Урок 12: Навигация – Base Compose Navigation

Введение

Зачем нам навигация?

• Экран авторизации: чтобы войти (или зарегистрироваться).
• Главный экран: условная домашняя страница.
• Список данных: будь то уроки, статьи или товары.
• Экран деталей: детальная страница выбранного элемента.
• …и так далее.

Способы реализовывать навигацию

1. Переходы с Activity на Activity

2. Фрагменты и NavController (до Compose)

3. “Чистый” Compose-подход (без библиотек)

• Плюсы: абсолютный минимализм, прямая декларативность. Просто меняем переменную — UI перестраивается.
• Минусы: при большом числе экранов придется вручную возиться со стеком экранов, аргументами, анимациями и возвратом назад — это чистая боль. Для крупных проектов совершенно неприемлемо.

4. Navigation Compose (рекомендуемый в 90% продакшн-проектов)

Минимальный пример навигации в Jetpack Compose

Подготавливаем проект к реализации “чистой” навигации

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        enableEdgeToEdge()
        setContent {
            MyApplicationTheme {
                Scaffold { innerPadding ->
                    Box(
                        modifier = Modifier
                            .fillMaxSize()
                            .padding(innerPadding)
                    ) {
                        AppNavigation()
                    }
                }
            }
        }
    }
}

Создаем “свою” навигацию (AppNavigation)

• currentScreen — это “строка-состояние” (по-хорошему, можно сделать sealed class – это позволяет создавать строго ограниченный набор подтипов, но для примера оставим так). Для нее реализуем стейт, с которым мы уже познакомились ранее. Значение по умолчание будет ”first”, чтобы сразу показывался первый экран.
• Через when проверяем, какое значение хранит стейт в данный момент при рекомпозиции.
• Если "first", то рендерим FirstScreen. Иначе "second" – SecondScreen.
• Сами экраны при вызове будут принимать единственный параметр – коллбэк onNextClick – он будет дергать изменение стейта с новым значением currentScreen, чем вызывать рекомпозицию функции AppNavigation() с отрисовкой нового экрана.

@Composable
fun AppNavigation() {

    val currentScreen = remember { mutableStateOf("first") }

    when (currentScreen.value) {
        "first" -> FirstScreen(
            onNextClick = {
                currentScreen.value = "second"
            },
        )

        "second" -> SecondScreen(
            onBackClick = {
                currentScreen.value = "first"
            },
        )
    }
}

Реализуем сами экраны (FirstScreen и SecondScreen)

@Composable
fun FirstScreen(
    onNextClick: () -> Unit,
) {
    Box(
        modifier = Modifier
            .fillMaxSize()
            .background(Color.LightGray),
        contentAlignment = Alignment.Center
    ) {
        Button(
            onClick = onNextClick
        ) {
            Text(text = "Перейти на SecondScreen")
        }
    }
}

@Composable
fun SecondScreen(
    onBackClick: () -> Unit,
) {
    Box(
        modifier = Modifier
            .fillMaxSize()
            .background(Color.Gray),
        contentAlignment = Alignment.Center
    ) {
        Button(
            onClick = onBackClick
        ) {
            Text(text = "Вернуться на FirstScreen")
        }
    }
}

Почему в продакшене такое не используют?

1. Отсутствие управления BackStack.
   При создании навигации на фрагментах через navGraph – при каждом новом переходе новые фрагменты складывались в стек. То есть, например, при такой реализации, если бы мы перешли с первого экрана на второй – они бы сложились в цепочку. Что это дает? При нажатии на кнопку “Назад” на устройстве – осуществится навигация на предыдущий экран в стэке.
   Однако, если мы попытаемся нажать “Назад” на втором экране сейчас – произойдет выход из приложения. Стэка нет, возвращаться некуда. Таким образом обработку BackStack требуется реализовывать вручную. В каких случаях делать popBackStack, куда возвращаться, что будет, если экраны идут цепочкой (A → B → C)? Это быстро становится громоздко.

2. Проблемы с аргументами.
   Передача аргументов при ручной навигации — это еще одна серьезная сложность. Например, если нам нужно передать на SecondScreen какой-то идентификатор, можно сделать это через строку. То есть буквально в строке currentScreen добавляем через слэш нужные нам данные. Но это только намеренно утрированный пример, в проде и даже в своих проектах так делать не следует.
   Все аргументы передаются как часть строки – это быстро становится нечитабельным. При сложных аргументах (например, объект данных) придется самим превращать объект в строку и обратно, увеличивая риск багов. Ну и еще много других сложностей с аргументами.

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

4. Наконец самое важное — состояние экрана не сохраняется. При “ручном” переключении через when(currentScreen), мы фактически заново вызываем метод экрана, когда возвращаемся с другого. Это значит, что все локальные переменные, LiveData-потоки, позиция в списке и прочие данные будут созданы заново. То есть это не рекомпозиция, где учитывается состояние, а вызов функции “как в первый раз”. Конечно, можно руками обыграть это через rememberSaveable или делать отдельные ViewModel, но это всё превращается в трудоемкий ручной костыль, тогда как в системах с полноценной навигацией это поставляется “из коробки”.