Question: what's the relation to RxJava? #20

Closed
Konrad-Morawski opened this Issue Apr 19, 2016 · 28 comments

Comments

Projects
None yet
@Konrad-Morawski

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).

@JoseAlcerreca

This comment has been minimized.

Show comment
Hide comment
@JoseAlcerreca

JoseAlcerreca Apr 19, 2016

Collaborator

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.

Collaborator

JoseAlcerreca commented Apr 19, 2016

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.

@ernstsson

This comment has been minimized.

Show comment
Hide comment
@ernstsson

ernstsson Apr 19, 2016

Collaborator

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.

Collaborator

ernstsson commented Apr 19, 2016

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.

@ChadCSong

This comment has been minimized.

Show comment
Hide comment
@ChadCSong

ChadCSong Apr 19, 2016

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.

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.

@Konrad-Morawski

This comment has been minimized.

Show comment
Hide comment
@Konrad-Morawski

Konrad-Morawski Apr 19, 2016

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.

Konrad-Morawski commented Apr 19, 2016

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.

@Konrad-Morawski

This comment has been minimized.

Show comment
Hide comment
@Konrad-Morawski

Konrad-Morawski Apr 19, 2016

@ChadCSong

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.

Konrad-Morawski commented Apr 19, 2016

@ChadCSong

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.

@VictorAlbertos

This comment has been minimized.

Show comment
Hide comment
@VictorAlbertos

VictorAlbertos Apr 19, 2016

@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.

@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.

@ChadCSong

This comment has been minimized.

Show comment
Hide comment
@ChadCSong

ChadCSong Apr 19, 2016

@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. :)

@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. :)

@ZeroBrain

This comment has been minimized.

Show comment
Hide comment
@ZeroBrain

ZeroBrain Apr 19, 2016

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.

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.

@tonyshkurenko

This comment has been minimized.

Show comment
Hide comment
@tonyshkurenko

tonyshkurenko Apr 19, 2016

Is it better for the Android than RxJava? Since RxJava is for java and Agera is for Android (including lifecycle etc)?

Is it better for the Android than RxJava? Since RxJava is for java and Agera is for Android (including lifecycle etc)?

@ZeroBrain

This comment has been minimized.

Show comment
Hide comment
@ZeroBrain

ZeroBrain Apr 19, 2016

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.

ZeroBrain commented Apr 19, 2016

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.

@FranciscoE-Hudl

This comment has been minimized.

Show comment
Hide comment
@FranciscoE-Hudl

FranciscoE-Hudl Apr 19, 2016

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.

FranciscoE-Hudl commented Apr 19, 2016

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.

@yuanyang1991

This comment has been minimized.

Show comment
Hide comment

interesting

@randallmitchell

This comment has been minimized.

Show comment
Hide comment
@randallmitchell

randallmitchell Apr 19, 2016

@FranciscoE-Hudl example(s)? curious for your thoughts.

@FranciscoE-Hudl example(s)? curious for your thoughts.

@akarnokd

This comment has been minimized.

Show comment
Hide comment
@akarnokd

akarnokd Apr 19, 2016

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/removeListener and update() with or without an actual value. java.util.Observable and 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'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/removeListener and update() with or without an actual value. java.util.Observable and 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...

@peerless2012

This comment has been minimized.

Show comment
Hide comment
@peerless2012

peerless2012 Apr 20, 2016

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!

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!

@luckyandyzhang

This comment has been minimized.

Show comment
Hide comment
@luckyandyzhang

luckyandyzhang Apr 20, 2016

Interesting! I'll try it later :)

Interesting! I'll try it later :)

@TwentySevenC

This comment has been minimized.

Show comment
Hide comment

inspiring!!

@lzyzsd

This comment has been minimized.

Show comment
Hide comment
@lzyzsd

lzyzsd Apr 20, 2016

It looks like RxJava at first glance, but has more meaningful and easy understanding api names. Great Job!

lzyzsd commented Apr 20, 2016

It looks like RxJava at first glance, but has more meaningful and easy understanding api names. Great Job!

@diov diov referenced this issue in android-cn/android-discuss Apr 21, 2016

Open

谷歌最新推出的agera, #444

@monfera

This comment has been minimized.

Show comment
Hide comment
@monfera

monfera Apr 21, 2016

@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.

monfera commented Apr 21, 2016

@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.

@avalond

This comment has been minimized.

Show comment
Hide comment
@avalond

avalond Apr 25, 2016

Great Job!

avalond commented Apr 25, 2016

Great Job!

@JoseAlcerreca

This comment has been minimized.

Show comment
Hide comment
@JoseAlcerreca

JoseAlcerreca Apr 25, 2016

Collaborator

Closing this to limit noise.

Collaborator

JoseAlcerreca commented Apr 25, 2016

Closing this to limit noise.

@IgorGanapolsky

This comment has been minimized.

Show comment
Hide comment
@IgorGanapolsky

IgorGanapolsky Apr 25, 2016

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.

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.

@Konrad-Morawski

This comment has been minimized.

Show comment
Hide comment
@Konrad-Morawski

Konrad-Morawski Apr 25, 2016

@IgorGanapolsky I think the next version of RxJava is supposed to incorporate them

@IgorGanapolsky I think the next version of RxJava is supposed to incorporate them

@jponge

This comment has been minimized.

Show comment
Hide comment
@jponge

jponge Apr 25, 2016

@akarnokd You forgot MS Excel. That is the true 0th generation 😉

jponge commented Apr 25, 2016

@akarnokd You forgot MS Excel. That is the true 0th generation 😉

@whiter13

This comment has been minimized.

Show comment
Hide comment

@IgorGanapolsky Based on https://github.com/ReactiveX/RxJava/wiki/Reactive-Streams RxJava is going to support new Java Flow APIs.

@FranciscoE-Hudl

This comment has been minimized.

Show comment
Hide comment
@FranciscoE-Hudl

FranciscoE-Hudl Apr 26, 2016

@IgorGanapolsky Reactive Streams only gives the topmost interfaces for pub, sub, and producers. Java 9 isn't giving any default implementation.

FranciscoE-Hudl commented Apr 26, 2016

@IgorGanapolsky Reactive Streams only gives the topmost interfaces for pub, sub, and producers. Java 9 isn't giving any default implementation.

@WZero

This comment has been minimized.

Show comment
Hide comment
@WZero

WZero May 3, 2016

可以看看

WZero commented May 3, 2016

可以看看

@geolyth

This comment has been minimized.

Show comment
Hide comment
@geolyth

geolyth May 8, 2016

Thank you for sharing your work as open-source

geolyth commented May 8, 2016

Thank you for sharing your work as open-source

@google google locked and limited conversation to collaborators May 16, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.