Лучшие практики, чтобы показать прогресс для Android JetPack? - PullRequest
Новая
       36

Лучшие практики, чтобы показать прогресс для Android JetPack?

0 голосов
/ 10 ноября 2018

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

Каковы рекомендации по отображению прогресса во время подготовки данных для ViewModel или когда мы отправляем некоторые данные для обработки (в ожидании изменений в ViewModel)?

Например, если значение LiveData равно нулю, переключитесь на фрагмент «Ход загрузки», подготовьте там ViewModel и вернитесь назад, когда он будет готов? Но ViewModel используют для привязки к определенному фрагменту ...

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

Должны ли мы когда-нибудь позаботиться об этом, если узнаем, что данные должны быть загружены практически сразу?

Как вы обрабатываете длительный пользовательский интерфейс операций в своих приложениях JetPack?

1 Ответ

0 голосов
/ 27 ноября 2018

Я нашел ответ в официальных документах и ​​образце.Здесь 2 части:

  1. Как отследить прогресс, используя LiveData
  2. Как отразить прогресс на пользовательском интерфейсе

1) Ответ найден наконец Руководство по архитектуре приложения

Прокрутите вниз до темы " Addendum: раскрытие статуса сети ".Они предлагают использовать некоторую оболочку LiveData, основанную на MediatorLiveData

. Существует много стандартного кода, который вы должны написать и поддерживать для переноса любых ваших LiveData, которые должны отслеживать прогресс или ошибки загрузки..

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

В каждом макете фрагмента должны быть какие-то средства поддержки прогресса.Здесь у нас есть только переменная: 

<data>
        <variable
            name="isLoading"
            type="boolean" />
</data>

И каждый виджет (представление), который мы хотим скрыть в процессе загрузки, должен иметь атрибут: 

app:visibleGone="@{isLoading}"

Так как это приложение определеноатрибут, мы должны позаботиться об этом где-то.Поэтому должен быть адаптер для поддержки visibleGone : 

public class BindingAdapters {
    @BindingAdapter("visibleGone")
    public static void showHide(View view, boolean show) {
        view.setVisibility(show ? View.VISIBLE : View.GONE);
    }
}

Конечно, мы можем использовать что-то вроде FrameLayout и поместить некоторую панель прогресса, которая затемнит наши элементы управления и покажет некоторое вращающееся колесо прогресса (вместо этогопростого сокрытия этого и показа пустого экрана).Но проблема в том, что вы должны заботиться об этом для каждого макета вашего фрагмента.А если у вас есть несколько сложных экранов (например, вкладок), это может еще больше усложнить ваш код.

Вывод: # 2 - более или менее работоспособное решение.Хотя я бы предпочел отдельный экран с фрагментами прогресса для всех случаев и не разбрасывать каждый из моих макетов фрагментов информацией о ходе загрузки и обработке ошибок.

Но # 1 заставляет меня спросить, в чем реальная выгода от использования LiveData?Чтобы сделать все правильно, с хорошей обработкой ошибок и обратной связью, нам нужно поддерживать слишком много стандартного кода.Они утверждают прямо в собственном руководстве:

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

Потому что этоКажется, дизайн LiveData не предназначен для легкого прогресса и обработки ошибок.

...