Support for Android events

[andrewhr]

Hello,

TL;DR: I want to contribute on Android support

In the past few weeks I'm become very interested in FRP in general, and how it applies to better wire code in GUI applications - my main interest is to build more elegant Android code.

So, I found that here on RxJava there is an initial code to support run RxJava on Android, which is really awesome! So, I've started to work on some code to try to grasp how to work with Rx.

After that, I want to have some helper methods to transform Android event listeners into RxJava's Subjects, so we can really start to make it useful to cleanup our Activity/Fragment code.

There is something like that waiting to be published? Can I start to draft some implementation? Someone is taking this task and want some help?

@mttkay I saw that you commited on this "area" of the project... are you the person to ask about this stuff?

Thank you all for the attention and sorry about the large message 😄

[mttkay]

Hi Andrew,

at SoundCloud we're using RxJava on the service layer. With the exception of adapters, which can be hooked up nicely to an Observable exposed by a service object, we haven't given other UI components much thought. The main reason I guess being that there is less to be gained out of it. I see RxJava's main benefits in the reliability and ease gained where asynchronous event composition is required. However, neither seem very likely to me to occur in, say, a TextView or other widgets/UI components. When I say that I suppose I mean RxJava specifically, not FRP in general. ReactiveCocoa for instances takes Rx into the view layer, but it supports heterogeneous signals that can be mapped to view properties, which is very powerful since it allows a view to directly react to state change emitted by an observable sequence. With (Rx)Java one would have to jump through a few hoops to accomplish that.

That's not to say I'm not interested in investigating in that direction! If you have ideas or even some working components already I'd be curious how such a solution could look like. I'll be on vacation for 2 weeks starting Tuesday, so apologies if I reply infrequently.

[mttkay]

That reminds me. Another area where I think RxJava adds benefits and convenience on Android is when used as a simple event bus. Due to its nature it's extremely simple to build application global pub-sub style interaction with Rx. The Subject class lends itself well for that, since every system event can be described using a Subject to which observers subscribe. I wrote a tiny event bus using a Java enum, in which every enum constant was a Subject. The enum had a fire method to signal each event, so that observers would receive it. The data transmitted through the subject could then be an event object.

That way you can e.g. fan out a state change to multiple views at once. I can see also benefits in this in replacing many occasions where Intents or Handler messages are cumbersome to use.

[andrewhr]

@mttkay Thank you for the response and the nice share of experiences 😄

My idea with the event support is to remove the logic from Activity by creating new objects, in a similar way to ViewModel/Passive Presenter. So we can write our business logic and test in separation from Android code. Even without any separation, our code becomes much more declarative, and I think that we could have some benefit from this approach.

I will try to put some experimental project online and link here so you can see what I'm talking about.

Thank you again for your attention.

[andrewhr]

Hello!

Here is a short example of what I'm thinking about with extending RxJava. The implementation of the Events and Properties is quite naive, but served as a sort of API exploration.

There is anyone who also thinks that this extensions are useful?

[jmhofer]

I definitely find this useful. Especially as it can be combined with Scala even for Android development.

[andrewhr]

Thanks @jmhofer for the feedback. I will continue to explore in a separate project before making any PR to official project.

[mttkay]

Andrew,

this looks very interesting and in fact I sat down the other day to think
about how this could look like and came up with something very similar.

I was wondering if you guys already use this in production? I would not
like the idea of adding features to the library prematurely, not unless the
code has proven to work in a number of production scenarios.

I will also start to dabble with it when I'm back from vacation, I'm still
traveling for the next 10 days.

Thanks for working on this! It could go a long way in getting
rxjava-android closer to the feature set of ReactiveCocoa.
On Sep 7, 2013 3:02 AM, "Andrew Rosa" notifications@github.com wrote:

Thanks @jmhofer https://github.com/jmhofer for the feedback. I will
continue to explore in a separate project before making any PR to official
project.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/335#issuecomment-23978488
.

[andrewhr]

Hello @mttkay,

Honestly, we don't have any code in production... yet. I'm still trying to get around the concepts. But I agree with you that we need something more solid to put into RxJava itself.

What I've started to do was converting some code from our apps to Rx model, and in the past days I've done for a meaningful amount of the codebase. This is helping me to evaluate and extend the helpers I've published before.

As soon I ship this application I can give more concrete feedback about the experience.

Thank you again for the attention spent here. I really appreciate!

[mttkay]

Sounds good! Looking forward to it

[zsxwing]

Hi, @andrewhr, I also think this is very helpful. However, I have one problem about Android events. Most of Android listeners are set via set***Listeners. If some view has already been set a listener, how do you handle it? Override it directly? Or wrap the old listener in a new listener?

[andrewhr]

Hi @zsxwing!

Actually, I have only one project in production, which was ported to use the helpers similar to those on the sample project that I shared.

In the current implementation, I found the exact problem that you described. I opted for just override the listeners. The few cases where I need to reuse an observable, I just create a temporary reference for reusing. I though that it's fine because my in this first attempt I only want to experiment with some sort of API (and also want to gain some experience with the tools... this is my first real project with FRP style).

I've never tough about listener overriding before, but I've imagined some kind of Context-like object to create the observers, instead of just using static helpers... so it can keep all references and memoize if necessary. But I'm afraid that it would to some over complication 😟

[benjchristensen]

Is work still happening on this issue?

[benjchristensen]

Closing out as this thread has gone quiet ... please re-open or start something new if applicable.

The RxJava Google Groups is a good place for discussion as well: https://groups.google.com/forum/#!forum/rxjava