🧬 Генерация случайного числа

🧹 пост хозяйке на заметку

Получить истинно рандомное число (строку) программно не так уж просто

Ведь для генерации числа нужен алгоритм, а алгоритм по определению вещь предсказуемая


Поэтому для получения максимально непредсказуемого значения нужно добавлять энтропию — хаотичное число, взятое за пределами алгоритма

Довольно известный фокус — для энтропии брать напряжение процессора в моменте, шум микрофона, значение датчика температуры...


А в мобильных приложениях аж два раза за последнее время наткнулся на получение случайного числа с помощью действий пользователя:

🔵попросили порисовать рандомные рисунки на экране. получилась картинка, от которой взяли хэш

🔵попросили просто потыкать в рандомные части экрана 100 раз. взяли хэш от координат точек


Плюсы:
➕получаем действительно рандомное значение
➕пользователю спокойнее, дарит чувство безопасности

@dolgo_polo_dev

🧬 Чем cookie отличаются от headers?

Это база , но если никогда не работали с cookies, может быть интересно

В мобильной разработке про cookies вспоминаешь в 2 случаях:

🔵если нужен удобный способ отправлять ключ-значение на все http-запросы на определенный домен

🔵если речь идет о WebView



Коротко:

🔵header — это ключ-значение, которое добавляется к конкретному сетевому запросу через Interceptor (или Retrofit)

🔵cookie — это ключ-значение, которое привязывается к домену (например, domain = .ya.ru) и отправляется на все http-запросы на этот домен


📚 Где хранятся cookies?

В хранилище для cookies. За это отвечают классы

OkHttp: CookieJar, CookieHandler, CookieStore
WebView: webkit.CookieManager 

cookie-хранилища сами разруливают, на какие запросы нужно отправлять куку, а на какие нет — гибко настраивать это поведение можно с помощью cookie-атрибутов (httpOnly, secure, sameSite...)


📚 Откуда появляются cookies?

🔵бэк присылает cookies в http-респонсе в хэдере "Set-Cookie"
🔵также cookies можно добавить/удалить из кода


📚 Когда отправляются cookies?

Перед каждый сетевым запросом сетевой клиент (или WebView) идет в cookie-хралище и сообщает ему, на какой домен и путь (path) собирается сделать http-запрос

cookie-хранилище отдает список cookies, "привязанных" к этому домену

Сетевой клиент добавляет эти cookies в хэдер "Cookies" и отправляет вместе с сетевым запросом

➕ Когда удобно?

🔵для авторизационных токенов
🔵для флагов/значений, которые нужно передавать на все сетевые запросы определенного домена. например, выбранный пользователем язык

➖ Когда неудобно?

🔵когда нужно отправить какое-то значение только на 1 сетевой запрос — тут лучше подойдет header


@dolgo_polo_dev

🧬 Кто такое аппаратное ускорение?

Часто слышал этот термин, но не вдавался в подробности

Аппаратное ускорение — это перенос определенных расчетов с основного процессора на другие компоненты

Цель — разгрузить CPU и ускорить операции за счет специализированной архитектуры других чипов

В мобилке можно встретить следующие примеры аппаратного ускорения:
🔵Apple Bionic — нейропроцессор для FaceID и обработки фотографий
🔵ARM Adreno — графический процессор для рендеринга графики / игр
🔵еще бывают DSP-чипы для ускорения обработки сетевого сигнала, аудио потока и т.д.

По умолчанию аппаратное ускорение включено, но его можно отключить через настройки разработчика

Реальных кейсов не встречал, зачем это надо, но в интернетах пишут, что на GPU-могут флаковать snapshot-тесты — иногда помогает отключить GPU


💡 Еще удивительный факт — аппаратное ускорение можно отключить для отдельного экрана или даже для отдельной View:

view.setLayerType(View.LAYER_TYPE_SOFTWARE, null)

c Compose все немного сложнее — на отдельную composable-функцию отключить GPU нельзя

@dolgo_polo_dev

🧬 Нативки в нейронках

Вы же не забываете радоваться золотым годам бесплатных нейронок?

Пока все компании пытаются отжать себе долю рынка пожирнее, мы получаем крутейший продукт забесплатно


Причем абсолютно бесплатно — даже без рекламы


Одно из преимуществ нейнронок в том, что они сразу дают конкретные названия продуктов / моделей / версий. Могут выбрать лучшее и описать плюсы-минусы вариантов


Но как долго эти подсказки будут неподкупными?

Ведь это огромный простор для рекламы:

🔵чьи курсы по программированию лучше? Привет, друг, конечно вот эти от гекабрейнс за 300к в неделю

🔵где поесть вкусный омлет в Москве? Привет, друг, конечно в бургер кинге, не забудь купить комбо

🔵можешь сгенерировать мне картинку кота, лакающего молоко? Привет, друг, вот твой кот с бутылочкой Простоквашино


ждем появления нативной рекламы через пару лет

а потом подписку для отключения рекламы и подписку ultima-pro для полного отключения рекламы

@dolgo_polo_dev

🧬Как работают генераторы одноразовых кодов?

Утренняя рутина ☕️ — нужно доказаться компьютеру, что ты все еще ты — подключить VPN, войти в корпоративные учетки...

Для этого часто требуется ввод одноразового кода с телефона — подтверждение фактора владения


💡 Почему не использовать пуш-уведомления или SMS?

дорого

для примерных подсчетов можно умножить 50 копеек на количество сотрудников в компании — это расходы за день


Поэтому прибегают к бесплатному TOTP (Time-based One-Time Password)

Как это работает:

🔵на компьютере генерируется рандомный секретный ключ

🔵ключ передается на мобильное устройство (один раз, при первоначальном связывании устройств), обычно через сканирование QR-кода

🔵компьютер и телефон используют время как один из параметров для генерации кода

🔵каждые 30 секунд на основе секретного ключа и текущего времени генерируется новый одноразовый код (TOTP)

🔵когда вы вводите код на ноуте, там по тому же алгоритму генерируется (TOTP) и сравнивается с введенным -> ✅


Это безопасно:

👍 код действует всего 30 секунд
👍 секретный ключ хранится локально только на ваших девайсах

Если время на телефоне и компьютере не совпадает, TOTP не сработает. Уехать на Гаити и скинуть код другу, чтобы он зачекинился с рабочего компа в офисе, не получится

@dolgo_polo_dev

📕 Удавалось ли вам замерить перф локально?

Расскажите, если был удачный опыт — интересно узнать, мерите ли вы локально / в джобах на CI скорость работы приложения от тикета к тикету?



Мой опыт подсказывает, что это нереально. Потому что на перф влияет:

💀 насколько запуск приложения холодный — это далеко не бинарное состояние

💀 насколько телефон загружен другими фоновыми процессами

💀 загруженность и скорость сети в данный момент времени

💀 температура процессора / тротлинг

💀 настроение системы — дает оно приоритет вашему процессу или нет

💀 накопленный стейт приложения — может на первом чистом запуске все гладко, а на десятом у юзеров появятся побочки

💀 особенности девайса — на ксяоми перф мог улучшиться, а на самсунгах ухудшиться (так как одна и та же системная API-шка работает по-разному)


Поэтому увидеть реальное отклонение в десятках-сотнях миллисекунд можно только на биг дате, собранной хотя бы с нескольких тысяч пользователей

@dolgo_polo_dev

Во что упороться, если надоел обычный Android #2

Год назад выходила первая часть

Если мир стал снова абсолютно понятен, то вот еще области, куда можно прокачаться с перспективой практической пользы:


🌸Native c++.so

Нативные библиотеки нужны далеко не только для драйверов

С помощью них можно повысить скорость работы и создать проблемы реверс-хакерам

А также станет легче изучать исходники низкоуровневых либ, таких как WebView, Sentry, Cronet... на удивление иногда пригождается


🌸ML/AI локальные

Последний год подарил нам кучу ИИ-игрушек, которые можно запускать локально, не заплатив ни цента

Первый уровень — посмотреть API их подключения и возможности

Второй уровень — разобраться, какие параметры на что влияют и какие педали надо жать, чтобы получить желаемый бизнесом результат


🌸CI/CD и системы сборки

Нестареющая классика — пока не изобретут волшебную кнопку "собрать все типы сборок за ноль секунд со всеми комбинациями флагов и версий библиотек из всех мульти-репозиториев, доставить во все альсторы и синхронизировать в жиру", работа будет


🌸Ktor как бэкенд-сервер

Ktor позволяет за пару строк на коленке собрать https/gRPC сервер на Kotlin

Это порой позволяет быстро протестировать сложные клиент-серверные сценарии, не дожидаясь реализации на бэке и не мучаясь с моками в Charles/Proxyman

Ну и начинаешь чувствовать больше общности с бэкендерами ✨


@dolgo_polo_dev

Приходит поручик Ржевский устраиваться мобильным разработчиком в крупную ИТ компанию. HR ему говорит:

- Вы готовы до конца жизни писать на Java в одном файле на 150 тысяч строк?

- Как можно, вы с ума сошли! Есть же MVVM, MVI, Clean architecture...!

- Зарплата — $1M / year after tax 🧻

- А можно весь код в onCreate?

✨ Как быстренько протестить сетевые запросы

Если не хочется ждать реализации бэка


🔵Charles/Proxyman и т.д.

Программы-снифферы, которые позволяют перехватывать и модифицировать трафик через UI-кнопочки

код писать не надо, но придется разобраться куда тыкать

а также не очень удобно проверять сложные сценарии, когда важно замокать несколько запросов подряд


🔵Ktor и другие простые серверы

Можно быстро (за 20 строк кода и 2 запроса к нейронке) набросать свой локальный сервер, который позволит на определенные запросы получать определенные ответы

получаем почти реальный сервер с полной свободой действий

embeddedServer(Netty, port = 8080) {
   routing {
      get("/shop/{category}/{id}") {
         val category = call.parameters["category"]
         val id = call.parameters["id"]
         call.respondText("Категория: $category, ID товара: $id")
      }
   }
}.start(wait = true)

🔵MockWebServer от OkHttp

Это самая легкая штука. По сути класс, в который можно накидать респонсов, а потом по-очереди их забрать

// псевдокод
val server = MockWebServer()
server.enqueue("1")
server.enqueue("2")
api.load() // "1"
api.load() // "2"

из плюсов:
🔵можно быстро набросать unit-тест со сложным сценарием
🔵можно эмулировать плохую сеть / задержки. причем задержки отдельно на отдачу body, отдельно на отдачу headers...
🔵можно быстро протестить TLS-ошибки и другие ошибки сети

Узнали? Это Java сегодня

sealed interface Payment permits CreditCard, Crypto {
    BigDecimal amount();
}

record CreditCard(String number, BigDecimal amount) implements Payment {}

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    var futures = IntStream.range(1, 4)
            .mapToObj(i -> executor.submit(() -> STR."Running"))
            .map(Product::name)
            .toList();

    for (var f : futures) {
        System.out.println(f.get());
    }
}

record Customer(String name, int age, List<Product> products) {
    public Customer {
        products = List.copyOf(products);
    }
}

String productType = switch (obj) {
    case Product p -> p.name().contains("1") ? "2" : "3";
    case null     -> "null";
    default       -> "def";
};

cheapProduct.ifPresentOrElse(
    p -> "p",
    () -> "else"
);

ScopedValue<String> USER = ScopedValue.newInstance();
ScopedValue.where(USER, "superadmin").run(() -> {
    System.out.println(STR."\{USER.get()}");
});

кто теперь шугар daddy, пора ли переписывать все с умирающего kotlin 🤮 на красивую современную java 🌈?

Альтернативный способ замера перфа

Попался интересный доклад — идея заключается в том, чтобы отслеживать как много зарядки тратит приложение + мониторить нагрузку на процессор

Если приложение начинает тратить больше энергии и сильнее грузить процессор, то возможно кто-то ушатал перф


➡тезисы:

🔵мерить энергопотребление можно как программно через API системы, так и через прямое подключение ваттметром к плате

🔵темная тема и понижение частоты кадров заметно снижает энергопотребление экрана

🔵передача данных по сети (особенно по мобильному интернету) хавает много энергии


Также приводятся доказательства того, что стоит группировать сетевые запросы и отправлять их одной пачкой, чтобы как можно реже переводить модем в "активный" режим. Это же говорит и официальная дока андроида


Но к реальности, кажется, это мало применимо, так как всегда приоритетнее отправить запрос как можно раньше и показать контент пользователю, чем сэкономить несколько микроватт. Хотя у экоактивистов может быть другое мнение


Ведь еще стоит учитывать, сколько энергии и времени тратится на сжатие/разжатие данных, когда система фактически решит отправить запрос, как долго живет кэш, сколько потоков отведено под сетевые запросы, сколько живет соединение, размер запроса и ответа... слишком много параметров, чтобы можно было сделать однозначный вывод

↗ Дешевая выгодная оптимизация http-кэша

По умолчанию кэш http-запросов сохраняется по url:

https://g.com?timestamp=123

Если идем на тот же url, то можем попасть в кэш ➡ быстро получить ответ / снизить RPS на бэк ➡успех ↗


Но есть нюанс

💡 в OkHttp поиск в кэше идет по полному url, с учетом query-параметров


А некоторые query-параметры не влияют на респонс. Например, в них может быть зашит timestamp, аналитический маркер или прочая ерунда

Соответственно, чтобы повысить процент попадания в кэш, достаточно при записи и чтении из кэша вырезать из url незначащие query-параметры:

g.com?timestamp=123&b=1 ➡ g.com?b=1


Более того, на OkHttp реализован так, что даже порядок query-параметров играет роль. Соответственно, если всегда сортировать их в алфавитном порядке, то попадание в кэш еще вырастет ➡ успех ↗

g.com?b=1&a=1 ➡g.com?a=1&b=1

Ё

Пробовал оформить заявку на подключение домашнего интернета по адресу "Зеленая улица", а такой улицы не существует, хотя я вроде существую и нахожусь прямо на ней

Но существует "ЗелЁная улица"

Выходит была такая цепочка ввода фичи:

1. разработчик забыл разработать автозамену E на Ё и написать юнит-тест с Ё ✅
2. тестировщики не проверили Ё ✅
3. продакт принял заказ, не попробав ввести Ё ✅
4. бизнес потерял клиентов, живущих на Ё-ных улицах ✅

а у кого такого не было, чо уж тут

но есть интересный вопрос — насколько эффективнее начнут работать алгоритмы сжатия текста, если убрать Ё из алфавита?

🔥🔥🔥

одна папка, а сколько контента

блоги с авторским контентом по Android собрались в одной папке ➡ добавить 😎

🥰🥰🥰

⏳ пост капсула времени

к началу 2028 года:

✅мобильные разработчики перестанут верстать экраны вручную

верстка будет генерироваться автоматически, а разработчикам останется править баги / оптимизировать скорость


✅маятник качнется в сторону фулл-стек разработчиков

среднему мобильному разработчику придется больше шарить за смежную платформу iOS/Android, уметь верстать вебсайты и знать как работает бэк


✅Apple сначала потеряет монополию на магазин приложений, а потом вернет ее, выпустив Apple Store Lite

в нем не будет такой строгой модерации, но будет плашка "качайте на свой страх и риск"


✅ИИ рынок разделится между 2-3 основными игроками, которые будут поставлять полный набор ИИ в одной подписке


✅Android/iOS заберет заметный процент рынка ПК-систем. Часть офисных сотрудников начнут использовать мобилку с внешним монитором вместо ноута


✅на собесах перестанут спрашивать про MVI/MVVM, алгоритмы и прочие теоретические знания... останутся только практические задачи на проектирование и спортивное ориентирование в больших кодовых базах


пинганите в 2028, посмотрим, насколько обосрался

Google выпустил новый шрифт для кода — Google Sans Code

киллер-фича 🤩:
i, l и 1 начертаны нарочито по-разному, чтобы не путать

шрифт уже доступен в Android Studio

KRACUBOE?


а вы говорите в мобильной разработке ничего важного не происходит, как вам такое? 🚬