Released Episode 3, discussion: RxJava with its core developer David Karnok

[artem-zinnatullin]

Episode was divided into two parts, second part will be released in a few days after first.

Discussion before episode. Show notes for Part 1.

[sebaslogen]

Thanks for the episode, nice improvement from the previous and thanks to David for all the interesting info.

Now I'm even more puzzled about RxJava 2. From the discussion I understand it's a big change for developers of the RxJava 2 library, but for actual users of the library I don't understand if there will be any advantage, besides the performance gains of using a better architecture below. Is there any other noteworthy difference?

[artem-zinnatullin]

Let's ask David! cc @akarnokd

// As I understand, for users there will be more types in the API: Observable with backpressure and without + probably possibility to override applied operators.

Thanks for the feedback!

[akarnokd]

Back in last September, RxJava 2.x had more overloads of common operators with error-delay and buffer-sizing options. Now RxJava 1.x API is catching up.

The primary benefit is the native Reactive-Streams compliance that let's you talk to Akka-Streams and Reactor-Core directly (among other libraries).

The second advantage is that you can build non-backpressured sequences via NbpObservable (name pending), mainly suitable for GUI-related activities or shorter sequences that don't really need backpressure.

[jaggernod]

Thank you for creating the podcast. I found the Internet lacking in more advanced topics and hearing for the tenth time an introduction to Rx doesn't help anybody.

One comment that I have is that in the beginning I got a bit distracted with the particular accent of yours, but this lasted just a moment as I got to enjoy the content a lot. Plus I myself have "an accent".

Please continue addressing hard topics in-depth since we seem to lack them in Android scene.

P. S. Is there any place that the community could suggest topics?

[artem-zinnatullin]

Hi, @jaggernod

hearing for the tenth time an introduction to Rx doesn't help anybody

Huge +1 :)

One comment that I have is that in the beginning I got a bit distracted with the particular accent of yours, but this lasted just a moment as I got to enjoy the content a lot. Plus I myself have "an accent".

Yeah, hope I'll eliminate my accent one day. Anyway, I'll try to speak less in the episodes, so this should help too haha.

Please continue addressing hard topics in-depth since we seem to lack them in Android scene.

Will try, btw podcast will be changed in near future, hope you'll like the change, unfortunately I'm very busy at the moment and will be in such state for some time, but I hope we'll deliver new episode in next few weeks.

Regarding suggestions for new episodes I've created an issue for that #34, please feel free to add something there.

Thank you for listening and feedback!

[akarnokd]

hearing for the tenth time an introduction to Rx doesn't help anybody

What are the particular, non intro, topics you want to read/hear about?

[jaggernod]

Hi David, I'm a fun of your blog. Thank you for sharing your knowledge.

As for what other RX related I'd like to hear is:

1. How much easier would RxJava 2.0 be to debug. Huge stack traces make it impossible to debug long Rx chains.
2. I know that you are not using Rx that much in your line of work, but would be really nice to hear how to use some more complex operators in creative ways. Let's take for example window(). When, how and why?

Thanks a lot.

[akarnokd]

1 How much easier would RxJava 2.0 be to debug. Huge stack traces make it impossible to debug long Rx chains.

Not much. You'll get more meaningful stacktrace entries because massively reduced amount of anonymous inner classes.

I'm debugging RxJava all the time and usually, the top of the stacktrace points to where problems come from: the user provided code. Smaller cases are when the developer's expectations wasn't met such as backpressure exceptions and single() exceptions.

The debugging problem I encountered was with RxNetty where the code contains hundreds of similarly looking sequences with exit points. Setting a breakpoint in some class and seeing the stacktrace didn't help much identifying where the particular sequence was assembled in the library. So it was not about where the value came from but which sequence am I currently in. In theory, the RxJava hooks allows one to wrap Observables and Subscribers and you can add wrappers that capture the current stacktrace when the operators were assembled. You can then look at the variables in the debug window and locate code more easily.

2 I know that you are not using Rx that much in your line of work, but would be really nice to hear how to use some more complex operators in creative ways. Let's take for example window(). When, how and why?

I personally haven't encountered any use for window(). You can have a look at Intro to Rx for some examples. The use I can imagine is to go parallel with fixed-length windows:

range(1, 1000).window(16).flatMap(w -> w.observeOn(Schedulers.computation().map(...)))

There are also the boundary-controlled version of window where you can take other observables and then open and close windows:

PublishSubject<Integer> record = PublishSubject.create();
PublishSubject<Integer> stop = PublishSubject.create();

events.window(record, v -> stop).flatMap(w -> ...).subscribe(...)

Then you wire up record and stop to some buttons.

[artem-zinnatullin]

I'm debugging RxJava all the time and usually, the top of the stacktrace points to where problems come from: the user provided code.

Main problem is when source emits on the different thread that subscribe chain was established on, then you have no reference to the user code in the stacktrace. But we're currently successfully solving it with similar solution https://github.com/ReactiveX/RxJava/issues/3521

[jaggernod]

Thank you guys for the answer to the questions so quickly! Happy to hear that RxJava 2 will provide shorter stack traces. As for the tracing where events came from, I understand the problem. Even faced it. In my previous company, we made a custom Observable which had an AOP-like ways of recording the paths of the events in streams and visualised it in a web application. Looked pretty nice, but was just a prototype and of course, the performance plummeted :)

And the window question a general one. Maybe more directed to @artem-zinnatullin and his mission to teach proper Android. There are so many operators that are not that much used. Library of real life examples might encourage and teach in which cases those 'advanced' operators can be used. I remember and old .Net's RX video that showed window example based on opening and closing times of a grocery store. They gathered some data about the store based on the collected sessions. Don't remember the link to that. But it was a nice visualisation. I think that people with functional background have little problems with the operators but, java and especially Android crowd usually have little exposure to FRP.

[artem-zinnatullin]

Got it, ok, will try. Currently working on a project where whole interaction with UI made via RxJava, every UI component is reactive.

On Fri, 15 Apr 2016, 13:02 Paweł Polański, notifications@github.com wrote:

Thank you guys for the answer to the questions so quickly! Happy to hear that RxJava 2 will provide shorter stack traces. As for the tracing where events came from, I understand the problem. Even faced it. In my previous company, we made a custom Observable which had an AOP-like ways of recording the paths of the events in streams and visualised it in a web application. Looked pretty nice, but was just a prototype and of course, the performance plummeted :)

And the window question a general one. Maybe more directed to @artem-zinnatullin https://github.com/artem-zinnatullin and his mission to teach proper Android. There are so many operators that are not that much used. Library of real life examples might encourage and teach in which cases those 'advanced' operators can be used. I remember and old .Net's RX video that showed window example based on opening and closing times of a grocery store. They gathered some data about the store based on the collected sessions. Don't remember the link to that. But it was a nice visualisation. I think that people with functional background have little problems with the operators but, java and especially Android crowd usually have little exposure to FRP.

— You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub https://github.com/artem-zinnatullin/TheContext-Podcast/issues/25#issuecomment-210397730

[jaggernod]

Got it, ok, will try. Currently working on a project where whole interaction with UI made via RxJava, every UI component is reactive.

:+1:

[lenguyenthanh]

@artem-zinnatullin are you working on MVI like Cycle.js. I'm trying to do the same thing. My idea comes from this blog of @sockeqwe: http://hannesdorfmann.com/android/model-view-intent

[artem-zinnatullin]

Not exactly, we have MVVM (without data binding)

On Fri, 15 Apr 2016, 15:30 Thanh Le, notifications@github.com wrote:

@artem-zinnatullin https://github.com/artem-zinnatullin are you working on MVI like Cycle.js. I'm trying to do the same thing. My idea comes from this blog of @sockeqwe https://github.com/sockeqwe: http://hannesdorfmann.com/android/model-view-intent

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/artem-zinnatullin/TheContext-Podcast/issues/25#issuecomment-210446192

[lenguyenthanh]

Interesting, I don't like data binding too. My work is on progress but I still have some difficulties when trying to make it fully functional.

[dimsuz]

These were two very interesting and nice episodes, thanks to you and David!

[IgorGanapolsky]

I'd like to know - if I'm a beginner coming to RxJava for Android development, how should I decide which version to learn - 1 or 2? They are similar, but I'd rather focus on the one that will be most useful in the near future.

Thank you for this episode!

[artem-zinnatullin]

@IgorGanapolsky definitely pick v2!