Comments 12
Будут ли примеры на Kotlin?
Репозиторий на GitHub пустой
Я бы, наверно, конкретно задолбался писать столько кода для таких простых вещей. Особенно если учесть, что этот пример с логином — один из самых тривиальных сценариев.
Во-первых, не стоит пытаться сохранить в SavedInstanceState все на свете.
В большинстве случаев, все уже сделано за вас. Стек активити и фрагментов сохраняется, состояния EditText, включая Error — тоже.
Какой смысл заморачиваться с сохранением состояния а-ля «нажал на кнопку Login»? Какова вероятность, что вас процесс резко убъется посреди реквеста? Вместо этого стоило бы лучше подумать о том, чтобы этот реквест не делался заново при перевороте экрана, например.
То же самое с состоянием LoginComplete. В какой ситуации вам нужно восстановить это состояние из бандла? Вы либо уже открыли следующий скрин, и соотвественно стэк активити восстановится после смерти процесса, либо вы отменили реквест и не перешли в это состояние вообще.
Фрагмент с кэшем для одного типа данных, еще и не типобезопасным — тоже такое себе удовольствие.
А еще обилие бесполезных пустых и Base классов не делает вашу архитектуру Clean.
Во-первых, не стоит пытаться сохранить в SavedInstanceState все на свете.
В большинстве случаев, все уже сделано за вас. Стек активити и фрагментов сохраняется, состояния EditText, включая Error — тоже.
Какой смысл заморачиваться с сохранением состояния а-ля «нажал на кнопку Login»? Какова вероятность, что вас процесс резко убъется посреди реквеста? Вместо этого стоило бы лучше подумать о том, чтобы этот реквест не делался заново при перевороте экрана, например.
То же самое с состоянием LoginComplete. В какой ситуации вам нужно восстановить это состояние из бандла? Вы либо уже открыли следующий скрин, и соотвественно стэк активити восстановится после смерти процесса, либо вы отменили реквест и не перешли в это состояние вообще.
Фрагмент с кэшем для одного типа данных, еще и не типобезопасным — тоже такое себе удовольствие.
А еще обилие бесполезных пустых и Base классов не делает вашу архитектуру Clean.
Спасибо за комментарий)
Поэтому в статье и рассматривался такой сценарий, в реальности решали задачу сложнее, как видно в конце статьи.
Идея статьи была не в том как сохранять реквесты, а сохранять состояние интерфейса на реакцию пользователя. При описанном подходе, никто не мешает, вынести сетевые запросы в джоб, и тогда при состоянии LoginProgressingState проверить статус, если завершен успешно то к следующему состоянию. При этом вся прелесть в том что мы не храним флаги в презентере, а решается на уровне объектов наших состояний.
Вьюха может отдетачится, и метод перехода не вызовится. Естественно все можно было сделать на флагах и проверить в начале залогинены мы или нет, и в зависимости от этого сделать навигацию, но статья не про флаги.
Один тип данных, потому что он универсальный и пробрасывать будет проще. Но в нем можно сохранить все данные, по которым можно восстановить наше состояние. На практике такое не применял, но мне показалось это достаточно интересным. Не типобезопасным, да, но при этом такая возможность есть.
Я бы, наверно, конкретно задолбался писать столько кода для таких простых вещей. Особенно если учесть, что этот пример с логином — один из самых тривиальных сценариев.
Поэтому в статье и рассматривался такой сценарий, в реальности решали задачу сложнее, как видно в конце статьи.
Какой смысл заморачиваться с сохранением состояния а-ля «нажал на кнопку Login»? Какова вероятность, что вас процесс резко убъется посреди реквеста? Вместо этого стоило бы лучше подумать о том, чтобы этот реквест не делался заново при перевороте экрана, например.
Идея статьи была не в том как сохранять реквесты, а сохранять состояние интерфейса на реакцию пользователя. При описанном подходе, никто не мешает, вынести сетевые запросы в джоб, и тогда при состоянии LoginProgressingState проверить статус, если завершен успешно то к следующему состоянию. При этом вся прелесть в том что мы не храним флаги в презентере, а решается на уровне объектов наших состояний.
То же самое с состоянием LoginComplete. В какой ситуации вам нужно восстановить это состояние из бандла? Вы либо уже открыли следующий скрин, и соотвественно стэк активити восстановится после смерти процесса, либо вы отменили реквест и не перешли в это состояние вообще.
Вьюха может отдетачится, и метод перехода не вызовится. Естественно все можно было сделать на флагах и проверить в начале залогинены мы или нет, и в зависимости от этого сделать навигацию, но статья не про флаги.
Фрагмент с кэшем для одного типа данных, еще и не типобезопасным — тоже такое себе удовольствие.
Один тип данных, потому что он универсальный и пробрасывать будет проще. Но в нем можно сохранить все данные, по которым можно восстановить наше состояние. На практике такое не применял, но мне показалось это достаточно интересным. Не типобезопасным, да, но при этом такая возможность есть.
Поэтому в статье и рассматривался такой сценарий, в реальности решали задачу сложнее, как видно в конце статьи.
Я имею в виду, что в сложных задачах писанины еще больше.
Вьюха может отдетачится, и метод перехода не вызовится
Если вьюха отдетачится, и переход не вызовется, то у вас и состояние это теряется.
При детаче вы отписываетесь от чейна, значит onComplete/onNext не вызовется, и соответственно этот код — тоже.
setState(new LoginCompleteState());При этом вся прелесть в том что мы не храним флаги в презентере, а решается на уровне объектов наших состояний.
Это хорошо, но мой посыл не то, что состояния — это плохо, а то что не нужно каждое состояние делать Parcelable и извращаться с их сохранением. Особенно когда часть этих состояний и так сохранится без вашего участия.
Если вьюха отдетачится, и переход не вызовется, то у вас и состояние это теряется.
При детаче вы отписываетесь от чейна, значит onComplete/onNext не вызовется, и соответственно этот код — тоже.
setState(new LoginCompleteState());
Не совсем так, кто сказал, что вьюха отдетачилась именно на моменте когда у нас запрос еще делается, она может отдетачиться когда, вызвался метод subscribe и выставилось состояние, но при этом метод navigateToMainView еще не вызвался. Кейс с очень низкой вероятностью, но такое может быть.
Это хорошо, но мой посыл не то, что состояния — это плохо, а то что не нужно каждое состояние делать Parcelable и извращаться с их сохранением. Особенно когда часть этих состояний и так сохранится без вашего участия.
Визуально состояния элементов сохранятся, с этим никто не спорит, даже прогресс диалог будет показываться, если комит в фрагмент менеджер произошел до вызова onSavedInstanceState. Но сохранится ли текущая реакция приложения на действия пользователя? Теперь, давайте вернемся к последней схеме статьи.
Три кейса логин, восстановление пароля, регистрация. Элементы в разметке: email, password, first name, last name, btn. Каждый элемент должен себя вести в разных состояниях по разному: разные правила валидации поля, разные действия при нажатии на кнопку. Без сохранения текущего состояния мы получим полностью не рабочий интерфейс.
Не совсем так, кто сказал, что вьюха отдетачилась именно на моменте когда у нас запрос еще делается, она может отдетачиться когда, вызвался метод subscribe и выставилось состояние, но при этом метод navigateToMainView еще не вызвался
Нет, это невозможно.
Детач и вызов setState происходит в одном и том же треде. Последовательно. В setState вы сразу делаете переход navigateToMainView. Либо вы отдетачитесь и теряете стейт, либо вы на этот стейт переходите и потом детачитесь. Никакого рейс кондишина здесь не может быть.
Плюс ко всему в котлине parcelable идет практически из коробки.
Меня одного смутило, что слой View возвращает значения? Как же Void в обе стороны для слоев в MVP?
Sign up to leave a comment.
Cохранение состояний в android приложениях