Question: what's the relation to RxJava?
Konrad-Morawski opened this issue ยท 28 comments
This looks like a very interesting proposition.
My question - it's quite an elephant in the room, I should think - is what's the relation between this library and RxJava?
Isn't it RxJava reinvented? Is it supposed to be more light-weight? Complementary? Or just inspired?
Nowhere do your docs seem to even acknowledge RxJava's existence (I'll stand corrected if I overlooked something), even though you're clearly adopting the same paradigm.
I'd be very grateful if you were willing to shed some light on this (disclaimer: I'm not affiliated with RxJava nor its creators; just another Android dev on the lookout for the new shiny thing).
We don't compare Agera with RxJava because it's not meant to be a replacement for it nor it's our opinion that it should be replaced.
Reactive programming has many flavors and Agera proposes one that we know works well for Android. It was developed internally as part of Google Play Movies and we like to open source code whenever possible.
It's a good question but I'm afraid the answer isn't as exciting as already mentioned Agera is just another flavor of reactive programming, developed (after but) independently of RxJava, without inspiration, reinvention, or relation. We simply found that this style worked well for us.
I wouldn't see it used together with RxJava. It's rather an either or situation. I'm sure there's cases where one is more suitable than the other.
I would say it's more light-weight, but not intentionally, only because this what was needed by us as we developed it.
With regards to the flavor I'd say one of the bigger differences are the Agera push event/pull data (vs push data in RX) as well as the event/function separation, as well as the Scala "Try" inspired error handling.
Agera seems a good way to realize reactive programming. From there doc, the new train of thought was built for Android life circle. RxJava is a pure way to Java not Android.
Thanks for your answers, guys (and for open-sourcing your work).
This really helps to clarify things. I believe the documentation would benefit if you included such a brief "what's what" in the intro : ) It's the differences that are most interesting, obviously there is no
one right approach to reactive programming.
RxJava is a pure way to Java not Android.
These aren't mutually exclusive, and there's the https://github.com/ReactiveX/RxAndroid supplement for platform specific stuff.
@ChadCSong, you can sync fragments and activities life cycle states easily with RxLifeCycle, for instance.
Indeed, I think most of rx libraries extensions has been created not for java programmers, but for android programmers.
@Konrad-Morawski
@VictorAlbertos
Thanks for your reminding. The differences I say tend to more about the libs' concept not the application.
More differences must be found in use. :)
I think this model is for Architecture as MVW or Reactive Architecture. since last 6 months, I've found MVW like this.
I think agera is easist model of Android MVW libraries or examples.
Is it better for the Android than RxJava? Since RxJava is for java and Agera is for Android (including lifecycle etc)?
we need to look a different perspective. because RxJava cannot be Architecture on itself.
for being architecture, we should make it wrap something.
but agera...it looks like reflex or redux.
agera's Repository is similar Store of redux
agera's Supplier is similar Action of redux
agera's Updatable is similar View of redux.
I don't think google makes a wheel again.
you know that ReactiveExtentions XX (RxJava, RxSwift...) != ReactJS of Facebook
we need to look a different perspective.
What RP principles/libraries is it inspired by? It seems to get out of the way of functional languages to be as Androidy as possible, in some interesting ways.
The update Cancellable field model given in the samples, even with locking methods, is bound to error by common Android pitfalls like onClick firing after Activity is destroyed.
interesting
@FranciscoE-Hudl example(s)? curious for your thoughts.
I've glanced over the documentation and my impression is that Agera is almost a 1st generation reactive library with strong 0th generation ties. To put it in perspective:
- 0th generation is when you have
addListener/removeListenerandupdate()with or without an actual value.java.util.Observableand most GUI frameworks can be considered 0th gen. It is possible, although generally cumbersome to make a composable, native library out of them. - 1st generation is what the Microsoft folks invented back in ~2009. It's a step upwards with straightforward architecture and great composability. However, their concept has some shortcomings discovered in late ~2013. Example: Rx.NET, Reactive4Java
- 2nd generation is what RxJava 1.x currently is. It fixes the synchronous cancellation problem, introduced some optional backpressure and the notion of lifting into a chain.
- 3rd generation is the Reactive-Streams initiative with fleshed out, standardized APIs, designed ~2015. The architecture is reactive-push with backpressure. Examples are Reactor 1, 2 and Akka-Streams.
- 4th generation is the cutting edge of the field. It builds on Reactive-Streams and adds an adaptive push-pull option, in the form of operator-fusion, that allows both efficient synchronous and asynchronous use. Example is Reactor 2.5. (RxJava 2.x is in between 3 and 4 right now).
I know this is an optional library, don't use it if you don't like it. Don't get me wrong, it's not about how many operators you have, how strong do you inline your reactive library with the underlying platform or that you don't care about backpressure in GUI. It's about the architectural experiences, pitfalls and possibilities of the Rx family that maybe could have helped/inspired this library. If Agera were based on Reactive-Streams or designed in spirit of it, I'd say okay, why not.
As for the original questions:
Isn't it RxJava reinvented?
No.
Is it supposed to be more light-weight?
Seems so API-vise, not sure about performance-vise
Complementary?
As complementary as addListener-based APIs are in general. The name conflict of Observable and Supplier may be of some inconvenience.
Or just inspired?
Apparently not inspired by Rx.
Google Play Movies and we like to open source code whenever possible
In Netflix' footsteps I see. You see, they got significant help along the way...
I come here to see what's the different from RXJava,and i also recognize that there is a new way to code now.Hope this is aswom!
Interesting! I'll try it later :)
inspiring!!
It looks like RxJava at first glance, but has more meaningful and easy understanding api names. Great Job!
@akarnokd talking about these in terms of generations is interesting, thanks for the insight! I wonder what future generation number will implement Conal Elliott's vision, which I understand is more denotational, and 'late-binds' issues such as backpressure, pull vs push, handling of discretization error etc. An analogy (his one, me citing probably improperly) is like raster graphics vs. SVG. In the latter, you denote the things and the rasterization is essentially an afterthought, as, of course, screens and CPUs can only operate in a discretized world. In present-day FRP the core 'business' (or game, edu, whatever) logic is intermingled with aspects such as throttling, sampling, diffing etc. between almost every single connection between functional nodes.
I believe Conal's idea is, let's define a game etc. as if we didn't have to worry about incidental present-day constraints, and let's defer downsampling, backpressure handling etc. until a target environment is selected. For example, an Android game could be written with high performance, resolution etc. in mind, e.g. flagship handheld of 2018, or even, flagship home console of 2020. Then the late-binding of discretization would be such that even today's mid-tier and low-end Android phones can be targeted, tweaking tradeoffs via sliders such as loss of frame rate, loss of spatial resolution, loss of texture quality, less frequent updates from or pushes to the network (multiplayer), tradeoff of rendering accuracy vs. stutter-free game play, level of AI, number of enemies etc.
Great Job!
Closing this to limit noise.
Wait a second. Aren't Java 9's Flow APIs gonna supersede both RxJava and Agera? Am I missing something, or are we gonna end up with a handful of redundant reactive programming libraries.
@IgorGanapolsky I think the next version of RxJava is supposed to incorporate them
@IgorGanapolsky Based on https://github.com/ReactiveX/RxJava/wiki/Reactive-Streams RxJava is going to support new Java Flow APIs.
@IgorGanapolsky Reactive Streams only gives the topmost interfaces for pub, sub, and producers. Java 9 isn't giving any default implementation.
ๅฏไปฅ็็
Thank you for sharing your work as open-source