Контекстные ресиверы – это новая языковая фича, прототип которой был выпущен в Kotlin 1.6.20. С ее помощью можно неявно передавать в функцию дополнительные параметры. В статье разбирается пример того, как контекстные ресиверы помогают сделать запутанную бизнес-логику более понятной и корректной.

Сколько было разговоров о том, что Fuchsia OS заменит Android и начнется новая эра? И где теперь эта Fuchsia OS? Оказалось, что она все еще активно разрабатывается и похоже не собирается умирать. Чтобы не прозозохать все на свете и быть готовым, когда Fuchsia OS придет в ваш дом - рекомендую прочитать этот серьезный материал. Из статьи вы узнаете:
- Что из себя представлет Fuchsia OS и как выглядит ее модель безопасности
- Как собрать ОС из исходников и написать приложение для нее
- Как выглядит ядро ОС и как его подебажить с помощью GDB и QEMU
- Как разрабатывать эксплойты для ядра Fuchsia OS (Zirocon)

Под чай с печеньками прочитать не выйдет. Придется включать мозги 👨‍🔬

Многомодульный BDSM: стоит ли внедрять Gradle модули и какие типы модулей бывают?

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

Читать (Ru)

​​Как мы уменьшили ANR в 3 раза
#android

Ошибка "Приложение не отвечает" — весьма неприятное событие для пользователя, ведь в этом случае он вынужден закрывать приложение и делать незавершённое действие с начала.
Кроме этого, эти ошибки довольно непросто повторить и поправить, ведь они могут то появляться, то исчезать, а также иметь зависимость от устройств.

Вот неплохая статья, которая описывает то, откуда вообще появляются ANR и то, как с ними бороться.
Автор говорит, что они ощутимо снизили процент этих ошибок в своём приложении, а также значительно улучшили время старта приложения.

19 Things to Know About Kotlin Flow — A Quick Note

Статья-заметка, 19 пунктов о которых нужно знать про Kotlin Flow.

Читать (En)

разбираемся с тем, как Flow эмитит события наглядно

Пример анимации нескольких виджетов по отношению друг к другу с использованием MotionLayout в Jetpack Compose.

https://proglib.io/w/d3a57cdc

​​Parallax Effect в Jetpack Compose
#compose

Попалась красивая реализация эффекта параллакса, которая написана на Jetpack Compose.
Не уверен на 100%, что вам есть где использовать этот эффект в приложении, но любопытно посмотреть на саму реализацию. Тем более, на столь популярном в последнее время Compose.

@Composable элементы меняют своё положение на основе ориентации устройства и приходящих данных с SensorManager. Далее, создаётся DisposableEffect, который используется для репозиционирования Image.

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

Uber рассказывают, как они используют ApplicationExitInfo API, чтобы детектить Application Not Responding события. По сравнению с другими способами, таким образом получается детектить больше ANR и получать полную информацию о стектрейсах.

И еще про Uber. Смотрите, как выглядит их ферма из сотней Pixel девайсов. Она используется для всех видов тестирования – ручного, автотестов, перфоманса.

#compose

Jetpack Compose: Quick tips to avoid recomposition

Советы по тому как уменьшить количество рекомпозиций в Jetpack Compose, что позволит увеличить производительность UI. Советы:
👉 Переиспользуйте лямбды или используйте ссылки на методы
👉 Используйте обертку над List
👉 Логируйте рекомпозицию
👉 Анализируйте с помощью Compose Compile Metrics

​​How to write the best Usecase/Interactors ever!
#android

Попалась на глаза неплохая статья, которая рассказывает о принципах написания корректных UseCases. Если вы совсем не знакомы с тем, что это за слой архитектуры, то стоит ознакомиться с этой статьёй.

ℹ️ ВообщеUseCase — весьма полезный класс, который сильно облегчает взаимодействие между Repository и ViewModel. Правда, существует много разных подходов, связанных с корректным управлением жизненным циклом этого UseCase.

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

🖖 Идея с CoroutinesUseCaseRunner удобная, так что рекомендую попробовать подобный подход в своих проектах.

Занимательный пост. За 4 месяца чуваки выпустили первую версию STEPN. Ну и вот рассказали, с какими трудностями столкнулись. Про решения там без конкретики, да :С
За ссылку скажем спасибо @istima.

#gps #blockchain #gamedev

Достаточно содержательный доклад с прошедшей конференции Android Makers 2022 о создании собственного UI-фреймворка Apex от Romain Guy и Chet Haase.

В основе построения пользовательского интерфейса был использован подход Entity Component System, часто применяемый в геймдеве. Каждый элемент UI-фреймворка представляется в виде простой сущности, которой можно добавить некоторое поведение или свойство с помощью отдельных компонентов.

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

https://www.youtube.com/watch?v=4U9B0qMxIc0

Если вы используете Compose и столкнулись с задачей реализации взаимозависимого скролла вложенных друг в друга View и scrollable composables, вас очень порадует экспериментальный интероп между ними! Документация и сэмпл.

Давайте я вас таймзонам научу? А то бытует мнение, что это что-то сложное, но на самом деле там все просто, если разобраться.

Самое простое, что нужно понять — Unix timestamp. Формально это количество миллисекунд, которые прошли с момента, когда 1 января 1970-го года в Гринвиче часы показывали 00:00:00. Узнать его можно, например, так:

>>> new Date().getTime()
1655208767805 

Кайф в том, что unix time одинаково по всей земле. То есть любой человек где угодно на планете, если запустит эту вот строчку кода одновременно со мной (в ту же миллисекунду) получит то же самое число. Где бы он ни находился.

И это очень удобно. Unix time не зависит от часового пояса, летнего времени и прочей чепухи. Каждую секунду он увеличивается на 1000 по всей Земле одновременно. Любое число это какой-то момент времени, и любому моменту времени соответствует какое-то число, без пропусков.

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

Дальше. Понятно, что считать время таким образом не очень удобно. Люди привыкли общаться в терминах «четыре утра» или «семь тридцать вечера». Это называется Wall clock time, то есть время, которое будут показывать часы на стене в данном месте в этот конкретный момент времени.

В чем подвох? В один и тот же момент времени в разных точках земли часы на стенах показывают разное время. У меня 14:19, в Москве 15:19, а в Нью-Йорке 8:19. Это называется «часовые пояса».

То есть чтобы получить wall clock time, надо знать Unix timestamp и место. Это преобразование тотально (то есть работает всегда) — в любой unix timestamp в любом месте часы будут показывать _что-то_.

Обратное преобразование тоже возможно, но уже не всегда определено. Связано это с летним временем — когда часы переводят вперед, возникают цифры, которые часы не показывают никогда. Скажем, если часы перевели с 2 ночи на 3 ночи, ни в какой момент времени они не покажут 2:30. То есть перевести 2:30 в Unix timestamp не получится — в этом нет смысла.

Хуже того, если часы переводят назад (с 3 часов на 2), то 2:30 возникнет на них дважды в день, то есть из 2:30 можно получить аж два разных (с интервалом в 3600000 мс) Unix timestamp-а — преобразование неоднозначно.

Именно из-за этих неопределенностей Unix timestamp первичен, а wall clock time вторичен. Если вы храните Wall clock time (даже с часовым поясом), вы теряете информацию.

Теперь про часовые пояса. В простейшем случае это просто число минут, на которое время отличается от UTC — скажем, у меня сейчас UTC+0200, то есть на два часа больше, чем UTC. UTC это типа wall clock в Лондоне без летнего времени (на самом деле, атомные часы, но про это позже). Есть вроде таймзоны, отличающиеся кратно на 30 и на 15 минут, но более идиотских нет (хотя раньше были).

Однако простого UTC+0200 недостаточно, потому что есть еще два фактора — летнее время и история. Летнее время это собственно два раза в год переход от одного UTC-смещения к другому и обратно. Скажем, у меня в Германии летом UTC+2 (CEST), а зимой UTC+1 (CET). Поэтому когда вы выбираете часовой пояс, вы выбираете Europe/Berlin, а не UTC+2 — смещение плавает.

Плавает оно и из-за исторических прецедентов. Скажем, мой родной Новосибирск несколько раз только на моей памяти менял часовой пояс между UTC+6 и UTC+7. Это никак, разумеется, нельзя предсказать или предвидеть — правительства разных стран могут менять эти вещи произвольно, иногда объявляя об этом за пару недель и только в местных газетах.

Это была часть 1/3, продолжение ниже!