С одной стороны, статья для тех, кто уже прошел все основы, может собрать полноценное нативное приложение под андроид любой сложности и не знает, чем занять себя в свободное время.  С другой - перечисленные технологии становятся новой реальностью. И теперь просто знать о мультипоточности, ViewModels и LiveData становится недостаточно. Собираем список технологий\библиотек\фреймворков, которые нужно понять за этот год, если собираетесь проходить собеседования в компании, следящими за модой. все нижеописанные технологии — лишь надстройки над базовыми компонентами не обязательно знать их, чтобы написать отличное приложение но если хотите придерживаться современных течений - айда читать документацию Далее будет идти список и краткое описание, объясняющее концепцию технологии и боль, которую она решает. Максимально коротко. Compose — новый метод верстки.  Решает проблемы: пропадает разделение кодовой базы — отпадает нужда в xml-файлах, оставляем только Kotlin не нужно больше искать вьюшки по id и следить, чтобы значения обновлялись - грубо говоря, поля вьюшки подписываются на значения из viewModel и сами обновляются не нужно больше следить за жизненным циклом (при правильной архитектуре библиотеки сами учитывают состояние lifecycler) избавляет от наследования во вьюшках - переходим к композиции простых элементов Flow (StateFlow, SharedFlow...) — асинхронный способ передачи данных по подписочной модели. По принципу Flow — это LiveData с кучей настроек, с завязкой на корутины и без завязки на lifecycler-компонент. Решает проблемы: передача данных от Database (Source) к View теперь может выглядеть как тунель без ответвлений - Database испускает данные в flow, их забирает ViewModel и пересылает во View Да, та самая "чистая архитектура", которой сто лет, но теперь есть средство нагляднее показать идеальный "поток" данных можно гибко настроить буффер - указать количество хранимых элементов, выбрать сценарий переполнения и определить, что делать, если пришли новые данные, а старые еще не обработаны подписчиком Это не целая технология, но эта фишка языка часто используется вместе с Flow и Compose, потому что идеально подходит для описания состояний. Решает проблемы: можно описывать состояния (States) например, описать все состояния экрана - DataLoadedState, DataLoadingState, EmptyResultState.... результаты выполнения функции - Success<T>, Error(e: Throwable), Loading... Подробнее о возможностях, отличиях от Enum и способах применения писал пост в tg-канале об android-разработке: https://t.me/dolgo_polo_dev/52 Еще один сахар из котлина — синтаксическое средство, позволяющее делегировать методы getValue() и setValue() какому-то классу.Например, оператор by lazy() делегирует метод getValue(), что позволяет инициализировать значение переменной только при первом обращении (а не в момент объявления. Решает проблемы: есть готовые делегаты - by lazy(), by viewModels()... можно написать свои делегаты, избавившись от шаблонного кода можно хранить свойства в ассоциативном списке Hilt — фреймворк для внедрения зависимостей, замена Dagger 2 Решает проблемы: как и все dependency injection библиотеки - прям код создания объектов, управляет жизненный циклом и количеством создаваемых объектов преимущество перед Dagger 2 - предоставляет собственные скопы (Scope) для всех стандартных элементов - Activity, Fragment, ViewModel, Service... - не нужно писать свои преимущество перед Dagger 2 - не нужно писать ViewModelFactory для инъектирования во ViewModel преимущество перед Dagger 2 - достаточно написать Module-классы, в которых объявлены Provide и Bind-функции, и ставить аннотацию @Inject Корутины — пишем асинхронный код без явных коллбеков и явной работы с потоками Решают проблемы: код становится пошаговым, не нужно отслеживать макароны из коллбеков если использовать правильно, приложение работает без тормозов, так как главный поток занят только отрисовкой UI с помощью CoroutineScope и родительских отношений между корутинами можно легко прерывать выполнения функции в любом момент, если в ней больше нет нужды (например, viewModelScope автоматически остановится, когда ViewModel будет уничтожена из-за того, что пользователь ушел с экрана) MVI — архитектура. Про ее минусы и плюсы можно бесконечно, но суть одна - многие вышеописанные технологии заточены под ее философию:  заранее описываем все возможные состояния и эффекты, и от класса к классу передаем не информацию, а информацию, обернутую в состояние NavComponents — способ описания взаимодействия экранов или же способ создания наглядной карты приложения Решает проблемы: не надо держать в голове или в макете, с какого экрана на какой можно перейти - в Android Studio строится визуальный граф можно описать заранее, какие данные должны передавать экраны друг другу нельзя случайно увести пользователя по пути, не описанному в графе WorkManager — упрощает работу с запуском и контролем жизненного цикла сервисов (Service) Решает проблемы: очевидно - легче отслеживать, какие службы запущены, и задавать условия их смерти становится удобнее создавать отложенные службы (в том числе те, что должны отработать после перезагрузки устройства) в Android Studio добавили отладочное средство, которое позволяет отслеживать состояние сервисов, управляемых WorkManager Если вам, как и мне, нравится подобный формат — краткий обзор концепции технологий с минимальным погружением в код, то предлагаю: поддержать статью оценить tg-канал об Android-разработке — с картинками и короткими постами для новичков и бывалых — Dolgo.Polo Dev Android @dolgo_polo_dev