Tactic for several different Room queries

Question

While refractoring an app I decided to use room (and other architecture components). Everything went well until I reached database querying, which is async. It is fine by me, I can update views with LiveData callbacks.

But the problem arose with smaller queries following each other - with no thread restrictions it was easy, you could use variables straight away.

In legacy code there are plenty of setups, where quite many small data pieces are required one after another, from different tables. E.g., querying if item exists in one table, some calculations, querying another table, etc.

Disabling async requirement for queries is not an option, I prefer using Room as intended.

First thought was to nest callbacks, but it is too ugly. Second thought was to query for all required data, start a method only after receiving all callbacks. It also does not sound nice and there are cases where one callback has data required for the other query.

Strangely I have not found any related forum posts or articles dealing with this problem. Did anyone handle it already? Any ideas?

Answer 1

Most @Dao methods are synchronous, returning their results on whatever thread you call them on. The exceptions are @Query methods with reactive return types, such as Maybe<List<Goal>> or LiveData<List<Goal>>, where the methods return the reactive type and the results are delivered asynchronously to subscribers.

So, for cases where you have more complex business logic, you have three main courses of action (that I can think of right now):

1. Use RxJava and try to squish all that business logic into an observable chain. There are a lot of RxJava operators, and so some combination of map(), flatMap(), switchMap(), weAreLostWhereDidWePutTheMap(), etc. might suffice.

2. Do the work on a background thread, mediated by a LiveData subclass, so the consumer can subscribe to the LiveData.

3. Use classic threading options (e.g., IntentService) or more modern replacements (e.g., JobIntentService).