Каково реальное использование Executor в Android Paging Library? - PullRequest
Новая
       14

Каково реальное использование Executor в Android Paging Library?

0 голосов
/ 28 марта 2019

Я видел большинство примеров использования Executor в классах DataSource, которые обычно передаются в DataSourceFactory из ViewModel, а затем в классы DataSource. Как использовать executor. Какие преимущества / преимущества использования Executor.

ViewModel 

public FooViewModel{

public FooViewModel() {

    executor = Executors.newFixedThreadPool(5);
    //pasing executor here.
    FooDataSourceFactory itemDataSourceFactory = new 
   FooDataSourceFactory(executor);


}

DATASORUCEFACTORY 

public class FooDataSourceFactory extends DataSource.Factory {
private FooDataSource itemDataSource;
private Executor executor;
//creating the mutable live data
private MutableLiveData<FooDataSource> itemLiveDataSource = new 
MutableLiveData<>();

public FooDataSourceFactory(Executor executor) {
    this.executor = executor;
}


@Override
public DataSource create() {
    //passing executor here..
    itemDataSource = new FooDataSource(executor);

    //posting the dataSource to get the values
    itemLiveDataSource.postValue(itemDataSource);

    //returning the dataSource
    return itemDataSource;

.................
}

DataSource 

public class FooDataSource { 

 FooDataSource(Executor executor){
       //don't know what to do with executor
    }
}

1 Ответ

1 голос
/ 28 марта 2019

Палач

Объект, который выполняет представленные Runnable задачи. Этот интерфейс позволяет отделить представление задачи от механизма выполнения каждой задачи, включая сведения об использовании потоков, планировании и т. Д. Обычно вместо создания потоков используется исполнитель. Например, вместо того, чтобы ссылаться new Thread(new RunnableTask()).start() для каждого набора задач вы можете использовать: executor.execute(runnable);

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

Если вы разрабатываете приложение с архитектурой MVVM, вполне возможно, что у вас есть некоторый класс «хранилище», который обрабатывает данные локально и / или вызовы сетевого API. В этом случае рекомендуется запросить базу данных у исполнителей.

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

В вашем конкретном случае вам может не понадобиться исполнитель внутри ваших DataSource и DataSourceFactory. это зависит от того, что вы делаете в этих классах. Если вы извлекаете данные из сети, есть много библиотек, таких как volley и retrofit2 , которые выполняют http-вызовы асинхронно, поэтому нет необходимости в исполнителе.

При извлечении данных из локальной БД, например Room :

«Из коробки» не поддерживает доступ к базе данных в главном потоке, поэтому исполнитель находится там, чтобы обеспечить выполнение работы в отдельном потоке. ссылка

Надеюсь, вы найдете мой ответ полезным.

...