Александр Юдаков

Чат? — Отлично. Значит, у нас задача: отделить ботов от людей и забанить ботов.

Я действую так:

1. Собираю в оперативке на бэкенде статистику действий клиентов в разрезе IP.

2. После (!) обработки запроса клиента на бэкенде проверяю по статистике, не бот ли это? Использую несколько метрик и три временных среза для контроля лимитов: последние 3 секунды (здесь отлавливаются самые глупые боты), последние 10 секунд (здесь уже боты поумнее), последние 3 минуты (здесь ловятся совсем хитрые боты).

3. Если хотя-бы по одному из сочетаний метрика/период клиент выходит за границы дозволенного, объявляю его ботом.

4. Автоматизированно добавляю для данного IP-шника запрещающее правило на ближайшем брандмауэре. В итоге трафик на бэкенд больше не приходит.

5. Через месяц также автоматизированно удаляю IP-шник из черного списка брандмауэра.

В итоге обычный бот живёт у меня на сервере примерно полсекунды, успевая сделать 3...4 запроса. Потом IP уходит в бан на месяц и общается только с брандмауэром. Бэкенд сидит спокойно и ковыряет в носу.

У меня первым открывается основной экран, где человек работает после авторизации.

Чаще пользователь уже авторизован и именно этот сценарий мы оптимизируем с точки зрения скорости запуска приложения.

Если не хочется хранить состояние, можно передавать идентификатор элемента туда-обратно в интентах:

1. При вызове startActivityForResult добавляем в интент идентификатор элемента.
2. При возврате результата методом setResult() добавляем в интент кроме фотографии, еще и идентификатор, полученный ранее.
3. При обработке полученного результата в onActivityResult() получаем из интента фотографию и идентификатор элемента.

UPD:
Признаться, у меня для подобных задач реализован более удобный API.
При вызове startActivityForResult() сразу передаю обработчик результата.
А вся работа с requestCode скрыта в черном ящике.

public class ShellActivity extends AppCompatActivity {

    public interface ActivityResultHandler {
        void onActivityResult(int resultCode, Intent intent);
    }

    public void startActivityForResult(Intent intent, ActivityResultHandler handler) {
        // implementation
    }
}

Upd 2. А в Kotlin-е еще интереснее получается, вызов в одну сроку:

/**
 * Возвращает Intent (если RESULT_OK), либо null (если RESULT_CANCELED)
 * */
suspend fun ShellActivity.startActivityForResult(request: Intent): Intent? {
    return suspendCoroutine {
        this.startActivityForResult(request) { resultCode, response ->
            if (resultCode == RESULT_OK) {
                it.resume(response!!)
            } else {
                it.resume(null)
            }
        }
    }
}

Потому что по-русски десятичный разделитель — запятая.

А если надо в программистском формате — с точкой, то используем:
int.ToString(CultureInfo.InvariantCulture)

ScrollView может содержать только один вложенный элемент.

Если надо больше — берем LinearLayout и в него уже вставляем несколько элементов.

Из приложения Stasis канал можно вернуть назад в dialplan с помощью операции "continue":

https://wiki.asterisk.org/wiki/display/AST/Asteris...

Хоть в Queue, хоть... куда угодно.

Подобные задачи в работе возникают регулярно. Строю текст SQL-запроса вручную, безо всяких Linq to SQL.
В зависимости от текущих потребностей, включаю в текст SQL-запроса те таблицы, условия, группировки и т.д., которые нужны.

TCP-сокет - это транспортный уровень, его задача: передавать от отправителя получателю последовательность байт, при этом:
а) байты не терять;
б) доставлять эти байты именно в том порядке, в котором они были отправлены.

На этом задачи сокета заканчиваются. Т.е. ваш вопрос не имеет отношения к сокетам.

Вопрос о том, сколько надо читать (и ждать), решается не на транспортном, а на прикладном уровне. Т.е. перед вами фактически стоит задача: разработать протокол прикладного уровня - придумать правила, чего и сколько должна отправлять и ждать каждая из сторон сетевого взаимодействия.

Один из простых способов решения этой задачи - заставить каждую сторону перед отправкой любых данных указывать длину этих данных (например, 4 байта).

Тогда работа получателя в этом случае проста:
1) читаем из сокета 4 байта - длину сообщения;
2) читаем из сокета еще столько байт, сколько указано в длине сообщения.

А на всякие там DataAvailable обращать внимания не стоит, они только вводят в заблуждение. Если нужного нам количества байт еще не поступило - ждем, когда поступит.

Upd.
NetworkStream.DataAvailable всего лишь показывает нам, что данные уже поступили и их можно забрать с помощью Read, однако ничего не говорит о том, сколько еще данных ожидается и уж тем более НЕ сигнализирует о том, что другая сторона закончила передачу данных:

"Use the DataAvailable property to determine if data is ready to be read. If DataAvailable is true, a call to Read returns immediately."
https://docs.microsoft.com/en-us/dotnet/api/system...

Если использовать async/await - код получается значительно (!!!) проще и короче.
А компилятор сам потом переделает этот код в BeginConnect, BeginAccept и т.д.

Т.е. работать эти варианты все равно будут одинаково, а писать легче через async/await.