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

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

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

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

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


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

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


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

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

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


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

@dolgo_polo_dev

🎲 Retrofit 3.0 — что изменилось?

На днях вышел Retrofit 3.0. А точнее в один день вышло 2 версии — Retrofit 3.0 и 2.12

Библиотека важная, поэтому обзор


Самое интересное случилось в 2.12 — добавили стриминговую сериализацию из Kotlin/Java-классов в Json/Protobuf

Зачем это нужно было? ➡️чтобы большие классы не сериализовывались целиком перед отправкой запроса, а начинали это делать во время передачи данных на бэк

Это позволит чутка снизить нагрузку на процессор и оперативку, если

🔵передаете объемные данные в теле запроса (1 мегабайт+)

🔵где-то вызываете Retrofit.Call.enqueue() с главного потока — стриминг перенесет сериализацию с главного UI-потока в бэкграунд

Чтобы изменения заработали, нужно создавать конвертер с помощью функции withStreaming()

MoshiConverterFactory.create(moshi).withStreaming() // пример

В Retrofit 3.0 просто апнули версию OkHttp (3.14.9 -> 4.12.0). И немного поправили внутреннего кода, пару строк для совместимости с 4.12.0

Так что если обновите версию Retrofit, у вас транзитивно апнется OkHttp — будьте внимательны, берегите себя и своих тестировщиков

Из хороших новостей — Retrofit 3.0 формальный мажор, то есть бинарно совместим с предыдущими версиями (по словам разработчиков). Мажорное версию апнули для хайпа, чтобы подчеркнуть обновление OkHttp


Пруфы:
🔵 compare 3.0 with previous (там много ченжей, но 90% из них — это обновление их website с документацией)
🔵 compare 2.12 with previous (тут можно посмотреть, за счет чего сериализация стала асинхронной)

@dolgo_polo_dev

🧬 Маленький рынок

У Samsung OneUI прошивок есть фича — Samsung Edge Panel

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

Раньше было специальное EdgePanel SDK, с помощью которого можно было написать свое приложение для этой шторки и запушить его в GalaxyStore, но оно deprecated


Но самое удивительное другое — в GalaxyStore до сих пор продаются приложения для этой шторки по 100-500 рублей


Например, в Edge Panel могут отображаться стремные селекторы громкости или мини крестики-нолики. Цена удовольствия всего 82 рубля


А ведь если вовремя залететь, можно было бы стать миллионером

@dolgo_polo_dev

🖥 Android как пк в 2k25

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

А может Android уже можно использовать как компьютер?


Чтобы использовать Android OS в качестве Desktop OS нужно решить пару проблем:

🔵запихать в AOSP драйверы для компьютерных Wi-Fi-чипов, тачпадов и т. д.

🔵полноценно поддержать режим мультиоконности в UI/UX. ведь главное отличие пк от мобилки — на нем удобно работать с десяти программах одновременно, перескакивая между окнами

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


На данный момент существует два пути

💻 Форки Android AOSP

К этой категории относятся полноценные адаптации AOSP под desktop-систему

Android-x86, PrimeOS, Bliss OS... — все это нативные операционные системы, их можно установить на пк/ноутбук и использовать независимо от смартфтона

(кто их использует как основную систему на ежедневной основе не могу придумать)


💻 Desktop-режим смартфона

Тут другой подход — речь не про установку Android как системы на пк, а про специальный режим трансляции экрана телефона на внешний монитор

Работает это так:
1️⃣ подключаешь телефон к внешнему монитору через type-c
2️⃣ телефон продолжает работать как обычно или превращается в тачпад
3️⃣ на внешнем мониторе выводится содержимое телефона, но выглядит как привычная компьютерная ОС (приложения открываются в плавающих окнах, есть рабочий стол)

Но такой режим пока есть не везде:
🔵Samsung DeX — режим Desktop, доступный на некоторых девайсах Samsung
🔵Huawei EMUI Desktop — режим Desktop, доступный на некоторых девайсах Huawei
🔵Android Desktop — встроенный режим в Android. на Pixel Android 16 можно включить в настройках разработчика, тут видео

@dolgo_polo_dev

📱 Поисковик Google еще нужен?

Поймал себя на мысли, что перестал пользоваться google поиском

Хотя пару лет назад это казалось невозможным

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

🔵google карты, кажется, в рф развиваться перестали, хотя в мире новые фичи выходят

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

🔵на сложные вопросы, где галлюцинации недопустимы и нужны пруфы в виде источников, удобнее сходить в perplexity

🔵поиск по картинкам имхо лучше работает у яндекса, а если нужны уникальные иконки / картинки — спасают ии-генераторы


а гугл поиск зачем?

@dolgo_polo_dev

📚 Мода на SDK

Или архитектура SDK-first (отсылка на Mobile-first, который пришел на замену Desktop-first)

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

Вижу несколько причин


🔵Большим компаниям нравится экспериментировать с микро-бизнесами и растить стартапы внутри себя

Бигтех-копании нужно приложение и для продажи кофе, и для аренды электросамокатов, и для внутренних сотрудников

Плюс компаниям нравится переплетать эти стартапы между собой — продавать кефир в приложении такси

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

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


🔵ИИ могут использовать библиотеки для написания приложений

Чем меньший процент кода написан ИИ, тем более приложение стабильно и поддерживаемо

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

Хороший пример — сетевой клиент OkHttp. ИИ не сможет написать его полноценный аналог, но при этом за пару минут соберет на базе него работающий клиент-серверный фича-модуль


🔵Это логичное продолжение многомодульности

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

Следующий логичный этап — шарить код за пределами одного приложения (и одной платформы)

@dolgo_polo_dev

👀 Зачем роверу глаза?

Вообще-то по образованию я не смузи-вайб-разработчик, а суровый хард-инженер-робототехник — могу передаточное число редуктора в уме посчитать, сделать инженерный чертеж фланца по ГОСТу, отличить дырку от отверстия

Поэтому был рад, когда пригласили на конференцию для технарей "Чинители прекрасного". Сейчас Яндекс создает роверов, умные колонки и другое железо, поэтому логично, что команда решила провести ивент для инженеров


Из плюсов:
➕ не было докладов про очередные 10 тысяч способов оптимизировать Compose
➕ были интересные доклады о том, чем занимаются инженеры в компании

Расскажу пару запоминающихся фактов

🎲 Кубик Рубика

С большой вероятностью вы видели статью про него на хабре — удалось увидеть в живую)

Точнее в живую успеваешь заметить только два состояния до/после, сам процесс сборки занимает менее 200мс



❄ Охлаждение серверов

Тут как в мобилке — можно потратить полгода на микрооптимизации, которые дадут улучшение всего в 5%, но на масштабах бигтеха даже такой результат многократно окупится

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

Поэтому в Яндексе проектируют свои коробки для размещения серверного оборудования

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



📦 Ровер-доставщик

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

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

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


🖥 Еще были доклады про

🔵ДНК секвенатор и реверс-инжиниринг био-чипа
🔵промышленные манипуляторы Yandex Robotics
🔵световые мечи из звездных войн
🔵и стенд со всеми версиями Алисы в разобранном виде

@dolgo_polo_dev

📕 Новый этап для библиотек — Android SDK Runtime (Privacy Sandbox)

Google предлагает:
🔵публиковать SDK отдельно от приложения
🔵запускать SDK в отдельном от приложения процессе

Если этот проект не забросят в долгий ящик, то в ближайшие годы правила игры заметно поменяются



Как сейчас:
🔵все библиотеки, подключенные к приложению, кладутся в apk и являются частью приложения

Как станет:
🔵приложение знает только API библиотеки, а реализация SDK загружается отдельно от apk и работает в изолированном процессе


Почему эта идея имеет смысл:

➕SDK смогут обновляться отдельно от приложений (в рамках мажорной версии)

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

сейчас у приложения и подключенных к нему библиотек полный коммунизм — всё общее (файлы, shared-preferences, медиа-контент...)

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

➕размер apk уменьшится (если это еще кого-то волнует)


Есть и обратная сторона:

➖ если SDK обновляется в рандомный момент, то и приложение ломается в рандомный момент

➖ усложняется схема жизненных циклов, ведь у SDK будет отдельный от приложения ЖЦ

➖ не ясно, как это будет работать на устройствах без Play Market, откуда будут дозагружаться отсутствующие SDK


В первую очередь гугл раскатывает SDK Runtime с Android 14 для рекламных библиотек, а будущее зависит от фидбэка разработчиков

@dolgo_polo_dev

#рекомендация

@mobile_appsec_world — один из крупнейших каналов про безопасность мобильных приложений

если вдруг не подписаны, то вот что вы пропускаете:

🔵Как отключить SSL Pinning для дебага?

🔵Новости про использование AI в реверс-инжиниринге

🔵Анонсы конференций и вебинаров про мобильное ИБ

🔵Ссылки на полезные тулзы для анализа apk

и все это ради благой цели — чтоб в вашем сыре аппе было меньше дырок

🦙 Почему первые 300мс жизни сложнее всего?

Пользователь нажимает на иконку

И тут начинается треш и угар — в ближайшие 300мс случится больше интересного, чем в фильмах Marvel за последние 5 лет


Пошло поехало:

🔵проинициализоровать часть DI

🔵проинициализировать большую часть библиотек в нужном порядке

🔵стянуть и применить фича-флаги, на которых будет работать приложение

🔵собрать начальный стейт для первого экрана в зависимости от десятков параметров (авторизован ли юзер? какой язык выбран?...)

🔵прочитать кучу локальных данных из долгого ПЗУ, чтобы дальше работать с быстрой ОЗУ

🔵установить соединение с бэком (сходить в DNS, пройти этапы коннекта по TCP/TLS)

🔵выбрать CDN для загрузки медиа-контента

🔵проверить, есть ли в кэше информация для отображения

🔵если нет, начать грузить новую с бэка

🔵отрисовать какой-нибудь скелетон UI

🔵запустить префетч и прогрев важных экранов

🔵замерить все предыдущие этапы, отправить информацию о перфе в аналитику


фух, кончили. наконец-то можно вывести "Ваше приложение устарело, пожалуйста, обновите версию"

@dolgo_polo_dev

🖥 Будущее офисных компов у меня на столе

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

Задачи у него такие:

✅ минимальный размер, так как
а) это эстетично
б) это практично — иногда кидаю его с собой в портфель в поездки, весит чуть больше блока питания от ноутбука
в) удобно с подъемным столом — не нужно ничего придумывать, просто положил под монитор

✅ красивое — есть аналоги чуть мощнее за ту же цену, но в пластмассовых стремных коробках

✅ тянет без лагов среднего размера проекты в AutoCAD, Matlab, Android Studio, Figma

✅ можно позапускать на средних в 60фпс всякие простенькие игры — Dont Starve Together, Party Animals, Raft, Split Fiction...

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


Со всеми этими задачами отлично справляется встроенка AMD 680M — не шумит, не греется выше нормы, не фризит

Если вы геймер, то судя по тестам из интернетов можно взять MacMini на M4 за 70-80к и комфортно играть на нем даже в киберпанк


Итого — все мои потребности закрыл на 5️⃣➕. Через пару лет этот оставлю под медиастанцию, а для остального возьму что-нибудь с еще более мощной встроенкой


Думаю, со временем все не_игровые пк перейдут в такой формат. Коробки размером с пылесос больше не имеют смысла, но пока они чуть дешевле


А в идеальном мире домашние компы заменят телефоны, которые с помощью внешнего монитора и type-c будут превращаться в полноценный пк. Надеюсь, лет через 5-10 мы окажемся в этой точке 🌈


Минусы и характеристики моей коробки скину в комменты👇

@dolgo_polo_dev

🍏 Эко-френдли код

Почему какое-то приложение жрет батарейку больше остальных?

Потому что там много анимаций, а в бэкграунде запускается майнер? Возможно, но есть более физическое объяснение


💡 Например, сетевые запросы напрямую влияют на расход батареи

Чтобы выполнить запрос к бэку, нужно вывести Wi-Fi-модуль из сна ➡️ подать на него напряжение ➡️ сначала отправить байты в интернет с помощью излучения радиоволн ➡️ повисеть какое-то время в режиме ожидания ответных радиоволн

То же самое с Bluetooth/NFC/динамиками/датчиками — для передачи информации нужно потратить энергию


При этом теоретически важно не только количество передаваемой информации в физический мир, но и частота

Например, энергоэффективнее отправить 10 запросов в бэкенд параллельно, чем последовательно — ведь так мы быстрее позволим Wi-Fi платке вернуться в режим сна


Но в реальном мире такими микрооптимизациями занимается в лучшем случае ОС или драйвер, нам же достаточно описать, откуда и куда перекладывать джейсончики

@dolgo_polo_dev

🐦‍⬛️ Как передать секрет между приложениями безопасно

Помните про мужика в середине?

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


💡 Например, пользователь поставил смешную фотку на аватарку в нашем приложении, и мы хотим по-секрету рассказать об этом всем дружеским приложениям так, чтобы об этом не узнали чужие


⚠️ Какие варианты точно не подходят:

🔵Intent — любое приложение может перехватить Intent, зарегистрировав intent-filter в Manifest

🔵Explicit Intent — это тот же самый Intent, но с явным указанием пакета/класса, которому он отправляется. На устройстве не может быть двух приложений с одинаковым пакетом. Но на устройстве могут быть хакнутые сборки с оригинальным пакетом, сливающие данные, которые пользователь скачал не из Play Market, а с пиратского сайта

🔵deeplink с query-параметрами — любое приложение может перехватить deeplink, зарегистрировав его в Manifest

🔵общий зашифрованный файл — любой алгоритм шифрования и ключи шифрования, зашитые в apk, вычисляются за пару минут. так что сколько не шифруй, все-равно зареверсинжинирят



🗝 Более интересные варианты:

🔵AccountManager и ContentProvider / BroadcastReceiver с protectionLevel = "signature" и KeyStore — позволяют безопасно общаться приложениям с одинаковой подписью

🔵App-links — подходят, если нужно передать какой-то секрет из браузера в мобильное приложение. Благодаря этой технологии домен сайта связан с подписью приложения

🔵Доверенное лицо — это любые сторонние сервисы-посредники, который мы почему-то решили доверять (свой бэкенд, гугл аккаунт и т.д.)

@dolgo_polo_dev

Короткий топ технологий


гибкость 👇

🔵низкоуровневая разработка
🔵нативная разработка
🔵кросс-платформа
🔵AI-вайб-кодинг
🔵AI+вайб-кодинг
🔵no-code
🔵шаблоны
🔵нам IT-отдел не нужон, а логотип дочка нарисует

time to market 👆


@dolgo_polo_dev

SSL Pinning

Помните про мужика в середине?

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


Чтобы этого избежать, мы можем не передавать сертификат в момент установки соединения, а заранее зашить его в код мобилки

Там все просто — в коде указываем данные сертификата, и начинаем общаться с бэком только если он прислал этот же сертификат при установке соединения

В этой схеме приложение само является центром сертификации, так как само проверяет сертификат


➕
🔵спасаем пользователей, которые отключили проверку сертификатов на устройстве, не понимая, чем рискуют

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


mTLS

Тут идея в том, чтобы передавать сертификат не только с бэка на мобилку, но и с мобилки на бэк

В код мобилки зашивается сертификат, который при установки соединения отправляется на бэк.

Если мобилка не отправила сертификат или отправила неверный — бэк не станет устанавливать соединение

➕
🔵защищаем бэк от DDOS, даем ему возможность игнорировать запросы без сертификата

➖
🔵добавляется еще один шаг при установке соединения -> может негативно сказаться на скорости сетевых запросов (тратим дополнительные миллисекунды)

первая часть поста

TLS / SSL / SSL Pinning / mTLS на пальцах

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



Первый запрос к бэку всегда особенный — на нем устанавливается соединение и происходит обмен информацией для шифрования трафика

TLS / SSL — протоколы шифрования
❌ SSL — старый
✅ TLS — новый (самая крутая версия 1.3)

Один из этапов шифрование — передача публичного ключа шифрования вместе с сертификатом

💡 Сертификат — это файлик с уникальным публичным ключем, который владелец домена (например, ya.ru) получает от центра сертификации

💡 Центр сертификации — организация, которая выдает сертификаты доменам и потом проверяет их


Так вот, бэк передает свой сертификат на мобилку. Мобилка идет к центру сертификации и спрашивает:

Точно ли этот сертификат принадлежит этому домену?

Если все ок, то с помощью этого сертификата трафик шифруется

➡️ стороннее лицо (центр сертификации) подтверждает, что мы общаемся напрямую с ya.ru

Это и есть SSL / TLS (если сильно упрощать)

продолжение

🔓 Почему нельзя подключаться к публичным Wi-Fi в Макдональдсе?


С дества слышал, что подключаться к общественным Wi-Fi небезопасно. И это утверждение у меня никогда не билось с фактом "https трафик зашифрован, ведь s — это security" (ну или TLS/SSL)

Если весь трафик зашифрован умными алгоритмами, то какая-разница, через какие радиоволны подключаюсь к бэку? 🤯


Разгадка нашлась простая — проблема в атаке man in the middle (мужик в середине)


Это не какая-то конкретная уязвимость, а весь спрект потенциальных проблем

Имея доступ к роутеру, то есть находясь посередине между приложением и бэком, злоумышленник может попытаться:

🔵подменить DNS -> подменить итоговый IP сайта
🔵понизить соединение с https до http
🔵средиректить на произвольный url
🔵подменить публичный ключ шифрования (сертификат)


Естественно, все не так просто, и на произвольном сайте такое злодей не провернет. Нужно целое стечение обстоятельств, несколько допущенных дыр, чтобы любая из атак стала возможной. Но доступ к Wi-Fi, через который устанавливается соединение, повышает шанс этой атакой воспользоваться, ведь трафик льется через роутер как через прокси


А дальше начинается самое интересное — центры сертификации, разные версии SSL, шифрование трафика через VPN, дополнильные проверки IP браузером — огромный мир борьбы с мужиком в центре


Кстати проблема man in the middle справедлива и для мобильных приложений — существует не так уж много способов безопасно передать информацию между двумя приложеними, не дав кому-то посередине ее перехватить

@dolgo_polo_dev

😄 Очепятка в стандарте

referer — стандартный хэдер для http-запросов

он показывает, откуда пользователь попал на страницу/в приложение

например, referer = google.com ознаечает, что пользователь попал на сайт/в приложение из гугла. полезная штука для аналитики


но забавно другое — слова referer не существует, правильное написание — referrer (с двумя rr)

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


например, Cronet (сетевой клиент от гугла для Android, iOS и не только) тупо вырезает хэдер referer 🧠 из запроса. При этом referrer спокойно дает отправить

@dolgo_polo_dev