RxJava Android Use with System Components like Services

[Tyler Chesley]

Does anyone have any experience or suggestions on using RxJava with some of the standard Android components like Service, SyncProvider, ContentProvider, etc? Or is RxJava really a way to supplant these traditional ways of writing Android apps? 

[Matthias]

Hi Tyler,

we use RxJava PublishSubjects as event brokers to communicate change between Android services and UI components. What we do is define an enum whose fields are PublishSubject, and every such field represents an "event queue". You use it like so:

// in UI component, e.g. Activity#onCreate

Event.MY_EVENT.subscribe(observer);

// in backend component, e.g. Service

Event.MY_EVENT.publish(eventObject);

Event is the enum; MY_EVENT an event queue. Calling publish calls onNext on the PublishSubject with the given data. This results in calls to onNext on all subscribers.

[Tyler Chesley]

Ah, interesting. Communication between services and the UI layer has always been a pain in the ass, especially communicating back errors. So with this approach you get the advantages of Android Services and RxJava. I like it. 

So Google really pushes this idea of using ContentProviders, SyncAdapters, CursorLoaders and a lot of the Android UI components are designed to work with these components using Android's ContentObserver to update the UI when changes occur. Do you still use any of these patterns or are you using RxJava to notify and update the UI as data changes or is loaded?

BTW, I watched your talk at DevCon2013 in London. Really enjoyed it.

[Matthias]

We still use ContentProvider for legacy reasons but are moving away from it to a storage layer which serves data via observables.

SyncAdapter is still useful if you want to get the benefits of syncs scheduled by the system (retry logic, connection reuse.) so we're not looking to replace it.

However, we're moving from a mostly Intent based messaging approach to Rx where ever it makes sense for us (in some cases it's more difficult, e.g. when sending messages from a widget, in which case you're forced to use PendingIntent.)

[Rostislav Chekan]

Hi, Matthias.

Can you explain, why enums are used? Or any suggestion for persistent observables? And whats the profit of using observables in services?

[Matthias]

It was a good choice back then, since enums are a simple way of building singletons.

Meanwhile, we've much improved out EventBus implementation and it's now based on injectable objects. It supports:

- an event queue builder to create queues with different types and behaviors (e.g. replaying vs non-replaying)

- queue types are now type safe (that was the biggest problem with using an enum)

- test event bus that allows you to easily assert that events are raised in unit tests, or to publish fake events

I would like to contribute this back to RxAndroid once the project breaks out of core. It's also matured in our app over the past 6 months so I feel comfortable about the value it adds (it also closes the gap between background objects like Android services and foreground objects like Activities, but we use for a lot more, to raise tracking events for instance.)

[Tyler Chesley]

I'd be really interested to see what you're doing. So how does your bus differ from more traditional event bus libraries like EventBus and Otto?

[Dmitry Suzdalev]

Hi Matthias.

You wrote:

// in backend component, e.g. Service
Event.MY_EVENT.publish(eventObject);

Event is the enum; MY_EVENT an event queue. Calling publish calls onNext on the PublishSubject with the given data. This results in calls to onNext on all subscribers. 

I wonder if there is any particular reason why you are calling publish() and not just onNext() directly?

If I understand correcty, publish will convert MY_EVENT to a connectable observable which will wait for a 'connect' call and not emit anything prior to that.

So were you using that 'connect' at some point in app's lifecycle to initiate event bus?