Android Room: обратный вызов LiveData для вставки обновления?

1. Могу ли я использовать LiveData для обертывания вызовов Delete, Insert, Update?

Нет, не можешь. Я написал ответ на проблему. Причина в том, что LiveData используется для уведомления об изменениях. Вставка, обновление, удаление не вызывают изменений. Он вернет удаленные строки, вставленный идентификатор или затронутые строки. Даже если это выглядит ужасно, имеет смысл не обертывать LiveData вокруг ваших материалов. В любом случае, имеет смысл иметь что-то вроде Single вокруг вызовов, чтобы позволить операции запускаться и работать с операцией RX-Java.

Если вы хотите инициировать эти вызовы, вы наблюдаете за запросом выбора, который уведомляет ваш LiveData onec, что вы обновили, вставили или удалили некоторые / любые данные.

2. Лучший способ сохранить такой класс asynctask для удаления, вставки, обновления?

Посмотрев на ваш пример, похоже, что вы неправильно используете (Model / View /) ViewModel-Pattern. Вы никогда не должны обращаться к своему репозиторию в вашем представлении. Я не уверен, что вы делаете это, потому что это не видно в вашем образце. В любом случае, после наблюдения за вашими LiveData и получения результата нет необходимости оборачивать обновление данных внутри вашего viewModel в AsyncTask. Это означает, что вы всегда должны заботиться о

a) просматривать ‹-> viewmodel ‹-> репозиторий, а не просматривать ‹-> репозиторий и просматривать ‹-> viewmodel

а также

б) не пытайтесь использовать ненужные потоки. Вы наблюдаете LiveData в фоновом потоке (@WorkerThread) по умолчанию (если не аннотировано с помощью @MainThread) и получаете значение в пользовательском потоке (@MainThread).

Что касается второго вопроса, есть еще одна более удобная альтернатива AsyncTask; который использует java Executor, хорошая новость заключается в том, что вы можете использовать один экземпляр Executor вместо нескольких экземпляров AsyncTask для всех операций CRUD.

Демо-пример

public class Repository {

    private static Repository instance;
    private MyDatabase mDatabase;
    private Executor mExecutor = Executors.newSingleThreadExecutor();

    private Repository(Application application) {
        mDatabase = MyDatabase.getInstance(application.getApplicationContext());
    }

    public static Repository getInstance(Application application) {
        if (instance == null) {
            instance = new Repository(application);
        }
        return instance;
    }


    public void insert(final MyModel model) {

        mExecutor.execute(new Runnable() {
            @Override
            public void run() {
                mDatabase.getMyModelDAO().insert(model);
            }
        });
    }

    public void update(final MyModel model) {
        mExecutor.execute(new Runnable() {
            @Override
            public void run() {
                mDatabase.getMyModelDAO().update(model);
            }
        });
    }

    public void delete(final MyModel model) {
        mExecutor.execute(new Runnable() {
            @Override
            public void run() {
                mDatabase.getMyModelDAO().delete(model);
            }
        });
    }

}

Относительно вопроса 2:

Для пользователей Kotlin теперь есть действительно хороший способ добиться этого, потому что, начиная с Room 2.1, есть прямая поддержка сопрограмм. Замечательный пример приведен здесь.

Вы можете использовать «функцию приостановки» непосредственно в DAO, которая заботится о том, чтобы ничего не выполнялось в основном потоке:

@Dao
 interface BarDao {

   @Query("SELECT * FROM bar WHERE groupId = 2")
   fun getAllBars(): LiveData<MutableList<Bar>>

   @Query( "SELECT * FROM bar WHERE groupId = 0 LIMIT 1")
   fun getRecentBar(): LiveData<Bar>

   @Insert
   suspend fun insert(bar: Bar)

   @Update
   suspend fun update(bar: Bar)

   @Delete
   suspend fun delete(bar: Bar)

}

тогда в вашем viewModel вы просто:

    fun insert(bar: Bar) = viewModelScope.launch {
        barDao.insert(bar)
    }

    fun update(bar: Bar) = viewModelScope.launch {
        barDao.update(bar)
    }

    fun delete(bar: Bar)= viewModelScope.launch {
        barDao.delete(bar)
    }

Чтобы ответить на ваш второй вопрос:

Google разместил здесь Android Room Codelab, в котором изложил краткую архитектуру MVVM для реализации Room в Android:

Здесь рекомендуется, чтобы операции с базой данных обрабатывались общедоступным статическим ExecutorService в классе базы данных. Расположение класса ExecutorService может варьироваться, просто помните, что идея заключается в том, что в MVVM ваше представление не заботится о том, как данные фактически обрабатываются CURD, это ответственность ViewModel, а не View.

репозиторий github для этой лаборатории кода

Короче говоря, применить аналогичную идею к вашему коду можно примерно так:

class YourRepository {
    private FeedEntryDAO mFeedEntryDAO;

    YourRepository(Application application) {
        YourDatabase db = YourDatabase.getDatabase(application);
        mFeedEntryDAO = db.feedEntryDAO();
        mAllWords = mWordDao.getAlphabetizedWords();
    }


    void update(FeedEntry feedEntry) {
        Database.databaseExecutor.execute(() - > {
            mFeedEntryDAO.update(feedEntry);
        });
    }
}

class YourViewModel extends ViewModel {
    private YourRepository mRepository;
    void update(FeedEntry feedEntry) {
        mRepository.update(feedEntry)
    }
}

Делая это, ваше представление может напрямую вызывать viewModel.update (feedEntries [0]).

Следует упомянуть одну важную вещь: mFeedEntryDAO.update (feedEntry) автоматически запускает обратный вызов onChanged вашего наблюдателя в getFeedEntrys LiveData.

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

Вы также можете использовать аннотацию @Dao в абстрактных классах, поэтому:

1. Создайте абстрактный @Dao BaseDao класс с абстрактными методами @Insert insert(entities) и с конкретным методом insert(entities, callback), который выполняет эту уродливую AsyncTask работу, вызывая абстрактный @Insert insert(entities) на onBackground и ваш обратный вызов на onPostExecute.
2. Сделайте свой FeedEntryDAO также абстрактным, расширяйте BaseDao и @Query методы абстрактными.

Результат использования в Kotlin довольно приятный:

database.entityDao().insert(entities) { ids ->
    // success
}

Поддерживаемые типы возвращаемых значений для каждой из поддерживаемых библиотек перечислены здесь < / а>. Я включил сюда таблицу для удобства.

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

@Dao
interface MyDao {
    @Query("SELECT first_name, last_name FROM user WHERE region IN (:regions)")
    fun loadUsersFromRegionsSync(regions: List<String>): LiveData<List<User>>
}

Примечание. Начиная с версии 1.0, Room использует список таблиц, доступных в запросе, чтобы решить, обновлять ли экземпляры LiveData.