Про команду SystemMessage.
Я специально выделил ей особое внимание, так как она только косвенно связана с навигацией. Можно обойтись и без нее, но в ряде случаев это будет не так изящно как с ней!
Пример: форма оплаты. Пользователь заполнил поля и нажал далее, но сервер вернул ошибку авторизации. Нам надо сказать об этом пользователю и перекинуть на экран входа. Без команды SystemMessage это можно сделать двумя способами:
на экране оплаты показать диалог и ждать нажатия кнопки ОК. Тут придется блокировать отмену этого диалога + очищать поля с секретной информацией, так как ошибка авторизрции может говорить о том, что приложение в чужих руках.
переходить на экран входа с дополнительной информацией о том, что надо при запуске показать сообщение. Это само по себе некрасиво, так как, по логике, экран входа не должен ничего иного делать, кроме как регистрировать пользователя.
Разруливание логики startActivityForResult оставлено на решение в частном порядке, так как эта логика доступна только в Activity и частично во Fragment'ах, а библиотека не делает разницы между разными видами View. Как я и говорил, Cicerone легко расширять, все в ваших руках. Важный момент: в подходе MVP не предполагается обмена данными между View и даже между Presenter'ами. Это надо реализовывать через модель. Да, в андроиде Activity обладают механизмом startActivityForResult, но он не единственно возможный. Если речь о сторонних библиотеках или системных Activity, то я советую рассматривать результат запуска таких Activity как обычное пользовательское действие и передавать данные в свой презентер, где уже делать остальную обработку.
"Activity это не экран" — кто сказал? Activity может быть View без каких либо ограничений! После перехода на новое Activity, первое Activity очистит навигатор в методе onPause, а новое Activity установит свой навигатор в onResume. Здесь будет только один момент, обусловленный архитектурой андроида: Activity будет, с одной стороны, реализовывать View, а с другой, заниматься навигацией. (помните слайд с Франкенштейном?)
Я не веб или браузерный разработчик, поэтому оценивал чисто субъективно, но из 10 открытых сайтов полностью "правильно" отобразились только 3-4. То картинки обрежутся, то шрифт кривой, то совсем все съедет.
Возможно, это не критичные вещи на данном этапе, но и до 2017 года уже не очень далеко
Я не понял один момент:
На схеме бинов есть Shared Bean, и создается впечатление, что он, при переходе на новое активити, не будет создаваться заново, а будет использоваться общий между двумя фрагментами разных активити.
Но далее, судя по коду, этот Shared Bean ничем не отличается от Bean A и Bean B, и будет создаваться новый инстанс для нового активити B.
Еще странный момент: на скринах двух активити ИД отличаются даже у SingletonBean!
Как преданный фанат Огнелиса, возлагаю большие надежды на новый движок.
Хотя, где-то месяц назад пробовал тестовую сборку Servo, и, честно сказать, впечатление, что до использования в реальном браузере ему очень далеко :(
Буду ждать и верить в новогоднее чудо!
Вы статью читали?
Речь о том, что сейчас много кто хочет использовать MVVM на андроиде. А автор статьи на собственном опыте показал, что на данный момент красиво и в рамках паттерна этого не сделать.
Приведены конкретные аргументы. Никто не принижает сам MVVM!
А вы все к словам придираетесь и хотите в другое русло загнуть.
Мне кажется вы меня не совсем правильно поняли. Возможно я действительно привел неудачный пример. Извините!
Речь шла не о навигации и диалоговых окнах, а об особенности паттерна — только и всего.
Попробую еще раз: У нас на вьюхе могут быть состояния, которые нужно восстановить после поворта, но не связанные с самими данными. Пример: экран с изображением. мы можем зуммить изображение и двигать его в стороны нажатием на кнопки "+", "-", "<-" и "->" соответственно. Обработкой нажатий занимается ViewModel.
В случае MVVM во ViewModel появятся дополнительные данные помимо самой картинки — это X, Y и зумм. Эти параметры я и назвал неудачно "флагами", так они тут только для сохранения состояния.
В случае подхода с сохранением очереди команд, рядом с самой картинкой не появится дополнительных "флагов", X, Y и зумм. Они будут неявно сохранены в очереди.
Я для примера привел диалог. Кто говорит о стеке?
Это может быть что угодно, Snackbar, например, или анимация какая-нибудь.
Как сохранить такие вещи статическим набором данных?
Да, я именно про второй вариант. В реальных проектах количество таких флагов может вырасти до неприличных размеров. Так что, в таком случае, удобно применять подход сохранения очереди вызовов на вьюхе вместо флагов.
А как тогда сохранить в VM то, что было показано через непосредственный вызов (например диалог)? Тут начинаются танцы с флагами и восстановлением состояния при ребиндинге вьюхи
В мобильной разработке самое классное то, что телефоны есть у всех (есть мнение, что даже ПК отстают). Ты не только можешь сам пользоваться своим творением, но и есть шанс, что у друзей тоже оно будет. Ну а если там есть очень хитрая пасхалка… :-)
Кроме того, помимо решения архитектурных задач и реализации бизнес логики, я люблю делать красиво. Анимации, верстка, плавность — вот это все действительно доставляет истинное удовольствие, когда круто сделано!
И наконец, работая над проектом, ты можешь его реально «пощупать» — поэтому точно знаешь, что делаешь что-то реальное.
Я люблю андроид! Причин много, но я упомяну только его Linux корни и частичную открытость.
Как и везде, в андроид разработке есть тонкие моменты, которые хотелось бы изменить:
1) работа с клавиатурой. Ладно когда надо ее просто скрыть и показать, но вот когда дизайнер хочет сочетание прозрачного статус-бара и хитрую анимированную обработку при появлении клавиатуры… Порой очень мешает момент, что fitSystemWindows относится и к статус-бару и к клавиатуре. Еще высоту клавиатуры не так просто узнать. Приходится опираться на OnLayoutChangeListener
2) Асинхронность транзакций фрагментов. Это не так сложно, но постоянно приходится следить за возможностью словить эксепшн там, где не ожидаешь.
3) Недоступность для прямой работы с фрагмент-бэкстеком. Это усложняет задачи с хитрыми переходами или построением цепочки фрагментов (при обработке диплинка, например, хочется открыть экран с заранее построенным бекстеком).
4) Флаги запуска активити. Да, они позволяют гибко настроить запуск различных частей приложения, но даже прочитав официальную документацию, сразу не разберешься. Есть подозрение, что можно сделать проще.
5) «Сложный» жизненный цикл фрагмента. Когда работаешь с ним много лет, то он не кажется уже «сложным», но новичков разнообразие состояний сбивает с толку.
6) Встроенная работа со шрифтами. Calligraphy — спасение, но не всегда срабатывает с саппорт виджетами.
7) Ну и напоследок стоит упомянуть главную боль: огромный зоопарк устройств, среди которых хватает не только китайцев с 256 Мб оперативки и мелким экраном, но и кастомных сборок андроида, подменяющих системные виджеты. Ах да, еще вышла 7-ка, а мы все еще пишем под 4-ку…
Но не смотря на все недостатки — я обеими руками За Андроид!
В моей практике кругом и около ситуация, когда дизайн и красивый и функциональный, но стоит дойти до разработки, как оказывается, что этот дизайн совсем не приспособлен к реальным ситуациям, когда каких-то данных нет, что-то пустое, где-то текста в три раза больше, а где-то одно слово…
Мечта: каждый экран отрисованный в нескольких ситуациях, где будут видны и учтены вышеперечисленные недостатки
Я добавил в Sample приложение пример навигации на Activity. Welcome!
Про команду SystemMessage.
Я специально выделил ей особое внимание, так как она только косвенно связана с навигацией. Можно обойтись и без нее, но в ряде случаев это будет не так изящно как с ней!
Пример: форма оплаты. Пользователь заполнил поля и нажал далее, но сервер вернул ошибку авторизации. Нам надо сказать об этом пользователю и перекинуть на экран входа. Без команды SystemMessage это можно сделать двумя способами:
Разруливание логики startActivityForResult оставлено на решение в частном порядке, так как эта логика доступна только в Activity и частично во Fragment'ах, а библиотека не делает разницы между разными видами View. Как я и говорил, Cicerone легко расширять, все в ваших руках.
Важный момент: в подходе MVP не предполагается обмена данными между View и даже между Presenter'ами. Это надо реализовывать через модель. Да, в андроиде Activity обладают механизмом startActivityForResult, но он не единственно возможный. Если речь о сторонних библиотеках или системных Activity, то я советую рассматривать результат запуска таких Activity как обычное пользовательское действие и передавать данные в свой презентер, где уже делать остальную обработку.
"Activity это не экран" — кто сказал? Activity может быть View без каких либо ограничений! После перехода на новое Activity, первое Activity очистит навигатор в методе onPause, а новое Activity установит свой навигатор в onResume. Здесь будет только один момент, обусловленный архитектурой андроида: Activity будет, с одной стороны, реализовывать View, а с другой, заниматься навигацией. (помните слайд с Франкенштейном?)
Рад, что заинтересовал вас!
А что конкретно вас так взволновало?
Я не веб или браузерный разработчик, поэтому оценивал чисто субъективно, но из 10 открытых сайтов полностью "правильно" отобразились только 3-4. То картинки обрежутся, то шрифт кривой, то совсем все съедет.
Возможно, это не критичные вещи на данном этапе, но и до 2017 года уже не очень далеко
Я не понял один момент:
На схеме бинов есть Shared Bean, и создается впечатление, что он, при переходе на новое активити, не будет создаваться заново, а будет использоваться общий между двумя фрагментами разных активити.
Но далее, судя по коду, этот Shared Bean ничем не отличается от Bean A и Bean B, и будет создаваться новый инстанс для нового активити B.
Еще странный момент: на скринах двух активити ИД отличаются даже у SingletonBean!
SQLite Manager — не нашел ни одного аналога, хоть как-то сравнимого с удобством этого.
Как преданный фанат Огнелиса, возлагаю большие надежды на новый движок.
Хотя, где-то месяц назад пробовал тестовую сборку Servo, и, честно сказать, впечатление, что до использования в реальном браузере ему очень далеко :(
Буду ждать и верить в новогоднее чудо!
Я думаю, самый подробный ответ на ваш вопрос в статье Как перестать использовать MVVM
Так в этом и идея, что при повороте можно это определить во фрагменте и не очищать Dagger Scope, в остальных случаях он остается в памяти:
Вы статью читали?
Речь о том, что сейчас много кто хочет использовать MVVM на андроиде. А автор статьи на собственном опыте показал, что на данный момент красиво и в рамках паттерна этого не сделать.
Приведены конкретные аргументы. Никто не принижает сам MVVM!
А вы все к словам придираетесь и хотите в другое русло загнуть.
Мне кажется вы меня не совсем правильно поняли. Возможно я действительно привел неудачный пример. Извините!
Речь шла не о навигации и диалоговых окнах, а об особенности паттерна — только и всего.
Попробую еще раз: У нас на вьюхе могут быть состояния, которые нужно восстановить после поворта, но не связанные с самими данными.
Пример: экран с изображением. мы можем зуммить изображение и двигать его в стороны нажатием на кнопки "+", "-", "<-" и "->" соответственно. Обработкой нажатий занимается ViewModel.
В случае MVVM во ViewModel появятся дополнительные данные помимо самой картинки — это X, Y и зумм. Эти параметры я и назвал неудачно "флагами", так они тут только для сохранения состояния.
В случае подхода с сохранением очереди команд, рядом с самой картинкой не появится дополнительных "флагов", X, Y и зумм. Они будут неявно сохранены в очереди.
Это может быть что угодно, Snackbar, например, или анимация какая-нибудь.
Как сохранить такие вещи статическим набором данных?
"А можно взять Moxy", говорю я, как тот самый коллега ;-), но это уже не MVVM
Кроме того, помимо решения архитектурных задач и реализации бизнес логики, я люблю делать красиво. Анимации, верстка, плавность — вот это все действительно доставляет истинное удовольствие, когда круто сделано!
И наконец, работая над проектом, ты можешь его реально «пощупать» — поэтому точно знаешь, что делаешь что-то реальное.
Я люблю андроид! Причин много, но я упомяну только его Linux корни и частичную открытость.
Как и везде, в андроид разработке есть тонкие моменты, которые хотелось бы изменить:
1) работа с клавиатурой. Ладно когда надо ее просто скрыть и показать, но вот когда дизайнер хочет сочетание прозрачного статус-бара и хитрую анимированную обработку при появлении клавиатуры… Порой очень мешает момент, что fitSystemWindows относится и к статус-бару и к клавиатуре. Еще высоту клавиатуры не так просто узнать. Приходится опираться на OnLayoutChangeListener
2) Асинхронность транзакций фрагментов. Это не так сложно, но постоянно приходится следить за возможностью словить эксепшн там, где не ожидаешь.
3) Недоступность для прямой работы с фрагмент-бэкстеком. Это усложняет задачи с хитрыми переходами или построением цепочки фрагментов (при обработке диплинка, например, хочется открыть экран с заранее построенным бекстеком).
4) Флаги запуска активити. Да, они позволяют гибко настроить запуск различных частей приложения, но даже прочитав официальную документацию, сразу не разберешься. Есть подозрение, что можно сделать проще.
5) «Сложный» жизненный цикл фрагмента. Когда работаешь с ним много лет, то он не кажется уже «сложным», но новичков разнообразие состояний сбивает с толку.
6) Встроенная работа со шрифтами. Calligraphy — спасение, но не всегда срабатывает с саппорт виджетами.
7) Ну и напоследок стоит упомянуть главную боль: огромный зоопарк устройств, среди которых хватает не только китайцев с 256 Мб оперативки и мелким экраном, но и кастомных сборок андроида, подменяющих системные виджеты. Ах да, еще вышла 7-ка, а мы все еще пишем под 4-ку…
Но не смотря на все недостатки — я обеими руками За Андроид!
Мечта: каждый экран отрисованный в нескольких ситуациях, где будут видны и учтены вышеперечисленные недостатки