Хм, вряд ли Ktor можно назвать заменой Retrofit.
Все-таки суть Retrofit — это работа с REST-сервисами, а не выполнение произвольныз запросов в сеть. И для разработчика доступ к REST API через Retrofit выглядит именно как доступ через java-интерфейс (который он опишет аннотациями), абстрагируясь от работы с сетью.
Ktor скорее удобная замена urlconnection, или альтернатива (и обертка) okhttp с плюшками в виде поддержки корутин.
Кроме библиотеки, которую нет смысла упоминать есть ещё Play Services Vision, который кроме распознавания лиц и текста ещё умеет qr- и бар-коды читать.
По поводу библиотек, которые тянут за собой старые support зависимости — есть же jetify, который как раз и занимается переписыванием зависимостей в подключаемых либах с support на androidx
В браузере только статичная картинка?
Для просмотра картинки вне Wifi-сети дополнительно пробрасывали порт 8081 через VPN?
Можно ли то же самое сделать с ip-камерой (wifi), подключенной к роутеру? И можно ли сразу rtsp поток отдавать наружу через VPN (серый ip-адрес у роутера)?
Не так. Диалог с запросом на разрешение сам не появляется. Только если разработчик в коде явно это сделал. Это касается только dangerous-level разрешений. Разрешения с normal-level выдаются автоматом.
Начиная с Android Oreo не будут работать Broadcast Receiver'ы, статически добавленные через манифест, и которые вызываются неявно (без указания класса, а только по action).
Нужно или динамически регистрировать BroadcastReceiver в запущенном приложении (в активити или foreground-сервисе), или запускать активити/сервис через PendingIntent.getActivity(), PendingIntent.getService()
Если на секунду представить, что на самом-то деле все необходимые ключи давно представлены куда нужно
Зачем знать что-то о шифровании, вдаваться в технические подробности, если можно просто сесть, пофантазировать и «представить» все, что угодно и выгодно для себя. Даже то, чего быть по законам математики не может. Исходники клиентов телеграмма открыты, но зачем их читать и разбираться, если можно просто пофантазировать
Раздражает, что sdk для Wear не может прийти к какому-то более-менее стаблильному состоянию. Каждый раз открывая проект для Wear, который не трогал пару месяцев, замечаю, что часть классов уже deprecated. Некоторые просто переносятся в другие пакеты (например, android.support.wearable.view.* -> android.support.wear.widget.*), для некоторых приходится переписывать код (например, ChannelApi -> ChannelClient или CapabilityApi -> CapabilityClient).
Еще момент — на Wear до сих пор не завезли support-фрагменты. Это не дает использовать lifecycle-компоненты (только через костыли). К тому же, если какой-то фрагмент нужно будет использовать и для mobile-, и для wear- приложения, придется под каждую платформу делать свой фрагмент.
Никакой работодатель не будет платить разработчику за самостоятельный софт, с которого работодатель не будет иметь профита. Иначе с каких денег ему вообще платить? Не беру в расчет тот случай, когда пишется приложение (клиент) для существующей системы, с которой работодатель уже имеет профит.
Вызов этого метода «быстрый», т.к. проверяется только факт наличия любого сетевого соединения, а не реальная возможность куда-то подключиться (выход в Интернет). Поэтому его можно и нужно вызывать каждый раз непосредственно перед коннектом куда-либо. К слову, кроме activeNetworkInfo != null нужно еще проверять activeNetworkInfo.isConnected()
К тому моменту, когда нужно будет прочитать значение из переменной internet, ее значение может быть уже не актуальным, т.е. сети уже может не быть.
В нужных местах достаточно вызывать CheckURLConnection.isNetworkAvailable(), чтобы узнавать о наличии сети по факту в нужный момент.
А так получается, что наличие сети проверяется один раз при создании класса активити и зачем-то сохраняется в переменной, к тому же еще private static.
Static-поля и методы нужны для доступа к ним без создания экземпляра класса. Например, в static-методах этого класса или inner-static-классах — это если поле private. Или, например, как константы для доступа из других классов — это если поле не private.
Хм, вряд ли Ktor можно назвать заменой Retrofit.
Все-таки суть Retrofit — это работа с REST-сервисами, а не выполнение произвольныз запросов в сеть. И для разработчика доступ к REST API через Retrofit выглядит именно как доступ через java-интерфейс (который он опишет аннотациями), абстрагируясь от работы с сетью.
Ktor скорее удобная замена urlconnection, или альтернатива (и обертка) okhttp с плюшками в виде поддержки корутин.
Кроме библиотеки, которую нет смысла упоминать есть ещё Play Services Vision, который кроме распознавания лиц и текста ещё умеет qr- и бар-коды читать.
*Jetifier
По поводу библиотек, которые тянут за собой старые support зависимости — есть же jetify, который как раз и занимается переписыванием зависимостей в подключаемых либах с support на androidx
Для просмотра картинки вне Wifi-сети дополнительно пробрасывали порт 8081 через VPN?
Можно ли то же самое сделать с ip-камерой (wifi), подключенной к роутеру? И можно ли сразу rtsp поток отдавать наружу через VPN (серый ip-адрес у роутера)?
Есть же Kotlin Native и gradle-плагин Konan, который позволяет компилить pure-kotlin код без изменений сразу в ios-фреймворк
Нужно или динамически регистрировать BroadcastReceiver в запущенном приложении (в активити или foreground-сервисе), или запускать активити/сервис через PendingIntent.getActivity(), PendingIntent.getService()
Зачем знать что-то о шифровании, вдаваться в технические подробности, если можно просто сесть, пофантазировать и «представить» все, что угодно и выгодно для себя. Даже то, чего быть по законам математики не может. Исходники клиентов телеграмма открыты, но зачем их читать и разбираться, если можно просто пофантазировать
Еще момент — на Wear до сих пор не завезли support-фрагменты. Это не дает использовать lifecycle-компоненты (только через костыли). К тому же, если какой-то фрагмент нужно будет использовать и для mobile-, и для wear- приложения, придется под каждую платформу делать свой фрагмент.
пруфы? или это звучит как обвинение «без объяснения причин»
не пользуешься серверами амазона и гугла. а другие пользуются. в мире то больше людей, чем ты один.
В нужных местах достаточно вызывать CheckURLConnection.isNetworkAvailable(), чтобы узнавать о наличии сети по факту в нужный момент.
А так получается, что наличие сети проверяется один раз при создании класса активити и зачем-то сохраняется в переменной, к тому же еще private static.
Static-поля и методы нужны для доступа к ним без создания экземпляра класса. Например, в static-методах этого класса или inner-static-классах — это если поле private. Или, например, как константы для доступа из других классов — это если поле не private.