I want to integrate RxJava in my Android app, but I can't seem to find an up-to-date, cohesive tutorial to do exactly that. Most tutorials I read usually step 1. very basic reactive concept, step 2. ..., step 3. profit.
+1 for Grokking RxJava, really great set of intros, especially from an Android perspective. Gonna pile my two cents on this as well. I think the easiest place to add
RxJava in an existing Android app would be your networking code. Square's Retrofit works really really well with Observables and you can do some very interesting things that imo are more immediately graspable than say writing reactive UI code.
I've prototyped UIs with RxJS (the javascript version of reactive extensions) both by itself and with Cycle.js. I've also used reactive programming in Perl 6. There are a lot of things to like about reactive programming, but anymore I'm not sure if it's the right answer. Let me first preface this by saying that I'm building upon thoughts presented (by someone else) here: http://blog.paralleluniverse.co/2015/08/07/scoped-continuati...
One problem with reactive programming (and also with promises), is that you are essentially using monadic composition in an imperative language. Because of the lack of special support for monads that you have in a language like Haskell, you have.to.chain.flow.control.methods. As a result of this, you lose access to the standard flow control the imperative language provides you, and you also generally end up with mangled stack traces. Now I know that rxjs5 is working on the stack trace problem through the usage of a recursive scheduler, but I'm not sure how this works on the Java side of things.
An alternative approach can be found in languages like Go and Erlang. In these languages you generally do not need to worry about exhausting a thread pool because they have made creating "threads" extremely cheap. As such, you can write normal imperative code that blocks, potentially indefinitely, and also still preserves stack traces and which uses the plain flow control structures (and error handling) of imperative programming.
Furthermore, if you couple this approach with CSP, you can leverage specialized systems that can "prove" (to a "good enough" level vs a mathematical proof level, although the latter is probably possible) that your design is correct. I'm not certain if a similar capability exists for reactive streams. See http://reaktor.com/blog/why-csp-matters-ii-how-do-i-know-syn...
Now granted, this discussion may be overkill for a small app that needs a little bit of reactivity. The article does mention that they are using this only for networking code. I've tried to use it in a much more general way, and I'm not yet fully convinced that it's the right approach in a typical imperative/OO language. Of course, if it seems like adding green threads to the language is nontrivial, as may be the case with javascript, then perhaps rxjs is the best option after all. :)
I'm familiar with Elm but haven't used it. I may not have properly communicated my point: FRP + imperative can be messy, and can force you to abandon the basic building blocks of an imperative language. It seems that Elm was designed from the ground up for FRP, so I have no objection to its use there.
As you point out, RxJS "Next" (~5) should simplify things a bunch.
On the other side (promises), EcmaScript standardization is progressing towards getting async/await baked into the language. There's also a slow lag, but native promise debugging support in browser dev tools is getting better. Some of that too is making sure to switch to libraries that take advantage of native promises when available (still a lot of promise libraries in the wild that are not aware of native promises).
> One problem with reactive programming (and also with promises), is that you are essentially using monadic composition in an imperative language. Because of the lack of special support for monads that you have in a language like Haskell, you have.to.chain.flow.control.methods. As a result of this, you lose access to the standard flow control the imperative language provides you, and you also generally end up with mangled stack traces. Now I know that rxjs5 is working on the stack trace problem through the usage of a recursive scheduler, but I'm not sure how this works on the Java side of things.
Your point is kind of validated by C#'s introduction of async/await at the language level. If Rx extensions for .NET would have lived up to their promise (and those are much, much more mature that the poor man's imitation that is RxJava), there would have been no need to introduce a completely unrelated mechanism for doing async work (and mandate its usage in the Universal Windows Platform).
I'm having trouble following this thread of conversation : isn't reactive more about restructuring your app as a composition of event streams that trigger actions and GUI state changes, rather than just simply performing async tasks ?
Fwiu, It tries to have you build your app as a static tree of flows, in a descriptive manner. It's a much broader goal.
Just wait until JS gets the :: function bind operator.
This wil yield 2 significant benefits.
First, Instead of the current hacky approach to implementing monads in JS, by which I mean adding operator methods to the observer 'monad' protype it'll be possible to use truly functional monads. Mixed with async functions I'd expect unnecessary blocking to become a non-issue and traditional prototype method chaining to become an anti-pattern.
Second, since it isn't necessary to add the operators at runtime it'll be possible to include them as separate ES6 module imports. That means, RxJS as well as any other library that extensively uses method chaining (ex lodash, jQuery) will finally benefit from tree shaking.
If this works the way I've been led to believe, minamilist libraries like jqlite will die off and Rollup.js will become the the de facto linker for building JS packages.
11 comments
[ 2.8 ms ] story [ 31.6 ms ] threadWe followed these tutorials at first, but it definitely just took a lot of time and trying things out. http://blog.danlew.net/2014/09/15/grokking-rxjava-part-1/
RxJava + Retrolambda has accelerated our development speed once we got a grip on it, but it does complicate our build process.
https://joluet.github.io/blog/2014/07/07/rxjava-retrofit/
This is a short post that I think nicely shows how Retofit+RxJava fit together
One problem with reactive programming (and also with promises), is that you are essentially using monadic composition in an imperative language. Because of the lack of special support for monads that you have in a language like Haskell, you have.to.chain.flow.control.methods. As a result of this, you lose access to the standard flow control the imperative language provides you, and you also generally end up with mangled stack traces. Now I know that rxjs5 is working on the stack trace problem through the usage of a recursive scheduler, but I'm not sure how this works on the Java side of things.
An alternative approach can be found in languages like Go and Erlang. In these languages you generally do not need to worry about exhausting a thread pool because they have made creating "threads" extremely cheap. As such, you can write normal imperative code that blocks, potentially indefinitely, and also still preserves stack traces and which uses the plain flow control structures (and error handling) of imperative programming.
Furthermore, if you couple this approach with CSP, you can leverage specialized systems that can "prove" (to a "good enough" level vs a mathematical proof level, although the latter is probably possible) that your design is correct. I'm not certain if a similar capability exists for reactive streams. See http://reaktor.com/blog/why-csp-matters-ii-how-do-i-know-syn...
Now granted, this discussion may be overkill for a small app that needs a little bit of reactivity. The article does mention that they are using this only for networking code. I've tried to use it in a much more general way, and I'm not yet fully convinced that it's the right approach in a typical imperative/OO language. Of course, if it seems like adding green threads to the language is nontrivial, as may be the case with javascript, then perhaps rxjs is the best option after all. :)
Do you know Elm ?
http://elm-lang.org
On the other side (promises), EcmaScript standardization is progressing towards getting async/await baked into the language. There's also a slow lag, but native promise debugging support in browser dev tools is getting better. Some of that too is making sure to switch to libraries that take advantage of native promises when available (still a lot of promise libraries in the wild that are not aware of native promises).
Your point is kind of validated by C#'s introduction of async/await at the language level. If Rx extensions for .NET would have lived up to their promise (and those are much, much more mature that the poor man's imitation that is RxJava), there would have been no need to introduce a completely unrelated mechanism for doing async work (and mandate its usage in the Universal Windows Platform).
Fwiu, It tries to have you build your app as a static tree of flows, in a descriptive manner. It's a much broader goal.
This wil yield 2 significant benefits.
First, Instead of the current hacky approach to implementing monads in JS, by which I mean adding operator methods to the observer 'monad' protype it'll be possible to use truly functional monads. Mixed with async functions I'd expect unnecessary blocking to become a non-issue and traditional prototype method chaining to become an anti-pattern.
Second, since it isn't necessary to add the operators at runtime it'll be possible to include them as separate ES6 module imports. That means, RxJS as well as any other library that extensively uses method chaining (ex lodash, jQuery) will finally benefit from tree shaking.
If this works the way I've been led to believe, minamilist libraries like jqlite will die off and Rollup.js will become the the de facto linker for building JS packages.