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

tg: mvpшная

• зачем это нужно?

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

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


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

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

​​Kotlin Flow: StateFlow vs SharedFlow
Часть №1

Сначала общие факты для понимания задумки авторов библиотеки Kotlin Flow:


• Flow (потоки) — никак не связаны с Android
это библиотека котлина, которая завязано только на корутины (которые тоже являются библиотекой, не связанной с Android SDK)


• основные методы:
collect() - подписаться на данные из потока
emit() - положить значение в поток


• холодный поток — запускает создание элементов каждый раз при вызове collect()

при объявление потока описывается функция-билдер новых элементов, внутри которого вызывается emit()

то есть для каждого подписчика свой поток данных


• горячий поток — не зависит от вызова collect()

то есть для каждого подписчика один и тот же поток данных


• если корутина, запустившая холодный поток, остановлена — поток тоже остановится

но только если внутри есть проверка флага isActive


• collect() и emit() — suspend-функции, выполнение корутины не продолжится, пока они не завершатся

collect() приостанавливает корутину до завершения потока данных
emit() приостанавливает корутину до момента, пока поток данных не будет готов принять элемент (освободится буфер)


• CoroutineContext определяется родительской корутиной, вызвавшей collect(). но его можно сменить с помощью оператора flowOn(CouroutineContext)

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


• зачем нужен буфер?

если речь идет о холодном потоке, то буфер помогает выполнить emit(), не дожидаясь завершения collect()

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

Kotlin Flow: StateFlow vs SharedFlow
Часть №2


Общее для StateFlow и SharedFlow:

• это горячие потоки

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


• они не отслеживает жизненный цикл активити\фрагмента\вьюшки

но их можно запустить в корутинах, которые автоматически остановятся во время вызова onStop(). остановка \корутины вызывает остановку выполнения collect()



Отличия StateFlow и SharedFlow:

• при создании StateFlow нужно указать начальное значение, а при создании SharedFlow — нет

• у SharedFlow можно настроить вместимость буфера, у StateFlow хранится только 1 последний элемент



У SharedFlow два буфера — replayBuffer и extraBuffer:

• replay — сколько новый подписчик, вызвавший collect(), получит последних выпущенных элементов

• extraBuffer — сколько дополнительно элементов сохранится для "медленного" подписчика, который не успевает выполнять collect()

этот буфер работает в следующей ситуации:
допустим, emit() вызывается каждые 100мс, а collect() выполняется за 150мс

• onBufferOverflow — определяет, что делать, когда вызывается emit() при полностью заполненном extraBuffer

сценарии:
SUSPEND (остановить корутину на строчке emit, пока не освободится буфер)
DROPLATEST (удалить последний элемент в буфере)
DROPOLDEST (удалить самый старый элемент в буфере)

эти сценарии включаются в работу только если есть хотя бы один подписчик, который не успевает выполнять collect(). они не влияют на работу replayBuffer

​​Рассказ о стартапе

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

Начал вести список развлечений — оказалось, что без фильтров это очень неудобно

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


Если вам интересно, с какими факапами можно столкнуться при запуске своего проекта (от поиска иконок до оформления документов) и пройти путь от зарождения идеи до релиза (или удаления папки с проектом) со мной, то раз в пару дней посты об этом будут появляться там — t.me/find_fun_app

....

в этом канале скоро будут посты о болях с точки зрения кода — почему мне пришлось писать свой LazyList, как сделать кастомную анимацию на Compose и как вкатиться в многомодульную архитектуру, если ты скромный проект на пару тысяч строк (и нужно ли это)

​​Kotlin — вложенные и внутренние классы

Кроме наследования, есть два типа отношений между классами:

• вложенные (nested)

class A {
class B
}

создать экземпляр класса B: A.B()

зачем: выделить часть функционала класса A, используемый только с классом A, в отдельный класс B

• внутренние (inner)

class A {
inner class B
}

создать экземпляр класса B: A().B()

зачем: аналогично вложенному, но при этом функционал, выделенный в класс B, зависит от полей класса A


Отличия:

вложенный класс не связан с экземпляром внешнего — они создаются отдельно

внутренние классы содержат ссылку на внешний класс, то есть во внутренний класс неявно передается ссылка на внешний класс

у внутреннего класса есть доступ к public, private и protected полям внешнего класса


Возможная опасность:

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

....

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

​​Почему нельзя писать liveData.observe(this...) во Fragment?


Lifecycle — объект, который отслеживает жизненный цикл (Fragment, Activity....) и передает их в качестве состояния тем, кто на этот жизненный цикл подписался (ViewModel, LiveData...)

LifecycleOwner — интерфейс, который содержит единственный метод — getLifecycle() : Lifecycle

LiveData.observe(...) — может принимать ссылку и на Lifecycle, и на LifecycleOwner


С помощью объекта Lifecycle мы сообщаем LiveData, когда данные должны приходить подписчику, а когда — уже нет


Activity и Fragment реализует интерфейс LifecycleOwner

Получается, что в Activity и Fragment мы спокойно можем просто передавать this в LiveData.observe()?


В Activity можем, а во Fragment — можем, но так делать не стоит


Дело в том, что у Fragment жизненный цикл View и самого фрагмента не жестко связаны:

если фрагмент был убран с экрана (onDetach), но добавлен в backstack, то View может быть уничтожена (onDestroyView), а сам фрагмент — нет

получается, если при подписки на LiveData мы передадим ссылку на фрагмент, а не на viewLifecycleOwner, то возможна ситуация, когда данные придут, а View уже уничтожено — приложение упадет

​​Многопоточность за 100 слов

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

дальше по шагам:
1) первый поток скопировал объект к себе в кэш
2) первый поток изменил поле объекта
3) второй поток скопировал объект к себе в кэш
4) второй поток изменяет это же поле (и не знает об изменениях, сделанных первым потоком!)
5) второй поток записывает изменения в общую память
6) первый поток записывает изменения в общую память

бац — мы потеряли изменения, сделанные во втором потоке. первый поток их перезаписал + второй поток даже не знал, что объект был изменен в первом потоке!


Как этого избежать:

• synchronized — запрещает нескольким потокам работать с объектом (классом) одновременно

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

- synchronized(Object) — захватывает объект
- synchronized fun — можно читать как synchronized(this), захватывает объект
- static synchronized fun — захватывает класс (а не объект)


• volatile — синхронизирует чтение и запись

сработает, если один поток только читает, а другой только пишет

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


• atomic

атомарная операция = неделимая операция изменения объекта

с объектами, имеющими атомарные операции изменения (например, увеличение на единицу для AtomicInteger), можно работать в разных потоках без ручной синхронизации

в Java есть атомарные примитивы, коллекции и класс AtomicReference для работы с произвольными классами

....

а нужно ли думать о синхронизации переменной в корутинах?
сработают ли там эти подходы?

с нг! 🍻🍻🍻

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

....

по поводу канала — постов нет не потому что их нет, а потому что копим ману на следующий год

как говорил один разоблачитель клоунов: "Ведь если я способен вернуться — способен каждый!"

Как PornHub бережет твою репутацию

Чисто из профессионального интереса разберем одну интересную фичу

Density vs Resolution vs dp vs sp vs dpi

Разбираемся, чем displayMetrics.density отличается от displayMetrics.densityDpi

и фиксируем, когда 1 dp == 1 px

читать

наша постоянная рубрика — "Вечер рекомендаций"

всё что ниже — не реклама, а просто делюсь годнотой

....


• сообщество Coffee&Code — мобильные разработчики собираются оффлайн (!) каждую неделю

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

короче, супер круто, всем советую

вот московский чатик. через него можно выйти на остальные города

иногда сам туда заезжаю, да и в целом там куча крутых мужиков и девчонок, а также разных селебрити)



• канал об Android-разработке — Android Easy Notes

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


....

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

​​Animation — сколько нужно классов, чтобы красиво переместить вьюшку?


Глоссарий:

• интерполятор — функция, описывающая изменение значения во времени

например, значение может изменяться линейно или по экспоненте

• pivotX, pivotY — координата точки внутри View, относительно которой будет применена анимация (например, вращение)



Как можно сделать анимацию:

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

• ObjectAnimator — то же самое, что и ValueAnimator, только сразу принимает название параметра View, который нужно менять

например, ObjectAnimator.ofFloat(view, "alpha", 1f, 0f)

• ViewPropertyAnimator — оптимизированный ObjectAnimator

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


• LayoutTransition — определяет анимацию появления/удаления элемента

например, есть дефолтная реализация для LinearLayout, включается параметром android:animateLayoutChanges="true"

• Scene — анимация между состояниями экрана

создается две xml — со стартовым и конечным положением вьюшек

• MotionLayout — наследник ConstraintLayout с API для анимации сложных перемещений вьюшек, с которыми взаимодействует пользователь

• WindowAnimation — анимашки перехода между Activity

• AnimationDrawable — описание анимации в drawable


Дополнительное:

• AnimatorSet — упрощает комбинацию анимашек

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

• Fling Animation — придает "физичность" спискам

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

• Spring animation — придает "физичность" смахиваемым элементам

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

• LottieAnimation — иногда дизайнерам легче скинуть готовый Lottie-файл с анимацией. нужна сторонняя библиотека

....

как дела с анимацией в Compose, все потребности уже закрыты?

Много внешних библиотек

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

Существует несколько способов их упорядочить

читать

​​Навигация через диплинки

В некоторых приложениях навигация между экранами осуществляется через диплинки, а не хардкодится в приложении xml-графом или просто кодом


Теоретические описание:
открываешь ссылку — открывается страница в приложении

Практическое описание:
в манифесте описываются диплинки, которые собирается перехватывать приложение

через Intent их получает Activity и выбирает Fragment, который нужно открыть



Плюсы подхода:

• гибкость

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

• возможность открывать сразу нужную страницу приложения из других приложений

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

• можно на беке строить актуальный граф экранов

• можно передать параметры в диплинке

например, "sheme://testPage?couponCode=123"

удобно для аналитики маркетинга и передачи параметров с экрана на экран/устройства на устройство

• из коробки получаем открытие любого экрана по QR-коду



Минусы:

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

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

• нужно следить за тем, что Activity возвращает через onActivityResult

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

• бывают сложные сценарии

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

например, страница ввода кода из смс для авторизации

• никто не запретит другим приложениям-мошенникам перехватить диплинк

пользователь увидит диалог "через какое приложение открыть ссылку?" и выберет не вас

​​SmartTV — это Android?

Меня долго мучал этот вопрос

Вскрытие показало, что существует несколько видов прошивок:


• AndroidTV — практически тот же самый Android

но с переделанным лаунчером и урезанным функционалом

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


• GoogleTV — практически тот же самый AndroidTV

только красивее

и AndroidTV, и GoogleTV разрабатывает Google


• кастомный AndroidTV — практически тот же самый AndroidTV, но с переделанным лаунчером и чем-нибудь еще

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

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


• SmartTV — а вот тут уже интереснее

SmartTV может быть как на базе Android, так и нет

например, SmartTV от Samsung использует их собственную Tizen OS, которая основана на Linux, а не Android

если вы захотите разработать что-то под Tizen OS, то придется скачать специальную Tizen Studio и освоить .NET/JS+HTML+CSS/С++

то есть поставить .apk на Samsung SmartTV не получится

аналогичная ситуация со SmartTV от LG — они прошивают телевизоры WebOS (Linux based)

Один аккаунт на два приложения

Авторизовался в приложении А, а потом открыл приложение Б

А там окошко "Хотите войти под тем же аккаунтом?"

Как?

Ответ: через посредника == системный сервис == AccountManager

Что произошло под капотом:

1. Приложение А получило ваш логин и пароль

2, Приложение А проверило через бекенд, что вы существуете

3, Приложение А обратилось к системному AccoutManager, создало в нем Account и положило в него ваш логин и пароль

4. Приложение Б в момент запуска тоже обратилось к AccountManager, вязало Account и увидела ваш логин и пароль

Готово, приложение Б может авторизовать вас под тем же аккаунтом, не заставляя вспоминать пароль


Схема начинает выглядеть более безопасно, если учесть два факта:

• Account можно передавать только между приложениями, имеющими одну подпись

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


Почему вам это надо:

• пользователю не нужно вспоминать пароль == увеличивается шанс, что он авторизуется

• компании не надо тратить деньги на СМС с кодом авторизации

Итоги года 2023

Постов: 7

то есть один пост раз в полтора месяца. знаете ли вы более продуктивного автора?)


Статьи на хабр:
• Прикладное adb (Android Debug Bridge) для зумеров
• Ускоряем поиск по коду в Android Studio
• Android. Принять себя или Cookie?


Планы на следующий год:
• дальше, больше, come on everybody

....

с новым годом! 🎁
желаю хорошо отдохнуть и потом еще раз хорошо отдохнуть 🥂

​​Автоподстановка кода из SMS

Есть такая магия— SMS приходит на телефон, а приложение его автоматически читает и подставляет в поле для ввода OTP (one-time password)

На первый взгляд механизм понятен:

система получает SMS -> кидает Intent в приложение -> Broadcast Receiver получается Intent с текстом SMS


Но есть подвох — это опасно. Если все приложения будут получать этот Intent, то они смогут перехватить OTP (читать "аккаунт украден")

Поэтому вводятся дополнительные степени защиты

Первая:
1. Ограничение по времени — приложение получает Intent только в течение 5 минут после начала ожидания OTP

А вторая на выбор:
2.1 Или показываем пользователю системную диаложку "Вы ТОЧНО хотите вставить этот код в это приложение?"
2.2 Или в SMS должен быть зашит hash-код приложения

Подход 2.1 называется One-tap SMS verification (потому что требует от юзера одного нажатия на кнопку "да, ТОЧНО"
Подход 2.2 вообще не требует от юзера тапов

hash-код для 2.2 формирутеся из подписи приложения и заранее сообщается бекенду, который отправляет SMS

бекенд вставляет hash-код в конец текста SMS

Например,

"Никому не сообщайте код 110011, Ваш Банк💋 Sdnjh!a+iDn",
где Sdnjh!a+iDn — hash-код приложения

Из чего состоит apk

,apk это .zip

Если переименовать расширение .apk на .zip, то спокойно можно увидеть содержимое ,apk

Или можно открыть .apk в Android Studio

А там такое:

• .dex-файлы — скомпилированный java/kotlin-код, часто обфусцированный

у .dex-формата есть ограничение по объему, поэтому код приложения разбивается на несколько файлов

• .so-либы — это скомпилированный нативный код, то есть написанный на C/C++

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

java/kotlin код компилируется в единственном экземпляре, потому что запускается через JVM

• в папке r или res—- картинки, строки и т.д.

• в файле resources.arsc лежит мапа ресурсов и их id

• AndroidManifest.xml — итоговый манифест, смерженный из всех модулей и библиотек

• куча всякой мета-информации о приложении, библиотеках, котлине и даже градле

• META-INF — хэши файлов, информация о подписи приложения и еще мета-информация о библиотеках

пост про .aab

​​Многомодульность зачем нужна?

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

И этому веришь на подсознательном уровне. Много — круто, модули — круто, получается многомодульность тоже круто

А зачем она нужна?

....

Первое, что приходит в голову — ради чистой архитектуры, ради группировки кода, ради presentation, domain, data

Но кто мешает разделять код с помощью обычных папочек и пакетов?

Из них тоже можно построить древо любой сложности. Модуль в этом плане отличается только цветом иконки в студии

....

Второй ложный аргумент — в большом проекте у каждой команды должен быть свой модуль

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

Единственное исключение здесь — модификатор internal в kotlin, позволяющий ограничить видимость кода на уровне модуля (команды)

....

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

Работает это примерно так:

• система сборки (обычно gradle) считает хэш от всех файлов в модуле

• считает хэш всех модулей / библиотек, от которых зависит модуль

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

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

....

или есть еще причины?)