Ответ
Navigator 1.0 — это императивный API для управления навигацией, основанный на стеке объектов Route. Он предоставляет простые методы для перехода между экранами (страницами).
Основные методы:
Navigator.push(context, route)— добавляет новый маршрут в стек.Navigator.pop(context)— удаляет текущий маршрут из стека, возвращаясь назад.Navigator.pushReplacement(context, newRoute)— заменяет текущий маршрут новым.Navigator.pushAndRemoveUntil(context, newRoute, (route) => false)— добавляет новый маршрут и удаляет все предыдущие из стека.
Пример использования:
// Переход на экран DetailsScreen
Navigator.push(
context,
MaterialPageRoute(builder: (context) => const DetailsScreen()),
);
// Возврат на предыдущий экран
Navigator.pop(context);Когда использовать:
- Для простых приложений с предсказуемым линейным потоком экранов.
- Когда не требуется сложная обработка глубоких ссылок (deep links) или декларативная конфигурация навигации.
Недостаток: Управление состоянием навигации (стеком) и синхронизация его с URL (на Web) или deep links (на мобильных) становится сложной задачей в больших приложениях, что привело к появлению Navigator 2.0 (Router API).
Ответ 18+ 🔞
А, ну вот, классика, ебать мои старые костыли! Сейчас объясню, что к чему, пока не начался этот ёперный театр с новыми API.
Представь себе, что твоё приложение — это такая книжка. Navigator 1.0 — это самый простой и тупой способ в ней листать страницы. Никаких умных оглавлений, просто тыкаешь пальцем: «Хочу на следующую страницу!» или «Ой, назад!».
Как это работает, ёпта? Всё крутится вокруг стека маршрутов — это как стопка тарелок. Каждый экран — это тарелка.
Navigator.push(context, route)— это когда ты сверху кладёшь новую чистую тарелку. Все видят её, а старые под ней лежат.Navigator.pop(context)— это когда ты снимаешь верхнюю тарелку и кидаешь её в раковину. Снова видна предыдущая.Navigator.pushReplacement(context, newRoute)— хитрый манёвр. Ты аккуратно вынимаешь верхнюю тарелку, а вместо неё кладёшь другую. Остальные под ней не трогаются.Navigator.pushAndRemoveUntil(context, newRoute, (route) => false)— это уже отчаяние, чувак. Ты берёшь и выгребаешь всю стопку тарелок в раковину, оставляя только одну, новую. Чистота, порядок, но иногда жалко.
Вот, смотри, как это в коде выглядит, тут всё просто:
// Показываем пользователю экран с деталями (кладём новую тарелку)
Navigator.push(
context,
MaterialPageRoute(builder: (context) => const DetailsScreen()),
);
// Пользователь нажал "назад" — убираем эту тарелку
Navigator.pop(context);Так когда же этим пользоваться? Да когда у тебя приложение — проще пареной репы. Типа, открыл список, тыкнул на элемент — перешёл в детали, нажал назад — вернулся в список. Всё линейно, предсказуемо, никаких тебе хитрых переходов из уведомлений или по ссылкам из браузера.
А в чём же подвох, спросишь ты? А подвох в том, что когда твоё приложение вырастает из коротких штанишек, этот подход начинает бздеть на все лады. Тебе самому приходится вручную следить за этой кучей тарелок-маршрутов. Хочешь, чтобы ссылка в браузере вела на конкретный экран? Придётся городить огород. Глубокие ссылки из уведомления? Тот ещё геморрой. Синхронизировать URL с тем, что видит пользователь? Доверия ебать ноль, что не накосячишь.
В общем, для мелких проектов — огонь, всё интуитивно. Но как только логика усложняется, ты сам от себя охуеешь, пытаясь это поддерживать. Поэтому умные дядьки и придумали Navigator 2.0 (Router API), где ты не тарелками швыряешься, а декларативно описываешь, какое у тебя должно быть состояние навигации, а система уже сама решает, как его добиться. Но это уже совсем другая история, с приключениями и овердохуищей бойлерплейта.