Pre-populating a LiveQuery


#1

Hey all, I’m using a LiveQuery to populate some Rx.Subjects to send data across my app. What I’m trying to figure out is the ‘correct’ path to take on initial app load. With a BehaviourSubject - it’s not a bad idea to pre-cache some data in there, that way my subscriptions will pull down something immediately when subscribed.

With a Livequery.start() <-- I believe this is ONLY run when a change happens - so no changes, no running… Is that accurate?

My thought was to run all my queries once on app bootup, and then start my liveQueries, but then I read this in the Android code:

/**
 * Sends the query to the server and returns an enumerator over the result rows (Synchronous).
 * Note: In a LiveQuery you should consider adding a ChangeListener and calling start() instead.
 */
@Override
@InterfaceAudience.Public
public QueryEnumerator run() throws CouchbaseLiteException {

That indicates that I probably don’t want to call run() - however, I explicitly want to have all my view data cached in memory to start - so, in this case, is it valid to do a:

liveQuery.run()
liveQuery.start() ?

Or is there some other hook I should be preferring?

Thanks!
-SJ

Update: Just a note - it appears as though the LiveQuery does run once, however, I just want to make sure this is the known, desired behaviour across platforms.


#2

I’m not sure what that question means. LiveQuery.start is run when you call it. It starts an asynchronous query, and also begins watching for database changes; soon after a database change, it will re-run the query and notify you if the results changed.

Calling LiveQuery.run will simply block until the query results are available. It’s not any faster than doing it the normal asynchronous way, and it can affect responsiveness of your app.