Лично я вижу, что мелкомягкие понимают: если изменить все сразу, то наше заранее готовое недовольство выйдет через край. А тут вроде UX почти тот же, а выглядит лучше + надеюсь работает быстрее.
у меня еще старый вид.
я рад что с этим убогим видом стали что-то делать
Спасибо за очередную шикарную статью! Я в игры не играю (не сложилось), но единственная купленная мной игра — это King Arthur's Gold за ее графику.
Так же не в целях рекламы (я не имею никакого отношения к этой программе) могу всем увлекающимся посоветовать крутой редактор фоток в 8битную графику: 8Bit Photo Lab, Retro Effects
Ничего вам не мешает хранить команды. Они все приходят в навигатор, здесь можно придумать какой-то массив команд и складывать его в бандл при умирании.
Такие вещи могут превратить библиотеку во фреймворк, то есть внутри будет много собственной логики о которой надо будет постоянно помнить, а кому-то она может не подойти и тогда придется опять переделывать.
Cicerone решает проблему передачи навигационных вызовов, но не сохранения стека навигации. Cicerone отвечает за то, что команды навигации гарантировано дойдут до навигатора, но не сохраняет их для полного восстановления состояния приложения. (представьте как восстановить цепочку из смеси Activity и Fragment'ов)
Мы не хотели писать свой FragmentManager + ActivityStack + и тд.
У себя мы тоже используем Moxy. А за восстановление навигации отвечает сам андроид.
А если это другая ошибка? Тогда нам надо все презентеры подписать на все ошибки? Я же говорю, решить можно по-разному, но SystemMessage поможет в некоторых случаях сделать это проще и изящнее.
Еще хочу подчеркнуть важную деталь: SystemMessage создана для показа сообщений именно при навигации, то есть это можно рассматривать как некоторое состояние в навигации. Неправильно использовать эту команду просто для показа сообщений на экранах. Это ответственность Вью. SystemMessage не умеет обрабатывать клик или еще что-то, это только сообщение пользователю о случившемся переходе.
В MVP не предполагается использование разных презентеров для одной вью. Вью имеет доступ к конкретному презентеру. Зачем там интерфейс? Какие публичные методы он будет скрывать? Для кого?
Мокси реализует чистый архитектурный подход. Не надо ломать принципы
1) Экран D показан не будет, так как смена экранов происходит быстрее. И все зависит от задачи. Можно сделать возврат не к конкретному экрану, а "на два назад", если экраны аутентификации попадают в общую цепочку. Такие случаи решаются расширением роутера. Для этого библиотека и создавалась гибкой.
Другой вариант: делать аутентификацию в отдельном активити с локальной цепочкой экранов.
2) Вы описываете типичный кейс бизнес логики. Если вы хотите, можно создать для таких случаев отдельную команду навигации. Повторюсь, что все для этого готово. Библиотека включает в себя необходимый минимум, если стараться учесть все кейсы, то маленькое решение превратится в гигантского монстра!
Возможно в будущем мы и добавим что-то еще, но на данный момент это не кажется критичным
1) Если я вас правильно понял, то вы спрашиваете про такой случай:
до перехода (F — активный экран)
a -> b -> c -> d -> e -> F
после перехода (G — активный экран)
a -> b -> c -> d -> G
Это решается методом в роутере:
public void customTransition() {
backTo("d");
forward("g");
}
2) Запрещать возвращаться на экран? Это как? Зачем тогда его оставлять в цепочке?
Спасибо за очередной дайджест!
ЗЫ: У вас в секцию Андроид попало пару ссылок про иОС.
у меня еще старый вид.
я рад что с этим убогим видом стали что-то делать
Спасибо за очередную шикарную статью! Я в игры не играю (не сложилось), но единственная купленная мной игра — это King Arthur's Gold за ее графику.
Так же не в целях рекламы (я не имею никакого отношения к этой программе) могу всем увлекающимся посоветовать крутой редактор фоток в 8битную графику: 8Bit Photo Lab, Retro Effects
вы называете "костылем" особенность реализации. Это как назвать "костылем" аккумуляторы у Теслы, исправляющие баг с невозможностью ездить на бензине.
Да, а что это? Сам не нашел. Находил только слои, но группировка объектов в слой не группирует их в объект — это очень неудобно.
Мне в Inkscape очень не хватает человеческого просмотра дерева элементов. Там только сухой XML.
Если календарь не впечатлил, то может это? Все тот же парень
А что там не так с CMYK? Она есть в панели управления цветом
Nick Saporito
Очень советую этот канал на Youtube — парень творит чудеса в InkScape.
Здорово помогает в изучении этого редактора!
Правильно я понял, что наличие BLE маяков необязательно? В таком случае интересно узнать точность навигации в помещении только по WIFI и другим сетям.
Напоминает историю с вк аудио плеерами. Каждый пишет свой. Хотя, как обучалка для начинающих знакомство с Electron сойдет.
Для всех интересующихся: добавил в Sample приложение экран со сложной параллельной навигацией (в каждом табе свой стек экранов).
Ничего вам не мешает хранить команды. Они все приходят в навигатор, здесь можно придумать какой-то массив команд и складывать его в бандл при умирании.
Такие вещи могут превратить библиотеку во фреймворк, то есть внутри будет много собственной логики о которой надо будет постоянно помнить, а кому-то она может не подойти и тогда придется опять переделывать.
Cicerone решает проблему передачи навигационных вызовов, но не сохранения стека навигации. Cicerone отвечает за то, что команды навигации гарантировано дойдут до навигатора, но не сохраняет их для полного восстановления состояния приложения. (представьте как восстановить цепочку из смеси Activity и Fragment'ов)
Мы не хотели писать свой FragmentManager + ActivityStack + и тд.
У себя мы тоже используем Moxy. А за восстановление навигации отвечает сам андроид.
Речь о контексте необходимом для навигации, например Activity, у которого брать FragmentManager и так далее
RemoveBackScreen не решить явным образом при навигации по Активити.
А если чрезмерная гибкость может создать неоправданные сложности, то лучше ограничится на Replace.
Попробуйте сделать RemoveBackScreen, а там посмотрим :)
А если это другая ошибка? Тогда нам надо все презентеры подписать на все ошибки? Я же говорю, решить можно по-разному, но SystemMessage поможет в некоторых случаях сделать это проще и изящнее.
Еще хочу подчеркнуть важную деталь: SystemMessage создана для показа сообщений именно при навигации, то есть это можно рассматривать как некоторое состояние в навигации. Неправильно использовать эту команду просто для показа сообщений на экранах. Это ответственность Вью. SystemMessage не умеет обрабатывать клик или еще что-то, это только сообщение пользователю о случившемся переходе.
Мокси реализует чистый архитектурный подход. Не надо ломать принципы
1) Экран D показан не будет, так как смена экранов происходит быстрее. И все зависит от задачи. Можно сделать возврат не к конкретному экрану, а "на два назад", если экраны аутентификации попадают в общую цепочку. Такие случаи решаются расширением роутера. Для этого библиотека и создавалась гибкой.
Другой вариант: делать аутентификацию в отдельном активити с локальной цепочкой экранов.
2) Вы описываете типичный кейс бизнес логики. Если вы хотите, можно создать для таких случаев отдельную команду навигации. Повторюсь, что все для этого готово. Библиотека включает в себя необходимый минимум, если стараться учесть все кейсы, то маленькое решение превратится в гигантского монстра!
Возможно в будущем мы и добавим что-то еще, но на данный момент это не кажется критичным
1) Если я вас правильно понял, то вы спрашиваете про такой случай:
до перехода (F — активный экран)
a -> b -> c -> d -> e -> F
после перехода (G — активный экран)
a -> b -> c -> d -> G
Это решается методом в роутере:
2) Запрещать возвращаться на экран? Это как? Зачем тогда его оставлять в цепочке?