• Retain внутри, а снаружи ViewModel
    0
    Ну тут они советуют использовать родные ретейн фрагменты, которые появились начиная с HONEYCOMB (версия 3.0-3.2). Но если посмотреть исходники внимательно, то можно увидеть, что родные и саппорт фрагменты хранятся и передаются через NonConfigurationInstances, аналогично и лоадеры.
    А вот второе замечание интересное, что onRetainNonConfigurationInstance может в каки-то случаях не вызваться. Но что-то мне подсказывает на практике это никогда не случается. Иначе на ретейн фрагменты тоже нельзя полагаться.
  • Retain внутри, а снаружи ViewModel
    0
    Из минусов — не работает до 4 андроида, там придется по старинке через retain фрагмент.

    getLastNonConfigurationInstance доступен с первой версии API

  • Свежий взгляд на отображение диалогов в Android
    0

    Для фрагментов в бэкстеке ваш способ не пройдет, у них дестроится вью при реплейсе. И придется восстанавливать стейт.

  • «Я был очень негативен по отношению к корутинам»: Артём Зиннатуллин об Android-разработке
    0

    Добавлю что LiveData внутри завязана на Handler, и как прогонять unit-тесты?
    Самое неприятное, что теперь решение ViewModel + LiveData считается де-факто стандартом. Большинство доверяют только Гуглу и смотреть в сторону намного лучших MV*-решений даже не хотят. Тот же PM или MVVM несложно реализовать на RxJava.

  • Лицензия на вождение болида, или почему приложения должны быть Single-Activity
    0

    Conductor вам в помощь

  • Лицензия на вождение болида, или почему приложения должны быть Single-Activity
    0

    Удивительно, что кто-то еще не пишет приложения в Single-Activity. В любой момент может потребоваться поместить экран в NavigationDrawer, ViewPager или BottomBar. В этом случае без кучи фрагментов в одной Activity не обойтись.

  • Как я заменил RxJava на корутины в своем проекте и почему вам вероятно также стоит это сделать
    0

    В RxJava для этих целей есть Connectable Observable и Subject

  • Как я заменил RxJava на корутины в своем проекте и почему вам вероятно также стоит это сделать
    0

    Что насчет combineLatest ?

  • RxPM — реактивная реализация паттерна Presentation Model
    0

    все картинки сделаны в Sketch

  • Стратегии в Moxy (Часть 2)
    +1

    Можете привести пример из жизни, когда стандартными стратегиями не обойтись?

  • Системный подход к тестированию Android-приложений, или О чем молчали разработчики
    0

    Их много — значит они

  • Реактивные приложения с паттерном RxPM. Прощайте​ MVP и MVVM
    +1

    Точно так же как и в Moxy ;)


    Рестарт процесса вещь неприятная, но не всегда требуется при этом восстанавливать View в то же самое состояние. Так как данные за время отсутствия пользователя в приложении могли устареть. Все зависит от конкретного приложения и в каждом случае нужно то или иное решение:


    1) Точно восстановится бэкстек из активити и фрагментов. При желании этот момент можно отследить и очистить бекстек, если приложение стартовало с восстановлением.


    2) Самые важные параметры экранов (параметры запуска) мы стараемся передавать через Intent или аргументы фрагмента, например id сущностей, которые нужно отобразить. PresentationModel получает их в конструкторе, так как View провайдит ее.


    3) Не все состояния нужно восстанавливать. Например прогресс загрузки не нужно восстанавливать, так как с убийством процесса все асинхронные запросы (в том числе и в сеть) тоже завершатся.


    4) Есть данные, которые быстро устаревают, например какие-нибудь статусы заказа. Лучше будет их заново запросить с сервера.


    5) Некоторые данные следует восстанавливать даже после принудительного завершения приложения. В этом случае никакие bundle нам не помогут. Например это может быть корзина с продуктами. Такие данные во время работы приложения нужно сохранять на диск (в бд или файл).


    6) Хорошо кешировать данные, которые не сильно теряют актуальность за относительно продолжительное время.


    7) Можно запустить сервис, чтобы повысить приоритет приложения в фоне. Тем самым снизить вероятность убийства процесса системой.


    8) В конце концов в PresentationModel можно пробрасывать вызовы сохранения/восстановления состояния из bundle. Но этот вариант не подходит для персистентных данных (пункт 5 и 6).

  • Реактивные приложения с паттерном RxPM. Прощайте​ MVP и MVVM
    0

    .

  • Реактивные приложения с паттерном RxPM. Прощайте​ MVP и MVVM
    +1

    Основная идея паттерна PM заключается в том, что стейт хранится в PresentationModel. View не нужно об этом беспокоиться и не нужно складывать стейт в Bundle. Главное реализовать хранение PresentationModel во время поворота.


    По поводу навигации, нужно складывать команды в буфер, и воспроизводить их когда навигатор (активити) будет готов. Посмотрите как это сделано в Cicerone.

  • Реактивные приложения с паттерном RxPM. Прощайте​ MVP и MVVM
    0
    1. Не все пишут на Котлине, можно делать интерфейс-заглушку, но ее тоже придется генерировать. Но проблема не в этом. Так как вьюха может быт отсоединена, то приходится сохранять стейт в презентере в виде флагов, чтобы потом его воспроизвести при атаче вью.
    2. По поводу тестирования RxJava, есть хороший доклад на эту тему: https://www.youtube.com/watch?v=7W5NwpE5WpQ&feature=youtu.be
    3. Ретейн фрагмент только для семпла, так то для прода они не годятся. Как вы уже заметили в бекстеке такие фрагменты нельзя использовать и есть баги с чайлд-фрагментами. Я в своих приложениях использую Conductor — это такие "правильные" фрагменты, которые не умирают в бекстеке и при поворотах. А насчет памяти тут все в порядке, на onDestroyView мы отписываемся от PresentationModel.
  • Реактивные приложения с паттерном RxPM. Прощайте​ MVP и MVVM
    0

    Все ошибки можно разделить на два типа:
    1) Ошибки, которые нужно показать один раз, например AlertDialog или Toast. В этом случае ошибка будет эвентом, ее сохранять не нужно. Для этого подойдет обычный PublishRelay. Но будет проблема, если ошибка прилетит в тот момент, когда вьюха отсоединена от PresentationModel. В этом случае мы потеряем этот эвент. Как решать эту проблему я расскажу в следующей статье.


    2) Ошибки, которые нужно показывать как заглушку в разметке, например с кнопкой "Retry", такой вариант нужно считать стейтом. Для этого нужно использовать BehaviorRelay.

  • Реактивные приложения с паттерном RxPM. Прощайте​ MVP и MVVM
    0

    Залил примерчик на гитхаб https://github.com/dmdevgo/RxPM-Demo

  • Реактивные приложения с паттерном RxPM. Прощайте​ MVP и MVVM
    0

    Залил примерчик на гитхаб https://github.com/dmdevgo/RxPM-Demo

  • Реактивные приложения с паттерном RxPM. Прощайте​ MVP и MVVM
    –1

    Ответил выше

  • Реактивные приложения с паттерном RxPM. Прощайте​ MVP и MVVM
    0

    Чуть позже выложу

  • Реактивные приложения с паттерном RxPM. Прощайте​ MVP и MVVM
    0

    MVVM — это модификация более общего паттерна Presentation Model, со специфической реализацией автоматического связывания данных. Причем датабиндинг зависит от конкретной UI-платформы. В случае с RxPM мы имеем полуавтоматический биндинг: приходится вручную подписываться на Observable и отписываться от него. Стоит различать форму связывания, поэтому не совсем корректно называть представленный паттерн как RxMVVM.

  • Moxy — реализация MVP под Android с щепоткой магии
    +1

    А как вам поможет интерфейс презентера в тестировании? Протестировать вьюху? Но смысл MVP в том, чтобы вынести всю логику в презентер. Подставлять другие презентеры во вью тоже сомнительная идея. Другой презентер — другая вью — другой интерфейс у вью.

  • Вводим текст красиво
    0

    В приведенных примерах код страны захардкожен в маске, но что если я хочу форматировать номер телефона динамически, в зависимости от набранного кода страны? Аналогично с номером банковской карточки – он может быть произвольным от 12 до 19 цифр.

  • Различия между MVVM и остальными MV*-паттернами
    0

    Загляните в wiki, там все достаточно просто. Только про стратегии сохранения стейта почитайте отдельно.

  • Различия между MVVM и остальными MV*-паттернами
    +1

    Мне нравится MVP. Очень хорошо себя зарекомендовала Moxy. Ничего лишнего, простая в использовании библиотека, избавляет от написания рутинного кода. Ты применяешь MVP на практике и не беспокоишься о том, как реализовать этот паттерн. Киллер-фича Moxy — это восстановление состояния. Советую!


    На самом деле, в андроиде уже есть свой MVP: если из фрагмента вынести весь UI-код в кастомные View, то он по сути станет презентером. Только связь со View будет жесткая, а не через интерфейс. У такого подхода на фрагментах есть проблемы:


    • Фрагменты сложно тестировать, так как они тянут много android-зависимостей и самостоятельно создают View
    • У фрагментов сложный жизненный цикл и они умирают вместе с Activity. При поворотах можно воспользоваться setRetainInstance(true), но это не работает на child-фрагментах.
    • Нужно писать много рутинного кода для восстановления View
    • Жесткая связь со View

    Про MVVM ничего не могу сказать, но писать связывание данных в xml меня напрягает. Если интересно, то мой коллега написал хорошую статью про проблемы с ним в андроиде.


    Есть еще интересный паттерн Presentation Model, о котором мало кто знает и мало кто говорит. В нем нет тех проблем, что есть в MVVM, но приходится писать код связывания самостоятельно, практически для каждого свойства. Я планирую написать несколько статей о том, как его можно реализовать на андроиде.

  • Различия между MVVM и остальными MV*-паттернами
    0
    Если речь идет о передаче данных между компонентами, то я бы назвал это шиной данных.
  • Различия между MVVM и остальными MV*-паттернами
    0
    Я бы сначала присмотрелся к нативным решениям и библиотекам
  • Различия между MVVM и остальными MV*-паттернами
    0
    Xamarin не нативное решение
  • Различия между MVVM и остальными MV*-паттернами
    0
    Нормального MVVM нет, но гугл пилит databinding
  • Различия между MVVM и остальными MV*-паттернами
    +2
    Возможно стоит погуглить на тему Sencha Ext JS 5
  • Различия между MVVM и остальными MV*-паттернами
    0
    К сожалению я не могу привести пример для Web. Я занимаюсь разработкой мобильных приложений под Android. Может кто-то из читателей приведет примеры.
  • Как перестать использовать MVVM
    0
    1) По-хорошему этим должен заниматься презентер или вьюмодель. Например, хранить позицию выбранного элемента в списке. На практике это легче реализовать во вьюхе, но тогда вы не сможете протестировать восстановление состояния. Это та самая UI-логика, ради которой и создавались эти презентеры и вью-модели.

    2) Нужно восстанавливать состояние вручную и проверять, что вьюха привязывается после восстановления. Запоминать команды с анимацией — плохая идея. Можно передавать команду скролла с анимацией, а в стейте сохранять без нее, только позицию.