На чем была реализована навигация до Jetpack Compose

Что проверяют

Сколько лет вы в платформе и приходилось ли вам держать легаси. Вопрос звучит как исторический, но практический смысл прямой: почти в каждом живом проекте есть экраны на View и XML, и работать с ними придётся. Заодно смотрят, отличаете ли вы разметку экрана от механизма переходов между экранами.

Как отвечать

Разверните хронологию и назовите, чем платили за каждый шаг.

• Экран как Activity, переходы через Intent, передача данных через extras, возврат результата через startActivityForResult. Просто, но состояние живёт в системе, а не в приложении.
• Подход Single Activity и фрагменты: FragmentManager.beginTransaction(), затем replace или add, addToBackStack и commit. Аргументы через Bundle, бэкстек фрагментов на совести разработчика.
• Сторонние роутеры: Cicerone, где навигация вынесена из UI в отдельный слой, и Conductor с контроллерами вместо фрагментов.
• Navigation Component в составе Jetpack: граф навигации в XML, NavController, NavHost, типизированные аргументы через Safe Args, диплинки, вложенные графы.

Полезно закончить преемственностью: тот же компонент работает с Compose через NavHost из navigation-compose, так что знание графов не устарело. И назовите боли той эпохи: падение commit после сохранения состояния, ручное восстановление бэкстека, нетипизированные аргументы, несколько стеков под нижней навигацией.

Где спотыкаются

Первое: путают FragmentManager и FragmentTransaction. Методы add, replace, remove и commit принадлежат транзакции, менеджер её только открывает и хранит бэкстек.

Второе: называют точный год выхода библиотеки и промахиваются. Достаточно сказать «появилась в составе Jetpack», проверять вас будут не на датах.

Третье: отвечают «до Compose был XML» и замолкают. Это ответ про разметку, а спрашивали про навигацию, и разница между setContentView и графом переходов тут принципиальна.