Presenter/View/ViewState relationshipts

Question

Например, у меня есть EditProjectFragment, который содержит несколько элементов:

• TextView (название проекта)
• ColorPicker (цвет проекта)
• Spinner (тип проекта)

Посмотрим:

1. Название проекта будет восстановлено самим TextView
2. Кому должен быть сохранен цвет проекта?
3. Кто должен хранить значение счетчика?

Обязанности: ViewState. Например, когда пользователь выбирает цвет, View звонит presenter.onProjectColorPicked(color). Затем Presenter позвонит view.setProjectColor(color). Или View должен обновить ViewState напрямую, без звонка Presenter, если он не нужен?

---

Другой пример. Пользователь добавляет фотографии в EditNoteFragment. Пользователь выбирает фотографию (presenter.pickPhoto()) ->presenter.addPhoto(photo) позвонил и уведомил View, чтобы добавить фотографию в ViewState & показать это. Должно ли View обновить Note объект сам по себе? Должно ли это быть сделано Презентером? В первом случае это означает, что ViewState предоставит такие методы, как getNote()/setNote(note), которые будут использоваться View. Должен ли я дублировать ссылку на замещение посредством обновления в методе View.setNote(note)? Второй случай означает, что я, вероятно, должен хранить Note объект в Presenter и просто обновлять View без пропуска Note в нем. Но это выглядит неправильно.

---

Другими словами:, что View должны обойтись без помощи Presenter «s (добавить фото к Note объекта?) И какие вещи с ним (кнопка щелчки и т.д.)?

Answer 1

Viewstate предназначался для представления различных состояний из вашего представления. I.e В представлении отображается индикатор загрузки. поэтому мы можем сказать, что представление находится в «состоянии загрузки». Поэтому всякий раз, когда меняется «состояние», обычно выступает ведущий, потому что его ответственность за презентацию заключается в согласовании взглядов. Возникает вопрос: как вы определяете состояние? Серебряной пули нет.

Я не думаю, что это имеет смысл играть такой пинг-понг игры, как

1. presenter.onProjectColorPicked(color)
2. view.setProjectColor(color)

, если вы не сказать, что она идет вниз к модели (бизнес-логика) следующим образом:

1. Просмотреть вызовы presenter.onProjectColorPicked(color)
2. Presenter называет model.setColor(color)
3. модель сообщает ведущий (с помощью шаблона наблюдателя), что модель была изменена
4. Presenter называет view.setData(newModelWithChangedColor), содержащий новый цвет

В целом: вид просто отображение (с помощью ведущего), каково текущее состояние «модели».

ViewState - это всего лишь маленький помощник, чтобы иметь дело с изменениями ориентации экрана и обработкой смерти немного более удобным способом (по сравнению с традиционными реализациями onSaveInstanceState(Bundle)).

Так что спросите себя: каково состояние вашей «модели». Обычно состояние представления совпадает с состоянием «модели».

В первом примере кажется, что это проблема выбора цвета и счетчика, чтобы не сохранять выбранные вещи внутри себя. Поэтому, делая это вручную в onSaveInstanceState() для сборщика/счетчика, по умолчанию рекомендуется команда разработчиков Android. Итак, если вы просто хотите использовать функцию ViewState, чтобы не использовать onSaveInstanceState(), потому что вам удобнее использовать ViewState, это тоже хорошо, хотя это не совсем то, для чего предназначался ViewState.