Турбореактивный двигатель

Треугольное крыло

Испытания крыла без двигателей

• Канал KБ4232: www.youtube.com/channel/UCmvN2bjhCx28qRCm8YMCbxg

Интервью

Baumgrtl Heliofly I

Hoppi-Copters

SoloTrek XFV

Martin Jetpack

P.S.

• Hiller ROE Rotorcycle
• Gyrodyne RON Rotorcycle

Jetpack Compose одна из наиболее обсуждаемых тем из серии видео про Android 11, заменивших собой Google IO. Многие ожидают от библиотеки, что она решит проблемы текущего UI-фреймворка Android, содержащего много легаси-кода и неоднозначных архитектурных решений. Другим не менее популярным фреймворком, о применении которого я расскажу в этой статье является Kotlin Coroutines, а конкретнее входящий в него Flow API, который может помочь избежать оверинжиниринга при использовании RxJava.
Применение этих инструментов я покажу на примере небольшого приложения для контроля за употреблением кофе, написанного с использованием Jetpack Compose для UI и StateFlow как инструмента для управления состоянием. В нем также используется MVI-архитектура.

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

Идея этого приложения родилась из моей любви к кофе. Однажды я заметил, что могу выпить его довольно много (особенно во время написания кода), и мне захотелось зафиксировать количество выпитых чашкек. Уже существует множество подобных приложений для контроля потребления воды или алкоголя, но не так много для кофе. В первой реализации приложение состоит из двух экранов: календарь с иконками кофейных чашек на месяц и список с количеством чашек разных видов в конкретный день.

Jetpack Compose

При первом взгляде на Jetpack Compose после продолжительной работы с версткой в XML вы, вероятно, почувствуете дискомфорт из-за смешения UI-кода с другим в файлах на Kotlin и необходимости постоянного контроля состояний. До этого у меня был опыт работы с Flutter который построен на виджетах и их состояниях. Это помогло мне легче понять концепцию декларативного UI и сделать прототип приложения всего за шесть вечеров после работы. Тот же опыт я использую для сравнения этих двух UI-фреймворков.

Помочь с переходом может сайт, на котором можно найти компонент в Compose по его названию в традиционном UI.

Также как во Flutter, в Compose вы можете использовать MainActivity как точку входа в приложение. Навигация же может быть сделана посредством композиции виджетов без необходимости использовать другие активити или фрагменты. Вы можете также поместить часть, написанную на Flutter или Compose в любую другую новую активити уже существующего приложения. Разработчики Compose планируют также добавить удобный API для навигации, похожий на тот, который есть в Flutter.

Свой проект я начал с шаблона Compose-проекта в Android Studio. Ниже приведен код из MainActivity.kt:

class MainActivity : AppCompatActivity() {    override fun onCreate(savedInstanceState: Bundle?) {        super.onCreate(savedInstanceState)        setContent {            CoffeegramTheme {                Greeting("Android")            }        }    }}@Composablefun Greeting(name: String) {    Text(text = "Hello $name!")}@Preview(showBackground = true)@Composablefun DefaultPreview() {    CoffeegramTheme {        Greeting("Android")    }} 

Если вы уже знакомы с Compose, можете просмотреть эту часть бегло
Весь Compose построен на функциях, помеченных аннотацией @Composable. Она позволяет плагину компилятора Котлина сгенерировать необходимый для работы код.
Вместо обычной функции setContentView(), вызываемой внутри Activity.onCreate() для инфлейта лейаутов, нужно вызвать функцию setContent(), передав ей в качестве параметра Composable-функцию.

Недавно появилась аннотация @Preview для Composable-функций, с помощью которой в новых версиях Android Studio (я использовал 4.2 Canary) можно увидеть превью помеченного компонента. Однако для этого нужно будет пересобрать проект. Этот механизм немного напоминает Hot Reload из Flutter, но работает медленнее из-за необходимости пересборки и не предоставляет синхронного анализатора кода, подсвечивающего ошибки компиляции всего проекта. Так у вас не получится увидеть превью, если вы меняете UI в одном файле, а в других остались ошибки компиляции.
Другая проблема, с которой я столкнулся, возникла после удаления директории .idea из Git и с диска после коммита. Превью перестал работать совсем, из-за чего пришлось начать проект с шаблона заново. Надеюсь, что это поправят в следующих версиях студии.
Тем не менее будет полезным оставлять как минимум одну превью функцию в каждом файле, чтобы отслеживать изменения в текущем.
Можно также аннотировать одну Composable-функцию несколькими превью-аннотациями с разными параметрами, чтобы, например, отслеживать вид компонента сразу в светлой и темной теме, нескольких размерах или с тестовыми данными. Сейчас не буду останавливаться подробнее, но пример можно посмотреть тут.

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

data class CoffeeType(    @DrawableRes    val image: Int,    val name: String,    val count: Int = 0)@Composablefun CoffeeTypeItem(type: CoffeeType) {    Row(        modifier = Modifier.padding(16.dp)    ) {        Image(            imageResource(type.image), modifier = Modifier                .preferredHeightIn(maxHeight = 48.dp)                .preferredWidthIn(maxWidth = 48.dp)                .fillMaxWidth()                .clip(shape = RoundedCornerShape(24.dp))                .gravity(Alignment.CenterVertically),            contentScale = ContentScale.Crop        )        Spacer(Modifier.preferredWidth(16.dp))        Text(            type.name, style = typography.body1,            modifier = Modifier.gravity(Alignment.CenterVertically).weight(1f)        )        Row(modifier = Modifier.gravity(Alignment.CenterVertically)) {            val count = state { type.count }            Spacer(Modifier.preferredWidth(16.dp))            val textButtonModifier = Modifier.gravity(Alignment.CenterVertically)                .preferredSizeIn(                    maxWidth = 32.dp,                    maxHeight = 32.dp,                    minWidth = 0.dp,                    minHeight = 0.dp                )            TextButton(                onClick = { count.value-- },                padding = InnerPadding(0.dp),                modifier = textButtonModifier            ) {                Text("-")            }            Text(                "${count.value}", style = typography.body2,                modifier = Modifier.gravity(Alignment.CenterVertically)            )            TextButton(                onClick = { count.value++ },                padding = InnerPadding(0.dp),                modifier = textButtonModifier            ) {                Text("+")            }        }    }}

Элемент списка здесь создаётся с использованием аналога ListView с горизонтальной ориентацией виджета Row. Внутри него помещается иконка (загруженный в виджет Image png-файл из drawable); разделительный виджет Spacer; Text с названием напитка, занимающий всё свободное пространство из-за применения модификатора weight(1f) (принцип похож на веса в ListView); и вложенный Row с двумя кнопками и текстом для отображения количества чашек.

Превью в Android Studio позволяет запустить виджет в интерактивном режиме. Это позволит с помощью тапов и других действий изменить состояние прямо в превью, без запуска приложения целиком на устройстве. Но если виджет получается слишком сложным (и превью в Android Studio не справляется), его можно запустить отдельно на эмуляторе. Так можно увидеть конкретный виджет без необходимости докликивать до него по всему приложению.

State

Виджет, показанный в коде выше, уже запускается в интерактивном режиме с возможностью изменить кнопками количество чашек. Это возможно из-за строки val count = state { type.count }, в которой функция state забирает исходное количество из модели type и оповещает окружающую ее Composable-функцию о каждом изменении этого состояния. Внутренние виджеты могут получить и изменить текущее значение через свойство count.value. Когда ему будет присвоено новое значение, поддерево виджетов, начиная с виджета, вызывающего функцию получения состояния, будет перерисовано (помимо state это может быть также collectAsState и прочие).

В отличие от Flutter, в Compose нет разделения на Stateful (с состоянием) и Stateless (без состояния) виджеты. Каждый виджет, содержащий вызов функции получения состояния может условно считаться Stateful, а остальные Stateless.

Теперь давайте создадим из уже имеющихся элементов весь список. Наиболее простой способ использовать виджет Column со вложенными элементами и добавить скроллинг, если список слишком длинный:

@Composablefun CoffeeList(coffeeTypes: List<CoffeeType>) {    Column {        coffeeTypes.forEach { type ->            CoffeeTypeItem(type)        }    }}@Composablefun ScrollableCoffeeList(coffeeTypes: List<CoffeeType>) {    VerticalScroller(modifier = Modifier.weight(1f)) {        CoffeeList(coffeeTypes: List<CoffeeType>)    }}

Composable функции могут быть вложены внутрь условных операторов и циклов, таких как if, for, when и т.п. Виджет Column представляет собой аналог ListView с вертикальной ориентацией, а VerticalScroller аналог ScrollView.
Проблема в этом коде должна быть очевидной. Список будет не оптимизированным и лагать во время скроллинга. Есть ли в Compose RecyclerView? Да представленный виджетом LazyColumnItems (еще недавно он назывался AdapterList). С ним реализация списка CoffeeList будет выглядеть следующим образом:

@Composablefun CoffeeList( coffeeTypes: List<CoffeeType>, modifier: Modifier = Modifier) {    LazyColumnItems(data = coffeeTypes, modifier = modifier.fillMaxHeight()) { type ->        CoffeeTypeItem(type)    }}

На данный момент нет аналога для RecyclerView с GridLayoutManager (для создания сетки вместо линейного списка). Но для приложения уже сделан один из двух экранов.

Перед тем как сделать следующий, нужно подумать о навигации.

Навигационные элементы из Material design реализованы очень похоже во Flutter и Compose. Корневым элементом является виджет Scaffold, обернутый темой. Он может содержать TopAppBar (верхнюю панель меню), BottomAppBar (нижнюю панель меню, с возможностью интегрировать кнопку Floating action button) или Drawer (левое боковое меню). Чтобы реализовать BottomNavigationView из Material я поместил в Scaffold виджет Column с BottomNavigation внутри:

@Composablefun DefaultPreview() {    CoffeegramTheme {        Scaffold() {                Column() {                    var selectedItem by state { 0 }                    when (selectedItem) {                        0 -> {                            Column(modifier = Modifier.weight(1f)){}                        }                        1 -> {                            CoffeeList(listOf(...))                        }                    }                    val items =                        listOf(                            "Calendar" to Icons.Filled.DateRange,                             "Info" to Icons.Filled.Info                        )                    BottomNavigation {                        items.forEachIndexed { index, item ->                            BottomNavigationItem(                                icon = { Icon(item.second) },                                text = { Text(item.first) },                                selected = selectedItem == index,                                onSelected = { selectedItem = index }                            )                        }                    }                }            }    }}

Состояние текущей выбранной вкладки содержится в selectedItem. Его состояние с помощью оператора when формирует контент для вкладки. Изменение вкладки происходит по клику на BottomNavigation с последующим изменением значения selectedItem. Такой способ построения навигации позволяет отказаться от использования фрагментов и активити кроме корневой для дерева Compose.

Реализацию второго экрана с таблицей и покоммитное создание кода приложения можно посмотреть в репозитории. Полезной деталью, которую я встретил тут, стал способ доступа к контексту для получения, например, ресурсов или текущей локали. Для этого нужно вызвать ContextAmbient.current.context внутри любой Composable-функции. Сам же экран с месячной таблицей выглядит так:

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

StateFlow

Теперь перейдем ко второй части названия статьи. Flow является аналогом реактивных стримов в составе Корутин. Его можно рассматривать как холодную последовательность данных они начинают поступать только после подписки (вызова терминальной функции). Для передачи состояния между разными компонентами приложения в реактивном стиле нужен аналог BehaviorSubject из RxJava. Таким аналогом является StateFlow. Как и BehaviorSubject, он может иметь несколько подписчиков и должен быть проинициализирован исходным значением.

Для иллюстрации его использования в примере, показанном выше, состояние selectedItem может быть заменено с помощью selectedItemFlow:

val selectedItemFlow = MutableStateFlow(0)@Composablefun DefaultPreview() {    ...    val selectedItem by selectedItemFlow.collectAsState()    when (selectedItem) {        0 -> TablePage()        1 -> CoffeeListPage()    }    ...    BottomNavigationItem(        selected = selectedItem == index,        onSelected = { selectedItemFlow.value = index }    )}

Состояние получается из StateFlow (или другого Flow) с помощью вызова функции collectAsState(). Оно используется для определения необходимости перерисовки, а также получения текущего значения.

Чтобы изменить состояние, нужно присвоить значение свойству selectedItemFlow.value.

Так как текущее значение может быть также получено через это свойство, важно не забыть вызвать collectAsState() внутри виджета. Иначе он не будет обновляться вместе с состоянием. Возможным паттерном тут может быть использование состояния (val selectedItem by selectedItemFlow.collectAsState()) для чтения значения, а свойства MutableStateFlow (selectedItemFlow.value) для изменения.

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

val yearMonthFlow = MutableStateFlow(YearMonth.now())val dateFlow = MutableStateFlow(-1)val daysCoffeesFlow: DaysCoffeesFlow = MutableStateFlow(mapOf())

yearMonthFlow отвечает за текущий отображаемый месяц.
dateFlow за выбранный день в таблице и навигацию между экранами: если текущее значение равно -1 отображается экран с таблицей TablePage. В другом случае это будет экран со списком CoffeeListPage для конкретного дня месяца.
daysCoffeesFlow прототип репозитория, содержащего все записанные чашки кофе. Его внутренняя структура стала решением следующей проблемы.

Когда пользователь переходит из TablePage в CoffeeListPage, состояние этого экрана должно быть частью (за конкретный день) из общего состояния, представленного в daysCoffeesFlow. Состояние элемента списка CoffeeList внутри должно быть также частью состояния целого списка. Когда изменяется количество чашек внутри, сам элемент не может знать, как изменить общее состояние daysCoffeesFlow. Мы помогаем ему, создавая набор мапперов из более общих Flow в более конкретные и наоборот.

Такое временное решение добавило четыре лишних типа, показанных в файле DayCoffee.kt. Если бы уровней вложенности было больше, то и мапперов было бы ещё больше.

Эти мапперы привели к трудночитаемому коду внутри UI-функций. Поэтому я решил применить MVI-архитектуру. Существующие решения, такие как MVICore, показались слишком завязанными на RxJava или другие асинхронные фреймворки и слишком сложными для текущей задачи. Моё решение базируется на статье Android MVI with Kotlin Coroutines & Flow article. Базовые концепции MVI с диаграммами можно найти там же. Здесь я покажу код базового класса Store:

abstract class Store<Intent : Any, State : Any>(private val initialState: State) {    protected val _intentChannel: Channel<Intent> = Channel(Channel.UNLIMITED)    protected val _state = MutableStateFlow(initialState)    val state: StateFlow<State>        get() = _state    fun newIntent(intent: Intent) {        _intentChannel.offer(intent)    }    init {        GlobalScope.launch {            handleIntents()        }    }    private suspend fun handleIntents() {        _intentChannel.consumeAsFlow().collect { _state.value = handleIntent(it) }    }    protected abstract fun handleIntent(intent: Intent): State}

Store работает на входящих Intent-ах и предоставляет StateFlow<State> подписчикам. Он содержит несколько вспомогательных функций, которые позволяют наследникам реализовать только похожую на Reducer функцию handleIntent() и иерархию собственных интентов и состояний. Пользователи наследников Store могут получить состояние через свойство state, возвращающее StateFlow; или передать новый интент с помощью функции newIntent().

Ниже приведен пример такого наследника NavigationStore, реализующего снова логику навигации:

class NavigationStore : Store<NavigationIntent, NavigationState>(        initialState = NavigationState.TablePage(YearMonth.now())    ) {    override fun handleIntent(intent: NavigationIntent): NavigationState {        return when (intent) {            NavigationIntent.NextMonth -> {                increaseMonth(_state.value.yearMonth)            }            NavigationIntent.PreviousMonth -> {                decreaseMonth(_state.value.yearMonth)            }            is NavigationIntent.OpenCoffeeListPage -> {                NavigationState.CoffeeListPage(                    LocalDate.of(                        _state.value.yearMonth.year,                        _state.value.yearMonth.month,                        intent.dayOfMonth                    )                )            }            NavigationIntent.ReturnToTablePage -> {                NavigationState.TablePage(_state.value.yearMonth)            }        }    }    private fun increaseMonth(yearMonth: YearMonth): NavigationState {        return NavigationState.TablePage(yearMonth.plusMonths(1))    }    private fun decreaseMonth(yearMonth: YearMonth): NavigationState {        return NavigationState.TablePage(yearMonth.minusMonths(1))    }}sealed class NavigationIntent {    object NextMonth : NavigationIntent()    object PreviousMonth : NavigationIntent()    data class OpenCoffeeListPage(val dayOfMonth: Int) : NavigationIntent()    object ReturnToTablePage : NavigationIntent()}sealed class NavigationState(val yearMonth: YearMonth) {    class TablePage(yearMonth: YearMonth) : NavigationState(yearMonth)    data class CoffeeListPage(val date: LocalDate) : NavigationState(        YearMonth.of(date.year, date.month)    )}

Начнем с конца. Здесь можно увидеть два sealed-класса, отвечающих за все возможные интенты и состояния, с которыми работает этот Store. Интенты представляют возможные действия в UI. А состояния навигации соответствующие экраны приложения.

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

Функция handleIntent() содержит бизнес-логику превращения интентов в состояния.
Второй DaysCoffeesStore, отвечающий непосредственно за кофе, как и весь код приложения, можно найти в репозитории.

Несмотря на детские болезни Jetpack Compose и необходимость поменять мышление для полного погружения, он уже выглядит как готовая для использования в некритичных приложениях технология и будущее Android-разработки. С ним легко применить современные техники, такие как архитектуры с однонаправленным потоком данных и Корутины, решая некоторые задачи (как, например, навигацию) легче. Я думаю, что разработчики должны начать знакомиться с ним, чтобы не пропустить тот момент, когда Compose (вместе с Корутинами) появится в списке обязательных технологий в вакансиях.

С популяризацией декларативных UI-фреймворков, таких как Compose, Flutter и SwiftUI, мобильная разработка становится всё больше похожей на Web. Это может привести, как к унификации используемых архитектур, так и к увеличению переиспользования кода между большинством клиентских платформ.

Появление

API design is building future regret

Преимущества

• Unbundled toolkit: JC не зависит от конкретных релизов платформы, а значит, забудем уже про Support Library.
• Kotlin-only: Больше не нужно переключаться между классами и xml-файлами вся работа с UI происходит в одном Kotlin-файле.
• Композитный подход: Наследованию нет, композиции да. Каждый UI-компонент представляет собой обычную composable-функцию, отвечающую только за ограниченный функционал, т.е. без лишней логики. Никаких больше View.java на 30 тысяч строк кода.
• Unidirectional Data Flow: Одна из основополагающих концепций Jetpack Compose, о которой будет рассказано подробнее чуть ниже.
• Обратная совместимость: Для использования Compose не требуется начинать проект с нуля. Имеется возможность как его встраивания (с помощью ComposeView) в имеющуюся xml-вёрстку, так и наоборот.
• Меньше кода: Тут, как говорится, лучше один раз увидеть, чем сто раз услышать. В качестве примера возьмём классическое сочетание компонентов два поля ввода и кнопка подтверждения:

<?xml version="1.0" encoding="utf-8"?><LinearLayout xmlns:android="http://personeltest.ru/away/schemas.android.com/apk/res/android"    android:layout_width="match_parent"    android:layout_height="wrap_content"    xmlns:app="http://personeltest.ru/away/schemas.android.com/apk/res-auto"    android:orientation="vertical"    android:padding="@dimen/padding_16dp">    <com.google.android.material.textfield.TextInputLayout        android:id="@+id/til_login"        android:layout_width="match_parent"        android:layout_height="wrap_content"        style="@style/Widget.MaterialComponents.TextInputLayout.OutlinedBox"        android:hint="@string/sign_in_email"        android:layout_marginBottom="@dimen/margin_8dp">        <com.google.android.material.textfield.TextInputEditText            android:id="@+id/et_login"            android:layout_width="match_parent"            android:layout_height="wrap_content"            android:inputType="text"/>    </com.google.android.material.textfield.TextInputLayout>    <com.google.android.material.textfield.TextInputLayout        android:id="@+id/til_password"        android:layout_width="match_parent"        android:layout_height="wrap_content"        style="@style/Widget.MaterialComponents.TextInputLayout.OutlinedBox"        android:hint="@string/sign_in_password"        android:layout_marginVertical="@dimen/margin_8dp">        <com.google.android.material.textfield.TextInputEditText            android:id="@+id/et_password"            android:layout_width="match_parent"            android:layout_height="wrap_content"            android:inputType="textPassword"/>    </com.google.android.material.textfield.TextInputLayout>    <Button        android:id="@+id/btn_confirm"        android:layout_width="match_parent"        android:layout_height="wrap_content"        android:text="@string/sign_in_submit"        android:layout_marginTop="@dimen/margin_8dp"        android:padding="@dimen/padding_8dp"        android:background="@color/purple_700"/></LinearLayout>

@Preview@Composablefun LoginPage(){    var loginValue by remember { mutableStateOf(TextFieldValue("")) }    var passwordValue by remember { mutableStateOf(TextFieldValue("")) }    Surface(color = Color.White) {        Column(modifier = Modifier.padding(16.dp).fillMaxWidth()) {            Surface(color = Color.White, modifier = Modifier.padding( vertical = dimensionResource(id = R.dimen.padding_8dp))) {                OutlinedTextField(                        value = loginValue,                        onValueChange = { loginValue = it },                        label = { Text(text = stringResource(id = R.string.sign_in_email)) },                        placeholder = { Text(text = stringResource(id = R.string.sign_in_email)) },                        modifier = Modifier.fillMaxWidth()                )            }            Surface(color = Color.White, modifier = Modifier.padding( vertical = dimensionResource(id = R.dimen.padding_8dp))) {                OutlinedTextField(                        value = passwordValue,                        onValueChange = { passwordValue = it },                        label = { Text(text = stringResource(id = R.string.sign_in_password)) },                        placeholder = { Text(text = stringResource(id = R.string.sign_in_password)) },                        visualTransformation = PasswordVisualTransformation(),                        modifier = Modifier.fillMaxWidth()                )            }            Button(                    onClick = {},                    modifier = Modifier.padding( vertical = dimensionResource(id = R.dimen.padding_8dp)).fillMaxWidth(),                    backgroundColor = colorResource(R.color.purple_700)) {                Text(text = stringResource(id = R.string.sign_in_submit), modifier = Modifier.padding(8.dp))            }        }    }}

Недостатки

• Alpha-версия: Безусловно, более чем за год разработки фреймворк значительно преобразился и стал гораздо стабильнее. Однако это всё ещё альфа, а поэтому за пределами Pet-проектов использовать его не рекомендуется.

Декларативный стиль

Что за Unidirectional Data Flow?

    var loginValue by remember { mutableStateOf(TextFieldValue("")) }    var passwordValue by remember { mutableStateOf(TextFieldValue("")) }

Вывод

PS

RIP

• Год назад: Первая смерть на реактивном ранце

К сожалению, мы не выбираем себе смерть, но мы можем встретить её достойно, чтобы нас запомнили как мужчин.
к/ф Гладиатор

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

Это третья и заключительная статья в цикле про различные кейсы навигации с Navigation Component-ом. Вы также можете ознакомиться с первой и второй частями

Навигация в многомодульных приложениях

Если вы работаете с большим приложением, вероятно, вы уже разбили его на модули. Неважно, как именно. Может быть, вы создаёте отдельные модули для логики и UI, а может храните всю логику фичи (от взаимодействия с API до логики presentation-слоя) в одном модуле. Главное у вас могут быть кейсы, когда требуется осуществить навигацию между двумя независимыми модулями.

На картинке мы видим, что у нас есть как минимум два модуля: модуль :vacancy с одним экраном и модуль :company с двумя экранами вложенного flow. В рамках моего примера я построил навигацию из модуля :vacancy в модуль :company, которые не связаны друг с другом.

Существует три способа как это сделать, разберём их один за другим.

App-модуль + интерфейсы

Первый способ использовать ваш application-модуль в качестве хранилища всего графа навигации и определить в feature-модулях специальные интерфейсы для роутинга.

Структура приложения будет стандартной: есть app-модуль, который знает обо всех feature-модулях, есть feature-модули, которые не знают друг о друге. В этом способе ваши feature-модули пребывают в священном неведении о Navigation Component, и для навигации они будут определять интерфейсы примерно вот такого вида:

// ::vacancy moduleinterface VacancyRouterSource {    fun openNextVacancy(vacancyId: String)    // For navigation to another module    fun openCompanyFlow()}

А ваш app-модуль будет реализовывать эти интерфейсы, потому что он знает обо всех action-ах и навигации:

fun initVacancyDI(navController: NavController) {  VacancyDI.vacancyRouterSource = object : VacancyRouterSource {      override fun openNextVacancy(vacancyId: String) {          navController.navigate(              VacancyFragmentDirections                .actionVacancyFragmentToVacancyFragment(vacancyId = vacancyId)          )      }      override fun openCompanyFlow() {          initCompanyDI(navController)          navController.navigate(R.id.action__VacancyFragment__to__CompanyFlow)      }  }}

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

• дополнительную работу в виде определения интерфейсов, реализаций, организации DI для проброса этих интерфейсов в ваши feature-модули;
• отсутствие возможности использовать использовать Safe Args плагин, делегат navArgs, сгенерированные Directions, и другие фишки Navigation Component-а в feature-модулях, потому что эти модули ничего не знают про библиотеку.

Сомнительный, в общем, способ.

Графы навигации в feature-модулях + диплинки

Второй способ вынести отдельные графы навигации в feature-модули и использовать поддержку навигации по диплинкам (она же навигация по URI, которую добавили в Navigation Component 2.1).

Структура приложения будет ровно такой же, как и в первом способе: есть app-модуль, который зависит от всех feature-модулей, и есть feature-модули, которые друг о друге ничего не знают.

Но теперь ваш app-модуль не обязан содержать весь граф навигации приложения, он может содержать только его часть. А остальные кусочки будут содержать именно feature-модули.

<navigation xmlns:android="http://personeltest.ru/away/schemas.android.com/apk/res/android"    android:id="@+id/company_flow__nav_graph"    app:startDestination="@id/CompanyFragment">    <fragment        android:id="@+id/CompanyFragment"        android:name="company.CompanyFragment">        <deepLink app:uri="companyflow://company" />        <!-- Or with arguments -->        <argument android:name="company_id" app:argType="long" />        <deepLink app:uri="companyflow://company" />        <action            android:id="@+id/action__CompanyFragment__to__CompanyDetailsFragment"            app:destination="@id/CompanyDetailsFragment" />    </fragment>    <fragment        android:id="@+id/CompanyDetailsFragment"        android:name="company.CompanyDetailsFragment" /></navigation>

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

После этого мы можем использовать этот диплинк для открытия экрана CompanyFragment из модуля :vacancy :

// ::vacancy modulefragment_vacancy__button__open_company_flow.setOnClickListener {  // Navigation through deep link  val companyFlowUri = "companyflow://company".toUri()  findNavController().navigate(companyFlowUri)}

Плюс этого метода в том, что это самый простой способ навигации между двумя независимыми модулями. А минус что вы не сможете использовать Safe Args, или сложные типы аргументов (Enum, Serializable, Parcelable) при навигации между фичами.

P.S. Есть, конечно, вариант сериализовать ваши сложные структуры в JSON и передавать их в качестве String-аргументов в диплинк, но это как-то Странно.

Общий модуль со всем графом навигации

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

У нас по-прежнему есть app-модуль, но теперь его задача просто подсоединить к себе все feature-модули; он больше не хранит в себе граф навигации. Весь граф навигации теперь располагается в специальном модуле, который ничего не знает о feature-модулях. Зато каждый feature-модуль знает про common navigation.

В чём соль? Несмотря на то, что common-модуль не знает о реализациях ваших destination-ов (фрагментах, диалогах, activity), он всё равно способен объявить граф навигации в XML-файлах! Да, Android Studio начинает сходить с ума: все имена классов в XML-е горят красным, но, несмотря на это, все нужные классы генерируются, Safe Args плагин работает как нужно. И так как ваши feature-модули подключают к себе common-модуль, они могут свободно использовать все сгенерированные классы и пользоваться любыми action-ами вашего графа навигации.

Плюс этого способа наконец-то можно пользоваться всеми возможностями Navigation Component-а в любом feature-модуле. Из минусов:

• добавился ещё один модуль в critical path каждого feature-модуля, которому потребовалась навигация;
• отсутствует автоматический рефакторинг имён: если вы поменяете имя класса какого-нибудь destination-а, вам нужно будет не забыть, что надо поправить его в common-модуле.

Выводы по навигации в многомодульных приложениях

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

Работа с диплинками

Практически каждое большое приложение должно уметь поддерживать диплинки. И практически каждый Android-разработчик мечтал о простом способе работы с этими глубокими ссылками. Окей, я мечтал. И казалось, что Navigation Component ровно то, что нужно.

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

У меня было три кейса с диплинками, которые я хотел реализовать с помощью Navigation Component.

• Открытие определённой вкладки нижней навигации допустим, я хочу через диплинк открыть вторую вкладку на главном экране после Splash-экрана

• Открытие определённого экрана ViewPager-а внутри конкретной вкладки нижней навигации

• Открытие экрана, который требует авторизации пользователя пусть теперь для корректной работы вкладки нижней навигации требуется авторизация. И с помощью диплинка я хочу сначала показать Splash-экран, затем открыть флоу авторизации, а когда пользователь его пройдёт, открыть нужную вкладку

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

Диплинк для определённой вкладки нижней навигации

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

<navigation xmlns:android="http://personeltest.ru/away/schemas.android.com/apk/res/android"    android:id="@+id/app_nav_graph"    app:startDestination="@id/SplashFragment">    <fragment        android:id="@+id/SplashFragment"        android:name="ui.splash.SplashFragment" />    <fragment        android:id="@+id/MainFragment"        android:name="ui.main.MainFragment">        <deepLink app:uri="www.example.com/main" />    </fragment></navigation>

Затем я, следуя документации, добавил граф навигации с диплинком в Android Manifest:

<manifest xmlns:android="http://personeltest.ru/away/schemas.android.com/apk/res/android"    package="com.aaglobal.jnc_playground">    <application android:name=".App">        <activity android:name=".ui.root.RootActivity">            <nav-graph android:value="@navigation/app_nav_graph"/>            <intent-filter>                <action android:name="android.intent.action.MAIN" />                <category android:name="android.intent.category.LAUNCHER" />            </intent-filter>        </activity>    </application></manifest>

А потом решил проверить, работает ли то, что я настроил при помощи простой adb-команды:

adb shell am start \  -a android.intent.action.VIEW \  -d "https://www.example.com/main" com.aaglobal.jnc_playground

И-и-и нет. Ничего не завелось. Я получил краш приложения с уже знакомым исключением IllegalStateException: FragmentManager is already executing transactions. Дебаггер указывал на код, связанный с настройкой нижней навигации, поэтому я решил просто обернуть эту настройку в очередной Handler.post:

// MainFragment.kt  fragment with BottomNavigationViewoverride fun onViewCreated(view: View, savedInstanceState: Bundle?) {    super.onViewCreated(view, savedInstanceState)    if (savedInstanceState == null) {        safeSetupBottomNavigationBar()    }}private fun safeSetupBottomNavigationBar() {    Handler().post {        setupBottomNavigationBar()    }}

Это исправило краш, но приложение всё равно работало неправильно: запустив диплинк, мы пропустили Splash-экран, он просто не запускался. А это означает, что не отрабатывал код, который отвечал за инициализацию моего приложения.

Это произошло, потому что в нашем случае путь диплинка был таким: мы запустили приложение, запустилась его единственная Activity. В вёрстке этой activity мы инициализировали первый граф навигации. В этом графе оказался элемент, который удовлетворял URI, мы отправили его через adb-команду вуаля, он сразу и открылся, проигнорировав указанный в графе startDestination.

Тогда я решил перенести диплинк в другой граф внутрь вкладки нижней навигации.

<navigation xmlns:android="http://personeltest.ru/away/schemas.android.com/apk/res/android"    android:id="@+id/menu__search"    app:startDestination="@id/SearchContainerFragment">    <fragment        android:id="@+id/SearchContainerFragment"        android:name="tabs.search.SearchContainerFragment">        <deepLink app:uri="www.example.com/main" />        <action            android:id="@+id/action__SearchContainerFragment__to__CompanyFlow"            app:destination="@id/company_flow__nav_graph" />        <action            android:id="@+id/action__SearchContainerFragment__to__VacancyFragment"            app:destination="@id/vacancy_nav_graph" />    </fragment></navigation>

И, запустив приложение, я получил ЭТО:

На гифке видно, как приложение запустилось, и мы увидели Splash-экран. После этого на мгновение показался экран с нижней навигацией, а затем приложение словно запустилось заново! Мы снова увидели Splash-экран, и только после его повторного прохождения появилась нужная вкладка нижней навигации.

И что самое неприятное во всей этой истории это не баг, а фича.

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

When a user opens your app via an explicit deep link, the task back stack is cleared and replaced with the deep link destination.

То есть наш back stack специально очищается, чтобы Navigation Component-у было удобнее работать с диплинками. Говорят, что когда-то давно, в бета-версии библиотеки всё работало адекватнее.

Мы можем это исправить. Корень проблемы в методе handleDeepLink NavController-а:

public void handleDeepLink(@Nullable Intent intent) {    // ...    if ((flags & Intent.FLAG_ACTIVITY_NEW_TASK) != 0) {        // Start with a cleared task starting at our root when we're on our own task        if (!mBackStack.isEmpty()) {            popBackStackInternal(mGraph.getId(), true);        }        int index = 0;        while (index < deepLink.length) {            int destinationId = deepLink[index++];            NavDestination node = findDestination(destinationId);            if (node == null) {                final String dest = NavDestination.getDisplayName(mContext, destinationId);                throw new IllegalStateException("Deep Linking failed:"                        + " destination " + dest                        + " cannot be found from the current destination "                        + getCurrentDestination());            }            navigate(node, bundle,                    new NavOptions.Builder().setEnterAnim(0).setExitAnim(0).build(), null);        }        return true;    }}

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

• почти полностью скопировать к себе исходный код Navigation Component;
• добавить свой собственный NavController с исправленной логикой (добавление исходного кода библиотеки необходимо, так как от NavController-а зависят практически все элементы библиотеки) назовём его FixedNavController;
• заменить все использования исходного NavController-а на FixedNavController.

Несложно, правда? Но кажется, что это уже слишком. Подобные исправления заставляют нас в будущем тратить всё больше и больше времени на поддержку нашего кастомного решения, ведь нужно будет обновлять свой фикс при каждом обновлении библиотеки. Около года назад коллеги из Яндекса столкнулись с похожей проблемой, и им пришлось делать примерно то же самое. Сочувствую.

В этот невесёлый момент я заметил ещё один баг, который был добавлен при попытке исправить краш с диплинками: сломалась обратная навигация из auth-флоу.

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

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

Диплинк на экран ViewPager-а внутри вкладки нижней навигации

Если у вас будет свой собственный NavController, корректно обрабатывающий диплинки, реализовать этот кейс будет просто.

В NavController-е есть специальный булевский флажок isDeepLinkHandled, который говорит нам, что текущий NavController успешно обработал диплинк. Вы могли бы добавить диплинк, ведущий на фрагмент, который содержит в себе ViewPager, затем написать примерно вот такой код, чтобы перейти на нужную вкладку:

if (findMyNavController().isDeepLinkHandled && requireActivity().intent.data != null) {    val uriString = requireActivity().intent.data?.toString()    val selectedPosition = when {        uriString == null -> 0        uriString.endsWith("favorites") -> 0        uriString.endsWith("subscribes") -> 1        else -> 2    }    fragment_favorites_container__view_pager.setCurrentItem(selectedPosition, true)}

Но, опять же, это будет доступно только в случае, если вы уже добавили к себе в кодовую базу свою реализацию NavController-а, ведь флаг isDeepLinkHandled является private-полем. Ок, можно достучаться до него через механизм reflection-а, но это уже другая история.

Диплинк на экран, требующий авторизацию

Navigation Component не поддерживает диплинки с условием из коробки. Если вы хотите поддержать такое поведение, Google предлагает действовать следующим образом:

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

Возможности глобально решить мою задачу средствами Navigation Component-а я не нашёл.

Выводы по работе с диплинками в Navigation Component

• Работать с ними больно, если требуется добавлять дополнительные действия или условия.
• Объявлять диплинки ближе к месту их назначения классная идея, в разы удобнее AndroidManifest-а со списком поддерживаемых ссылок.

Бонус-секция кейсы БЕЗ проблем

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

Навигация с экрана <A> в экран <A>

Допустим, у вас есть экран вакансий, с которого вы можете перейти на другую вакансию.

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

<fragment  android:id="@+id/VacancyFragment"  android:name="com.aaglobal.jnc_playground.ui.vacancy.VacancyFragment"  android:label="Fragment vacancy"  tools:layout="@layout/fragment_vacancy">  <argument      android:name="vacancyId"      app:argType="string"      app:nullable="false" />  <action      android:id="@+id/action__VacancyFragment__to__VacancyFragment"      app:destination="@id/VacancyFragment" /></fragment>

И этого оказалось достаточно новый экран открывался поверх старого, при нажатии на кнопку Back навигация была корректной. Если бы я захотел, чтобы каждый новый экран открывался вместо текущего, было бы достаточно добавить атрибут popUpTo к моему action-у.

Навигация из встраиваемых фрагментов

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

Я добавил контейнер для будущего фрагмента со списком в вёрстку вкладки нижней навигации:

<LinearLayout xmlns:android="http://personeltest.ru/away/schemas.android.com/apk/res/android"    android:layout_width="match_parent"    android:layout_height="match_parent"    android:orientation="vertical">    <TextView        android:id="@+id/fragment_favorites_container__text__title"        style="@style/LargeTitle"        android:text="Favorites container" />    <androidx.fragment.app.FragmentContainerView        android:id="@+id/fragment_favorites_container__container__recommend_vacancies"        android:layout_width="match_parent"        android:layout_height="match_parent" /></LinearLayout>

А затем в runtime-е добавил нужный мне фрагмент в этот контейнер:

class FavoritesContainerFragment : Fragment(R.layout.fragment_favorites_container) {    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {        super.onViewCreated(view, savedInstanceState)        childFragmentManager.attachFragmentInto(          containerId = R.id.fragment_container_view,          fragment = createVacancyListFragment()        )    }}

Метод attachFragmentInfo на childFragmentManager это extension-метод, который просто оборачивает всю работу с транзакциями, не более того.

А вот как я создал фрагмент:

class FavoritesContainerFragment : Fragment(R.layout.fragment_favorites_container) {    // ...    private fun createVacancyListFragment(): Fragment {        return VacancyListFragment.newInstance(          vacancyType = "favorites_container",          vacancyListRouterSource = object : VacancyListRouterSource {              override fun navigateToVacancyScreen(item: VacancyItem) {                  findNavController().navigate(                      R.id.action__FavoritesContainerFragment__to__VacancyFragment,                      VacancyFragmentArgs(vacancyId = "${item.name}|${item.id}").toBundle()                  )              }        }     }}

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

Навигация между диалогами

Пусть у меня есть несколько BottomSheetDialog-ов, между которыми я хочу перемещаться с помощью Navigation Component.

Год назад с таким кейсом были какие-то проблемы, но сейчас всё работает как надо. Можно легко объявить какой-то dialog в качестве destination-а в вашем графе навигации, можно добавить action для открытия диалога из другого диалога.

<navigation xmlns:android="http://personeltest.ru/away/schemas.android.com/apk/res/android"    android:id="@+id/menu__favorites"    app:startDestination="@id/FavoritesContainerFragment">   <dialog        android:id="@+id/ABottomSheet"        android:name="ui.dialogs.dialog_a.ABottomSheetDialog">        <action            android:id="@+id/action__ABottomSheet__to__BBottomSheet"            app:destination="@id/BBottomSheet"            app:popUpTo="@id/ABottomSheet"            app:popUpToInclusive="true" />    </dialog>    <dialog        android:id="@+id/BBottomSheet"        android:name="ui.dialogs.dialog_b.BBottomSheetDialog">        <action            android:id="@+id/action__BBottomSheet__to__ABottomSheet"            app:destination="@id/ABottomSheet"            app:popUpTo="@id/BBottomSheet"            app:popUpToInclusive="true" />    </dialog></navigation>

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

Выводы по бонус-секции

Кейсы без проблем существуют.

Подведём итоги

На данный момент нет никакой причины переводить большое приложение на Navigation Component. Слишком много проблем, слишком много костылей, постоянно нужно выдумывать что-то для осуществления не самых сложных кейсов навигации. Сам факт, что я ухитрился написать так много текста про проблемы с Navigation Component-ом, что-то да говорит.

Если у вас маленькое приложение, надо внимательно посмотреть на то, какие кейсы навигации вы хотите поддержать. Если задумываетесь про нижнюю навигацию, про диплинки пожалуй, лучше реализовать всё по-старинке: либо руками, либо на Cicerone. В остальных случаях, если вас не пугает необходимость постоянно искать фиксы, можно воспользоваться Navigation Component-ом.

Пример приложения на Github-е лежит здесь.

Полезные ссылки по теме

• Годичной давности статья от коллег из Яндекса про перевод приложения на Navigation Component; отдельно упоминают то, что если бы знали, сколько выхватят проблем, не стали бы ничего затаскивать.
• Хорошая статья про недостатки Navigation Component
• Документация по Navigation Component
• Что новенького в Navigation Component в 2020 году.
• Баг с BottomNavigationView

Встречайте Hilt Dependency Injection (DI) в JetPack, но это не правда, так как Hilt это просто обертка для Dagger2. Для небольших проектов сможет встать более удобным инструментом и хорошо интегрируется с остальными продуктами в JetPack.

Не буду описывать как добавить в проект, все хорошо описано в статье

Зачем?

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

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

Что упростили для нас:

• Готовые компоненты (из названий понятно к чему относятся)
  
  • ApplicationComponent
  • ActivityRetainedComponent
  • ActivityComponent
  • FragmentComponent
  • ViewComponent
  • ViewWithFragmentComponent
  • ServiceComponent
• В модуле указываешь в какой компонент добавить
• Через @AndroidEntryPoint Hilt компилятор генерирует весь bolierplate для создания компонента и хранения (например, ActivityRetainedComponent сохранит сущность после поворота экрана, ActivityComponent пересоздаст заново).

Такой код выглядит довольно элегантно (весь boilerplate за нас сгенерируется)

@AndroidEntryPointclass ExampleActivity : AppCompatActivity() {     @Inject lateinit var testService: TestService}

Особенности

Application обязателен

Необходимо объявить Application и пометить @HiltAndroidApp, без него Hilt не заработает.

@HiltAndroidAppclass App : Application() { }

Иерархическая зависимость

Если хотите использовать Hilt в фрагментах, то Activity которая содержит эти фрагменты обязательно помечать аннотацией @AndroidEntryPoint

Если View пометить @WithFragmentBindings то Fragment должен быть с аннотацией @AndroidEntryPoint, а без этой аннотации зависит от того куда инжектимся Activity или Fragment

Объявление модулей

Все как в Dagger2, но нет необходимости добавлять модуль в компонент, а достаточно использовать аннотацию @InstallIn. Это и понятно, так как компоненты не доступны для редактирования.

@InstallIn(ApplicationComponent::class)@Moduleclass NetworkModule {    @Singleton    @Provides    fun provideHttpService(): HttpService {        return object : HttpService {            init {                Log.e("Tester", "HttpService initialized")            }            override fun request() {                Log.e("Tester", "HttpService::request")            }        }    }}

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

Кастомные Component и Subcomponent

Создать их конечно можно, так как там Dagger2, но теряется тогда весь смысл Hilt и все придется писать вручную. Вот что предлагается в документации:

DaggerLoginComponent.builder()        .context(this)        .appDependencies(          EntryPointsAccessors.fromApplication(            applicationContext,            LoginModuleDependencies::class.java          )        )        .build()        .inject(this)

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

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

Ограничения для @AndroidEntryPoint

• Поддерживаются Activity наследуемые от ComponentActivity и AppCompatActivity
• Поддерживаются Fragment наследуемые от androidx.Fragment
• Не поддерживаются Retain фрагменты

Что внутри

Hilt работает следующим образом:

• Генерируются Dagger Component-ы
• Генерируются базовые классы для Application, Activity, Fragment, View и т.д, которые помечены аннотацией @AndroidEntryPoint
• Dagger компилятор генерирует статический коды

Как устроено хранение ActivityRetainedComponent

Не стали усложнять и просто поместили компонент в ViewModel из arch библиотеки:

this.viewModelProvider =        new ViewModelProvider(            activity,            new ViewModelProvider.Factory() {              @NonNull              @Override              @SuppressWarnings("unchecked")              public <T extends ViewModel> T create(@NonNull Class<T> aClass) {                ActivityRetainedComponent component =                    ((GeneratedComponentManager<LifecycleComponentBuilderEntryPoint>)                            activity.getApplication())                        .generatedComponent()                        .retainedComponentBuilder()                        .build();                return (T) new ActivityRetainedComponentViewModel(component);              }            });

Итог

Плюсы:

• Более простое использование чем Dagger2
• Добавление модулей через аннотацию выглядит довольно удобно (в несколько уже не поместишь)
• Код чище и много boilerpate спрятано.
• Все плюсы от Dagger2 (генерация статического кода, валидация зависимостей и т.д.)
• Удобен для небольших проектов

Минусы:

• Тяжело избавится, не только захочется убрать или заменить, но и просто перейти на Dagger2
• Тяжело добавить кастомные компоненты, что ограничивает использование с крупных проектах
• Наследует минусы Dagger2 и еще больше увеличивает время сборки
• Иерархическая зависимость, например, нельзя использовать в Fragment без Activity c @AndroidEntryPoint

Полезные ссылки:

• https://developer.android.com/training/dependency-injection/hilt-android
• https://developer.android.com/training/dependency-injection/hilt-multi-module
• https://medium.com/androiddevelopers/dependency-injection-on-android-with-hilt-67b6031e62d
• https://codelabs.developers.google.com/codelabs/android-dagger-to-hilt/

Два года назад на Google I/O Android-разработчикам представили новое решение для навигации в приложениях библиотеку Jetpack Navigation Component. Про маленькие приложения уже было сказано достаточно, а вот о том, с какими проблемами можно столкнуться при переводе большого приложения на Navigation Component, информации практически нет.

В этой и следующих двух статьях я расскажу о кейсах, с которыми может встретиться разработчик, желающий опробовать Navigation Component в большом Android-приложении.

Это текстовая версия моего выступления в рамках серии митапов по Android 11 в Android Academy. Само выступление было на английском, статью пишу на русском. Кому удобнее смотреть велкам.

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

Disclaimer

Я сделал пример, по структуре навигации повторяющий основные моменты навигации соискательского приложения hh.ru, и выхватил ряд проблем, о которых и собираюсь рассказать. Я основательно поресёрчил практическую сторону вопроса, но, разумеется, рассмотрел далеко не все возможные кейсы.

Схема моего тестового приложения выглядит так:

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

Кейсы с BottomNavigationView

Когда я только-только услышал про Navigation Component, мне стало интересно: как будет работать BottomNavigationView и как Google подружит несколько отдельных back stack-ов в разных вкладках. Два года назад с этим кейсом были некоторые проблемы, и я решил проверить, как там обстоят дела сегодня.

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

Первый опыт

Я установил Android Studio 4.1 Beta (последнюю более-менее стабильную версию на тот момент) и попробовал шаблон приложения с нижней навигацией. Начало было многообещающим.

• Мне сгенерировали Activity в качестве контейнера для хоста навигации и нижней навигации

<androidx.constraintlayout.widget.ConstraintLayout    android:id="@+id/container">    <com.google.android.material.bottomnavigation.BottomNavigationView        android:id="@+id/nav_view"        app:menu="@menu/bottom_nav_menu" />    <fragment        android:id="@+id/nav_host_fragment"        android:name="androidx.navigation.fragment.NavHostFragment"        app:defaultNavHost="true"        app:navGraph="@navigation/mobile_navigation" /></androidx.constraintlayout.widget.ConstraintLayout>

Стандартный ConstraintLayout, в который добавили BottomNavigationView и тэг <fragment> для инициализации NavHostFragment-а (Android Studio, кстати, подсвечивает, что вместо фрагмента лучше использовать FragmentContainerView).

• Для каждой вкладки BottomNavigationView был создан отдельный фрагмент

<navigation    android:id="@+id/mobile_navigation"    app:startDestination="@+id/navigation_home">    <fragment        android:id="@+id/navigation_home"        android:name="com.aaglobal.graph_example.ui.home.HomeFragment"/>    <fragment        android:id="@+id/navigation_dashboard"        android:name="com.aaglobal.graph_example.ui.dashboard.DashboardFragment"/>    <fragment        android:id="@+id/navigation_notifications"        android:name="com.aaglobal.graph_example.ui.notifications.NotificationsFragment"/></navigation>

Все фрагменты были добавлены в качестве отдельных destination-ов в общий граф навигации.

• А ещё в проект был добавлен файл-ресурс для описания меню BottomNavigationView

<menu xmlns:android="http://personeltest.ru/away/schemas.android.com/apk/res/android">    <item        android:id="@+id/navigation_home"        android:icon="@drawable/ic_home_black_24dp"        android:title="@string/title_home" />    <item        android:id="@+id/navigation_dashboard"        android:icon="@drawable/ic_dashboard_black_24dp"        android:title="@string/title_dashboard" />    <item        android:id="@+id/navigation_notifications"        android:icon="@drawable/ic_notifications_black_24dp"        android:title="@string/title_notifications" /></menu>

При этом я заметил, что идентификаторы элементов меню должны совпадать с идентификаторами destination-ов в графе навигации. Не самая очевидная связь между табами BottomNavigationView и фрагментами, но работаем с тем, что есть.

Пора запускать приложение

После создания приложения из шаблона я запустил его и сразу столкнулся с двумя проблемами.

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

Для проверки я добавил во вкладку Dashboard простенькую ViewModel со счётчиком. На гифке видно, как я переключаюсь со вкладки Home на вкладку Dashboard, увеличиваю счётчик до четырёх. После этого я переключился обратно на вкладку Home и вновь вернулся на Dashboard. Счётчик сбросился.

Баг с описанием этой проблемы уже два года висит в Issue Tracker-е. Чтобы решить её, Google-у потребовалось серьёзно переработать внутренности фреймворка Fragment-ов, чтобы поддержать возможность работать с несколькими back stack-ами одному FragmentManager-у. Недавно на Medium вышла статья Ian Lake, в которой он рассказывает, что Google серьёзно продвинулись в этом вопросе, так что, возможно, фикс проблемы с BottomNavigationView не за горами.

Вторая проблема следствие первой. По принятым принципам навигации, когда вы нажимаете на уже выбранную вкладку BottomNavigationView, вы должны вернуться на первый фрагмент в стеке текущей вкладки. Но когда это происходит, состояние этого первого фрагмента сбрасывается, так как сам фрагмент пересоздаётся.

Для демонстрации этой проблемы я добавил на вкладку Dashboard кнопку, которая ведёт на следующий экран. На гифке видно, как я переключаюсь на вкладку Dashboard, увеличиваю счётчик до трёх, а затем перехожу на экран Graphic. Если я нажимаю на кнопку Back то всё работает как надо, состояние вкладки не сбрасывается. Но если, находясь на экране Graphic, я ещё раз нажму на вкладку Dashboard, то после возврата на первый экран в стеке увижу, что его состояние сброшено.

Не самое лучшее первое впечатление, подумал я. И начал искать фикс.

У нас есть workaround

Решение этих проблем живёт в специальном репозитории Google-а с примерами работы с Architecture Components, в проекте NavigationAdvancedSample.

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

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

<?xml version="1.0" encoding="utf-8"?><navigation xmlns:android="http://personeltest.ru/away/schemas.android.com/apk/res/android"    xmlns:app="http://personeltest.ru/away/schemas.android.com/apk/res-auto"    xmlns:tools="http://personeltest.ru/away/schemas.android.com/tools"    android:id="@+id/navigation_home"    app:startDestination="@id/HomeFragment">    <fragment        android:id="@+id/HomeFragment"        android:name="com.aaglobal.jnc_playground.ui.home.HomeFragment"        android:label="@string/title_home"        tools:layout="@layout/fragment_home" /></navigation>

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

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

private fun obtainNavHostFragment(    fragmentManager: FragmentManager,    fragmentTag: String,    navGraphId: Int,    containerId: Int): NavHostFragment {    // If the Nav Host fragment exists, return itval existingFragment = fragmentManager.findFragmentByTag(fragmentTag) as NavHostFragment?    existingFragment?.let { return it }    // Otherwise, create it and return it.    val navHostFragment = NavHostFragment.create(navGraphId)    fragmentManager.beginTransaction()        .add(containerId, navHostFragment, fragmentTag)        .commitNow()    return navHostFragment}

FragmentManager пока что не поддерживает работу с множеством back stack-ов одновременно, поэтому пришлось придумать альтернативное решение, которое позволило ассоциировать с каждым графом свой back stack. Им стало создание отдельного NavHostFragment-а для каждого графа. Из этого следует, что с каждой вкладкой BottomNavigationView у нас будет связан отдельный NavController.

• В-третьих, мы устанавливаем в BottomNavigationView специальный listener, который будет заниматься переключением между back stack-ами фрагментов

setOnNavigationItemSelectedListener { item ->  val newlySelectedItemTag = graphIdToTagMap[item.itemId]  if (selectedItemTag != newlySelectedItemTag) {    fragmentManager.popBackStack(firstFragmentTag, FragmentManager.POP_BACK_STACK_INCLUSIVE)    val selectedFragment = fragmentManager.findFragmentByTag(newlySelectedItemTag)        as NavHostFragment    if (firstFragmentTag != newlySelectedItemTag) {      fragmentManager.beginTransaction()        .attach(selectedFragment)        .setPrimaryNavigationFragment(selectedFragment).apply {          graphIdToTagMap.forEach { _, fragmentTagIter ->            if (fragmentTagIter != newlySelectedItemTag) {              detach(fragmentManager.findFragmentByTag(firstFragmentTag)!!)            }          }        }        .addToBackStack(firstFragmentTag)        .setReorderingAllowed(true)        .commit()    }    selectedNavController.value = selectedFragment.navController    true  } else {    false  }}

В прикреплённом кусочке кода мы видим, как при переключении между вкладками BottomNavigationView выполняется специальная транзакция в FragmentManager-е, которая прикрепляет фрагмент выбранной вкладки и отцепляет все остальные фрагменты. По сути, так мы и переключаемся между различными back stack-ами.

• В итоге метод настройки BottomNavigationView возвращает разработчику специальную LiveData, которая содержит в себе NavController выбранной вкладки. Этот NavController можно использовать, например, для обновления надписи на ActionBar-е

class RootActivity : AppCompatActivity(R.layout.activity_root) {  private var currentNavController: LiveData<NavController>? = null  private fun setupBottomNavigationBar() {      // Setup the bottom navigation view with a list of navigation graphs      val liveData = bottom_nav.setupWithNavController(          navGraphIds = listOf(            R.navigation.home_nav_graph,            R.navigation.dashboard_nav_graph,            R.navigation.notifications_nav_graph          ),          fragmentManager = supportFragmentManager,          containerId = R.id.nav_host_container,          intent = intent      )      // Whenever the selected controller changes, setup the action bar.      liveData.observe(this, Observer { ctrl -> setupActionBarWithNavController(ctrl) })      currentNavController = liveData  }}

Метод для настройки BottomNavigationView вызывают в onCreate-е, когда Activity создаётся в первый раз, затем в методе onRestoreInstanceState, когда Activity пересоздаётся с помощью сохранённого состояния.

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

Опять же, не самая очевидная связь между этими элементами, зато работает.

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

Адаптация workaround-а для фрагментов

Очень здорово, что workaround помог решить основную проблему с сохранением состояний, но этих фиксов мне было недостаточно. Пример из проекта NavigationAdvancedSample использовал в качестве контейнера нижней навигации Activity, мне же нужен был фрагмент.

Я добавил вёрстку для фрагмента с нижней навигацией и перенёс настройку BottomNavigationView во фрагмент:

class MainFragment : Fragment(R.layout.fragment_main) {    private var currentNavController: LiveData<NavController>? = null    override fun onViewStateRestored(savedInstanceState: Bundle?) {        super.onViewStateRestored(savedInstanceState)        setupBottomNavigationBar()    }    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {        super.onViewCreated(view, savedInstanceState)        if (savedInstanceState == null) {            setupBottomNavigationBar()        }    }}

Я добавил в свой пример Splash-экран и дополнительную вкладку для BottomNavigationView. А чтобы пример стал ещё более походить на приложение для соискателей hh.ru, я также убрал из него ActionBar.

Для этого я поменял тему приложения с Theme.MaterialComponents.DayNight.DarkActionBar на Theme.MaterialComponents.DayNight.NoActionBar и убрал код для связки NavController-а с ActionBar-ом:

class MainFragment : Fragment(R.layout.fragment_main) {    private var currentNavController: LiveData<NavController>? = null    private fun setupBottomNavigationBar() {        val navGraphIds = listOf(            R.navigation.search__nav_graph,            R.navigation.favorites__nav_graph,            R.navigation.responses__nav_graph,            R.navigation.profile__nav_graph        )        val controller = bottom_navigation.setupWithNavController(            navGraphIds = navGraphIds,            fragmentManager = requireActivity().supportFragmentManager,            containerId = R.id.fragment_main__nav_host_container,            intent = requireActivity().intent        )        currentNavController = controller    }}

После всех манипуляций я включил режим Don't keep activities, запустил свой пример и получил краш при сворачивании приложения.

На гифке видно, как я запустил приложение, и после Splash-экрана показывается экран с нижней навигацией. После этого мы сворачиваем приложение и получаем краш.

В чём была причина? При вызове onDestroyView активный NavHostFragment пытается отвязаться от NavController-а. Так как мой фрагмент-контейнер с нижней навигацией никак не привязывал к себе NavController, который он получил из LiveData, метод Navigation.findNavController из onDestroyView крашил приложение.

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

class MainFragment : Fragment(R.layout.fragment_main) {    private var currentNavController: LiveData<NavController>? = null    private fun setupBottomNavigationBar() {        ...        currentNavController?.observe(            viewLifecycleOwner,            Observer { liveDataController ->                Navigation.setViewNavController(requireView(), liveDataController)            }        )    }}

Но это ещё не всё. Не выключая режим Don't keep activities, я попробовал свернуть, а затем развернуть приложение. Оно снова упало, но с другим неприятным исключением IllegalStateException в FragmentManager FragmentManager already executing transactions.

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

Краш происходит в методах, которые прикрепляют NavHostFragment к FragmentManager-у после их создания. Это исключение можно исправить при помощи костыля: обернуть методы attach-detach в Handler.post {}.

// NavigationExtensions.ktprivate fun attachNavHostFragment(    fragmentManager: FragmentManager,    navHostFragment: NavHostFragment,    isPrimaryNavFragment: Boolean) {  Handler().post {    fragmentManager.beginTransaction()    .attach(navHostFragment)    .apply {      if (isPrimaryNavFragment) {        setPrimaryNavigationFragment(navHostFragment)      }    }    .commitNow()  }}

После добавления Handler.post приложение заработало, как надо.

Выводы по работе с BottomNavigationView

• Использовать BottomNavigationView в связке с Navigation Component можно, если знать, где искать workaround-ы.
• Если вы захотите иметь фрагмент в качестве контейнера нижней навигации BottomNavigationView, будьте готовы искать дополнительные фиксы для ваших проблем, так как скорее всего я поймал не все возможные краши.

На этом с BottomNavigationView всё, на следующей неделе расскажу про кейсы с вложенными графами навигации.