Комментарии 13
Это перевод?
НЛО прилетело и опубликовало эту надпись здесь
Так у вас нет декларативного подхода. Замена push на pushNamed не меняет императивный код на декларативный. Декларативный навигатор появится в Navigator 2.0.
Согласен, но именно вызов метода pushNamed декларативен, так как знание о переходе скрыто от потребителя. То есть знание каким образом, как и куда реализовано в другом месте.
По поводу Navigator 2.0 я общался с @chunhtai пару месяцев назад и предлагал свою помощь. Точные сроки выхода нового принципа навигации никто не может назвать, но вдохновлялись Angular.
По поводу Navigator 2.0 я общался с @chunhtai пару месяцев назад и предлагал свою помощь. Точные сроки выхода нового принципа навигации никто не может назвать, но вдохновлялись Angular.
вызов метода pushNamed декларативен
Нет, это обычный императивный метод. Сокрытие реализации != декларативность.
Декларативность подразумевает, что вы описываете желаемый результат. В случае навигации вы можете, например, описать, какие страницы лежат у вас в стеке (что и будет сделано в Navigator 2.0). В императивном подходе вы используете инструкции, чтобы изменить состояние программы. pushNamed – это и есть такая инструкция.
The navigator manages a stack of Route objects and provides two ways for managing the stack, the declarative API Navigator.pages or imperative API Navigator.push and Navigator.pop.
api.flutter.dev/flutter/widgets/Navigator-class.html
api.flutter.dev/flutter/widgets/Navigator-class.html
Тут все описано как бы в формате что есть просто один стек экранов.
В реальном проекте скорее смешаны tabs/stacks, и какой-то элемент стека тоже может быть стек, вот про это бы почитать.
В реальном проекте скорее смешаны tabs/stacks, и какой-то элемент стека тоже может быть стек, вот про это бы почитать.
Предположим, у нас приложение состоит из нескольких страниц, пользователь между ними переходит при помощи вот такого подхода:
(или любого другого, в котором происходит создание нового виджета-страницы new MyPage()), пользователь при этом не пользуется кнопкой «назад» (вполне типичный сценарий).
В этом случае у нас каждый раз создается объект страницы MyPage, и остается в памяти, в стеке навигатора.
Вопрос: когда он от туда будет удален и не произойдет ли переполнение памяти этими объектами?
Navigator.push(MaterialPageRoute(builder: (BuildContext context) => MyPage()));(или любого другого, в котором происходит создание нового виджета-страницы new MyPage()), пользователь при этом не пользуется кнопкой «назад» (вполне типичный сценарий).
В этом случае у нас каждый раз создается объект страницы MyPage, и остается в памяти, в стеке навигатора.
Вопрос: когда он от туда будет удален и не произойдет ли переполнение памяти этими объектами?
Как только закрывается экран пользователем или программно в бизнес логике, так сразу он буде удалён из истории. Пользователь может нажать физическую кнопку назад на своём устройстве, либо использовать программную в приложении для удаления.
Утечек памяти нет. По поводу переполнения могу сказать одно, сделал эксперимент с открытием 100 экранов в дереве и всё работало прекрасно!
Утечек памяти нет. По поводу переполнения могу сказать одно, сделал эксперимент с открытием 100 экранов в дереве и всё работало прекрасно!
Что значит «закрывается экран»? когда пользователь переходит на новый экран при помощи
Navigator.push(MaterialPageRoute(builder: (BuildContext context) => MyPage()));
старый экран закрывается?
(100 экранов — это хорошо, но что будет на 101 экране? или на телефоне с меньшим количеством памяти или с более тяжелыми страницами?)
Я рассуждаю так: если пользователь может «бесконечно» долго переходить на новый экран и у пользователя всегда есть возможность вернуться к предыдущим экранам кнопкой «назад», то это означает что все прежние экраны остаются в памяти, а значит она рано или поздно закончиться, и вот тут то произойдет что-то нехорошее (тормоза или аварийное завершение).
Так вот я предлагаю эту мою идею или подтвердить (и найти другой способ навигации) или опровергнуть и перестать волноваться и наслаждаться бесконечной глубиной навигации.
Navigator.push(MaterialPageRoute(builder: (BuildContext context) => MyPage()));
старый экран закрывается?
(100 экранов — это хорошо, но что будет на 101 экране? или на телефоне с меньшим количеством памяти или с более тяжелыми страницами?)
Я рассуждаю так: если пользователь может «бесконечно» долго переходить на новый экран и у пользователя всегда есть возможность вернуться к предыдущим экранам кнопкой «назад», то это означает что все прежние экраны остаются в памяти, а значит она рано или поздно закончиться, и вот тут то произойдет что-то нехорошее (тормоза или аварийное завершение).
Так вот я предлагаю эту мою идею или подтвердить (и найти другой способ навигации) или опровергнуть и перестать волноваться и наслаждаться бесконечной глубиной навигации.
Кирилл, будет здорово, если укажете, что картинку взяли у меня из статьи Dependency Injection
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Детальный разбор навигации в Flutter