Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Support for Android events #335
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
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
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.
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
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.
@mttkay Thank you for the response and the nice share of experiences
My idea with the event support is to remove the logic from
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.
this looks very interesting and in fact I sat down the other day to think
I was wondering if you guys already use this in production? I would not
I will also start to dabble with it when I'm back from vacation, I'm still
Thanks for working on this! It could go a long way in getting
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!
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?
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