У меня на руках довольно необычный случай, и я удивлен, что, похоже, никто не написал об этом / что-то подобное для Android (или мои навыки Google - отстой)


Ситуация №1:

  • Пользователь может вводить текст в field1 и field2.
  • Пользователь также может переупорядочивать элементы в списке (отображается в RecyclerView)

Всякий раз, когда пользователь вносит какие-либо изменения, пользовательский интерфейс уже показывает обновленные данные (например, поле редактирования 1 будет отображать текст по мере его ввода пользователем, а список элементов будет показывать их в новом порядке, когда пользователь их переупорядочивает. ).

Если сразу сохранить данные здесь, пользовательский интерфейс будет обновлен (чтобы отобразить то же самое), что ухудшит впечатление пользователя (фокус field1 сместится на первую букву, и приложение может вылететь, если пользователь быстро переупорядочит элементы списка. ).

Поэтому имеет смысл сохранить изменения и выполнить их позже.


Ситуация 2:

  • Пользователь может нажимать кнопки плюс / минус для увеличения / уменьшения значения
  • Пользователь может вводить текст в поле 3.

Как и в ситуации №1 выше, при редактировании поля пользовательский интерфейс уже будет в обновленном состоянии. Но в этом случае нажатие кнопки «плюс / минус» также обновит данные, но пользовательский интерфейс не будет обновлен (если данные не будут сохранены и запрос не будет выполнен снова ...).


Проблема:

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

Я использую MVVM, поэтому все выполненные действия отправляются в модель просмотра, и она решает, что делать. Я ищу решение, которое по-разному работает на разных экранах приложения, но я знаю, что это просто прострелил бы себе ногу, а затем спрыгнул бы с моста. Конечно, должен быть кто-то, кто столкнулся с этой проблемой и имел какие-то идеи относительно нее?

Идеальное решение: одно решение, которое просто работает для всех разных экранов. У тебя есть это? Пожалуйста, дайте мне знать.

/ Отчаянный разработчик Android

1
zoltish 11 Дек 2017 в 23:40

1 ответ

Лучший ответ

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

Позволь мне объяснить. Рассмотрим два приложения: одно сохраняет элементы TODO, а другое - банковское приложение.

Теперь я объясню, что, по моему мнению, может сработать для вашего приложения, поскольку вы явно не упомянули какие-либо требования, которые противоречат этому.

В подобных ситуациях я считаю, что оптимизм - хорошая идея. Предполагая, что ничего не произойдет, и когда это произойдет, попытайтесь отступить. Что это обозначает?

Это означает, например, что в упомянутом вами сценарии пользователь вводит что-то в поле. Вы должны разрешить автоматическое обновление пользовательского интерфейса (здесь мы ничего не делаем, это просто Android), когда это произойдет, вы сохраните эти изменения либо локально, либо на сервере, не имеет значения.

Конечно, вы можете оптимизировать, вместо того, чтобы сохранять каждую букву, как-то ограничивать ввод, но вы поняли идею.

Это может быть либо успехом, либо неудачей, потому что мы настроены оптимистично, мы позволяем пользовательскому интерфейсу обновляться, и пользователь чувствует, что наше приложение быстро запускается. Вам не нужно ничего перезагружать или обновлять. Пользовательский интерфейс уже должен соответствовать вашему состоянию Model.

Что делать, если что-то пойдет не так, и ваш HTTP-запрос или обновление БД по какой-то причине не удастся, тогда вам нужно принять меры. Но постарайтесь, чтобы ваша реакция была адекватной.

Вы можете справиться с этой ошибкой многими способами, опять же, в зависимости от того, насколько критично то, что вы делаете в своем приложении.

  • Вы можете просто показать тост или даже ничего не делать, если действие пользователя было таким тривиальным.
  • Вы можете показать пользователю что-то более конкретное, если действие имеет какое-то значение, может быть, Snakbar с повтором и объяснением того, что произошло.
  • Вы завершаете свой процесс и завершаете все действия - шучу, никогда этого не делайте - но показываете очень навязчивое всплывающее окно и, возможно, возвращаете значение пользовательского интерфейса к правильному, если то, что делал пользователь, было довольно критично.

Теперь этот подход не только дает ощущение того, что приложение действительно быстрое, но и упрощает работу.

Еще один совет - не пытайтесь решать проблемы, которых еще нет, это означает, что не начинайте реализовывать фоновые службы и очереди заданий для некоторых локальных заданий сохранения, которые никогда не переживут представление и никогда не смогут этого сделать.

Вместо этого используйте измерения, регистрируйте эти ошибки и сбои с помощью какого-либо инструмента и используйте эту статистику, чтобы знать, что нужно исправить - если есть -

Возвращаясь к нашим двум приложениям, этот подход может быть идеальным для приложения TODO, однако он может быть не слишком хорош для банковского приложения.

Предположим, пользователь переводит деньги, мы сразу говорим: ВСЕМ ДОБРО ПОЖАЛОВАТЬ! а затем запрос не выполняется, и арендодатель вашего пользователя выгоняет его за то, что он не платил арендную плату.

Все сводится к тому, насколько чувствительны операции, которые вы выполняете.

1
elmorabea 11 Дек 2017 в 21:33