⚙️ Мигрировать на Navigation 3 можно, но только всё приложение разом. И это не единственная засада
Честный кейс от разработчицы: она в одиночку перевела приложение на 170+ экранов с Nav2 на Nav3 🤯. Не пересказ доков, а грабли из прода. Объем работы: 302 файла (по сути весь app), 2 недели разработки с овертаймами, ~1.5 недели стабилизации, 1 хотфикс.
Что стоит забрать себе ещё до старта:
Поэтапно не выйдет. Обратной совместимости между Nav2 и Nav3 нет, мигрируешь либо всё сразу, либо никак. Отсюда огромный affected area и главная организационная боль: команда не фризила разработку, коллеги параллельно пилили новые экраны на старой навигации. Чем дольше тянешь, тем дороже разгребать merge-конфликты.
Bottom Sheets из коробки в навигации нет. Пришлось городить обёртку вокруг entry с флагом в metadata и вручную разруливать, что рисовать через ModalBottomSheetLayout, а что через NavDisplay:
val NavEntry.isBottomSheet: Boolean
get() = metadata["isBottomSheet"] as? Boolean == true
NavDisplay(
entries = navigationState.toEntries(mainEntryProvider)
.filter { it.isBottomSheet.not() },
onBack = { navigator.goBack() },
)
Сейчас это решается официально через BottomSheetSceneStrategy, свой костыль автор потом выкинула. Мигрируешь сегодня — сразу проверь, что шторки ложатся на SceneStrategy, а не переоткрывай этот велосипед. ⚠️ И отдельный подвох: шторка часть стека, и если перед переходом на следующий экран не закрыть её руками, back вернёт её обратно. Легко забыть.
Сериализация уронит тебя уже в проде. 💥 Всё, что прокидываешь через навигацию, должно быть @Serializable. Автор прокинула entryPoint: NavKey (чтобы при блокировке юзера возвращать на нужный экран через несколько назад), а сам NavKey сериализуемым не был:
Fatal Exception: kotlinx.serialization.SerializationException
Ловушка в том, что краш не в обычном флоу, а в отдельных сценариях восстановления, поэтому проходит ревью и ручные тесты, а ловится только у юзеров. Лечится обёрткой:
@Serializable
open class NavStateSerializable : NavKey
Мой вывод: миграция оправданная, если на карте планшеты/фолды и adaptive layouts (тут Nav3 реально снимает боль), а навигация уже на Compose. Но держи в голове, что это не «обновить либу», а big-bang рефактор с регрессиями. Я бы не лез, если сидишь на фрагментах (сначала выпиливать их), поджимают сроки или свой навигатор и так стабильно работает.
🔗 Полный разбор с кодом и схемами на Medium
#Compose #Navigation3 #Android
Честный кейс от разработчицы: она в одиночку перевела приложение на 170+ экранов с Nav2 на Nav3 🤯. Не пересказ доков, а грабли из прода. Объем работы: 302 файла (по сути весь app), 2 недели разработки с овертаймами, ~1.5 недели стабилизации, 1 хотфикс.
Что стоит забрать себе ещё до старта:
Поэтапно не выйдет. Обратной совместимости между Nav2 и Nav3 нет, мигрируешь либо всё сразу, либо никак. Отсюда огромный affected area и главная организационная боль: команда не фризила разработку, коллеги параллельно пилили новые экраны на старой навигации. Чем дольше тянешь, тем дороже разгребать merge-конфликты.
Bottom Sheets из коробки в навигации нет. Пришлось городить обёртку вокруг entry с флагом в metadata и вручную разруливать, что рисовать через ModalBottomSheetLayout, а что через NavDisplay:
val NavEntry.isBottomSheet: Boolean
get() = metadata["isBottomSheet"] as? Boolean == true
NavDisplay(
entries = navigationState.toEntries(mainEntryProvider)
.filter { it.isBottomSheet.not() },
onBack = { navigator.goBack() },
)
Сейчас это решается официально через BottomSheetSceneStrategy, свой костыль автор потом выкинула. Мигрируешь сегодня — сразу проверь, что шторки ложатся на SceneStrategy, а не переоткрывай этот велосипед. ⚠️ И отдельный подвох: шторка часть стека, и если перед переходом на следующий экран не закрыть её руками, back вернёт её обратно. Легко забыть.
Сериализация уронит тебя уже в проде. 💥 Всё, что прокидываешь через навигацию, должно быть @Serializable. Автор прокинула entryPoint: NavKey (чтобы при блокировке юзера возвращать на нужный экран через несколько назад), а сам NavKey сериализуемым не был:
Fatal Exception: kotlinx.serialization.SerializationException
Ловушка в том, что краш не в обычном флоу, а в отдельных сценариях восстановления, поэтому проходит ревью и ручные тесты, а ловится только у юзеров. Лечится обёрткой:
@Serializable
open class NavStateSerializable : NavKey
Мой вывод: миграция оправданная, если на карте планшеты/фолды и adaptive layouts (тут Nav3 реально снимает боль), а навигация уже на Compose. Но держи в голове, что это не «обновить либу», а big-bang рефактор с регрессиями. Я бы не лез, если сидишь на фрагментах (сначала выпиливать их), поджимают сроки или свой навигатор и так стабильно работает.
🔗 Полный разбор с кодом и схемами на Medium
#Compose #Navigation3 #Android