Rx: StorIOContentResolver updates running on StorIOContentResolverNotificationsThread

Hello, I’ve noticed that when using the StorIOContentResolver API, all emissions triggered by a contentResolver notifications come back on the same thread, so doing a long running operation on the same observable can delay notifications being received by another listener. For instance:

PreparedGetListOfObjects<> query = storIOSQLite
                .get()
                .listOfObjects(Tweet.class)
                .withQuery(TweetsTable.query)
                .prepare()

Subscription subA = query.asRxObservable()
         .doOnNext(tweets -> Log.d("TEST", "Logs immediately!"))
         .flatMap(tweets -> lonRunningObservable()) /* Say this runs for 10 seconds */
         .subscribe()


Subscription subB = query.asRxObservable()
         /* Delayed if notification was delivered to subscriber A*/
         .doOnNext(tweets -> Log.d("TEST", "Sometimes logs 10 seconds late!")) 
         .subscribe()
...

final List<Tweet> tweets = new ArrayList<Tweet>();
tweets.add(Tweet.newTweet("artem_zin", "Cool Tweet"));
storIOSQLite
     .put()
     .objects(tweets)
     .prepare()
     .asRxObservable()
     .subscribe();

I realize that it can be avoided by switching to another thread with observeOn(), but aren’t updates supposed to use the default (or specified) scheduler?

[artem-zinnatullin]

@geralt-encore what do you think about proposal?

[nikitin-da]

internally moving the ContentObserver emission to the i/o pool

Since we should initially receive all notifications on the common handler thread (https://github.com/pushtorefresh/storio/blob/master/storio-content-resolver/src/main/java/com/pushtorefresh/storio/contentresolver/impl/RxChangesObserver.java#L40) moving emission to thread from io pool will add delay due to thread switching =( If user will agree with such delay defaultObserveOnScheduler(Schedulers.io()) will do this trick If you prefer to manually configure schedulers on every case and get rid of such delay - simply use defaultObserveOnScheduler(null)

asRxObservable(Scheduler)

I’m not sure that asRxObservable(Scheduler) will give more benefits over asRxObservable().observerOn(Scheduler)