The art of rx
Problem friends Reactive is everywhere, it’s too much and no one can hide from it anymore. We all know how to write ASyncTask, Service or ContentProvider (I believe in it!). All we can turn bitmap or drove to the server for data. This is all pretty obvious. But still WE THINK that we can prepare the reagent correctly. This is not always the case.
What is proper reactive programming on Android ?
')
- Good day. Tell us in a few words about yourself. Where do you work, what do you do when you start promoting a reactive approach?
- Hello. My name is Matthew Malkov (in haNr lNevermore ). I’m an Android developer, probably 5-6 years old. Specifically, now I am engaged in Scala-development in one startup. The startup is in Moscow and I can't talk very much about it. But the bottom line is that it will be such a community platform, like Telegram. And I actually write it under Scala for Android.
The first project that I completely translated into RxJava was with 2GIS. Architecture, base, work with the network - everything. After that, I began to actively promote the RxJava framework and the reactive approach in general at conferences. Now I am writing on Scala, where I use a functional approach with might and main, and in my free time I am interested in the news of the jet world.
- Users of Habrahabr are certainly aware of the concept of reactive programming. Tell us about the features of this paradigm on Android and about reactive data streams.
- There are a lot of features related to reactive programming in Android programming. I would just like to say that not all the principles of reactive programming, which we will discuss later, fit well Android. Not to be unfounded: there is such a thing as scalability, which is usually understood as scalability over a large number of nodes, that is, it is some kind of server scalability. In Android, this is just scalability for threads, which is not “true scalability”. And it does not give such a big powerful impact on the system as a whole. Although, of course, it still gives, but in a different way.
Another feature is that a lot of Android is tied to imperative. That is, for mutability, for data variability, and specifically because of it, it is very difficult to wrap all this into reactive streams. This leads to the fact that you have to do a lot of hacks, which complicates things a lot. The imperativeness of Android forces a large number of developers to use such things as sabzhekty, which in fact were conceived and made in order to merge the world of the jet and the world imperative. But in fact, in fact, everyone uses it to easily wrap something in the Observable. This usually occurs at the expense of architecture, especially in the long run, on large projects. It turns out a hodgepodge of imperativeness and anyhow as reactiveness made on it. And all because many people are just too lazy to do the right thing or they don’t know exactly how right.
Actually, this is in general all, because in the correct architecture for Android, interaction with the network, caching and in general all the common business logic should not be tied to some kind of android parts. Therefore, in fact it is just business logic that works, as in any other projects. Not only in android.
- The main principles of reactive programming (fault tolerance, responsiveness, event-oriented, more opportunities for scaling) were formulated long ago. How much do you agree with these principles now?
- If we talk about the principles of the reactive manifest, which, strictly speaking, is the foundation and foundation of the ideology of reactive programming, then in my article on Habrahabr I detailed all these five principles and projected them onto Android development. And surely yes, I still agree with them. This is the backbone, these are the basic principles, the main effects that you should count on when you are developing using the reactive approach, and these are the main things for which you have to fight when you are using reactive force.
If we take fault tolerance, then you should always think about it. It's pretty easy, but you should always keep this in mind. Correctly handle errors and ask yourself whether you have processed and reviewed all the cases. Reactive gives you convenient devices for this, but you still have to think about it. And following all these principles allows you to build very good architectures and very good applications. And, as I have already said about scalability, in Android it doesn’t give any impact, unless it is being projected onto threads.
- What is more important: resource intensity or reliability? After all, there is a limit on the issue of streams in Android, you can throw budget devices over the “board”, simply because the application (has become) more demanding on resources :)
- Of course, and certainly, reliability is much more important, because now there is a trend in the android world that there are a lot of devices in the cheap segment. In India, they launched Android One, in America they sell phones for a few dollars. That is, there were very cheap and super-cheap android-smartphones, which certainly can not work as well as the Nexus 6P. Owners of such smartphones are becoming more and more and it is impossible to write them all off.
But, of course, it is also impossible to forget about resource intensity. It is not secondary, these two principles should go parallel to each other. In the same reactive area, we can, depending on the device, on the number of cores, set a different number of threads for operations. That is, let something run slower in budget devices, but it works accurately and works out clearly. Let it take more time, but nonetheless. Between these things it is worth finding a balance, but you need to keep the attention on both!
- You said that you are quite conservative in terms of technology and frameworks. Tell me about the RxJava framework and its pros and cons.
- There is such a thing as framework-driven development. This is a disease, probably the front end first. And the whole android world. Imagine that you can not solve some problem quickly, and of course you are too lazy to think and you are trying to find some kind of framework that was written by an unknown Hindu. This framework has version 1.0.0 or 1.0.1, that is, it patched it only once, and wrote three years ago. And he somehow satisfies your needs. The library is not expandable, it may fall, but somehow it does its work. This is very common and people are constantly pulling such frameworks into their project. I believe that it is impossible to do this, and therefore I write everywhere that I am rather conservative in this regard.
What can you say about the framework RxJava? It's very cool that there is already a powerful community around him, he often rules, bugs are fixed all the time. It's cool that the RxJava improvisation goes in different directions, i.e. they are aiming to quickly process some events, which is very important for the android, and to the same extent they are working to ensure that RxJava works well in the server part. For example, backpressure processing has already been added, and this is already a backend piece. Previously, there was only on-backpressure-buffer and on-backpressure-drop, and now they allow you to customize all these backpressure. In modern Android, we also have to deal with this, not only in high-load systems. Especially if the system is built on reactive, there are a lot of streams, one writes the data very quickly, and the other stream reads them slowly (slow Norwegian reader) and then the handler starts choking. And this also needs to be processed, and usually Android developers are not very aware of what backpressure is, and they are very surprised when they hear these words. And this is important and you need to know in the process of Android development.
RxJava certainly has some disadvantages too. The fact is that this is a completely different approach if we are talking about Android. So far in this OS, the imperative approach is more used, and RxJava is more functional. And very few people know how to cook RxJava properly. Even I myself do not super-correctly understand all the concepts of RxJava, because this is a very deep thing. But in my defense I can say that even at a practical level, not everyone understands this framework. :)
Also in the obvious drawbacks it should be noted that there is a lot of copying of objects. What this leads to is understandable. This is an additional burden on the GC.
- RxJava vs Bolts: Is there a fundamental difference between them? What are your personal preferences, and the potential of each of the specific approaches?
- I practically did not work with Bolts, so I tried to poke it clean. RxJava seems to me more native and concise in terms of syntax. It looks good and quite comfortable. But at the same time, the Bolts are deeper in terms of the reactive approach. Async and await alone deliver, which, by the way, is not in the “normal” RxJava. Bolts, it seems to me, are lower level and close to fundamental things.
The potential is clear and it is huge. Both one and the other library caused a huge impact on the development. RxJava, as far as I can see, influenced more, since Bolts is still less used. Which library to use is the choice of each, but it seems to me that RxJava is simpler in terms of syntax and understanding.
- How do you evaluate modern applications from top developers: 2GIS, Soundcloud, Facebook and what is their difference in the approach to the paradigm?
- These are completely different applications, starting with the fact that they are about different things. 2GIS about geolocation and maps, Soundcloud about music, and Facebook about social things. They are interestingly chosen, because they are written on completely different technologies. 2GIS is written in Qt 5 + QML, Soundcloud is a Java application using reactive RxJava, and Facebook is now written in Reactive Native. At least there is already a fundamental difference. Plus there is a difference in how they relate to their users.
That is, for example, Facebook does not comply with all guidelines and the Facebook messenger has such a thing as Pop-Up or Overlay. When you are chatting, you have on your desktop the face of the person with whom you are chatting. And by clicking on it, an application opens that overlaps everything that is now on the screen. It’s not very right to do that, and personally I am very annoyed.
Soundcloud tries to bring a lot of standard material-user interface, but nevertheless it is very beautiful. All of their tracks, which run when the music plays, it's all very cool and difficult in the development of the front-end.
Well, 2GIS is 2GIS. (by the way, you know what to pronounce correctly not “duplicates”, but “dvagis”? Now you know! :) They have their own zapars, they have QML and they can't seem to particularly use standard Android widgets. The bottom line is that they also try to follow the standard material design, but they do not always succeed.
I really like applications like Soundcloud or Telegram, which work very fast. I do not know how to evaluate them. Applications work stably and well, the design can be liked by someone, but not by someone. And they all have different paradigms.
- How do you evaluate the dynamic development of reactive programming and application in areas other than mobile development (Elm)?
- I can’t say anything about Elm, because I have never used it. The very same reactive programming now, as I see it, is gaining momentum. It found a very good niche in the server-side, many companies use it in their servers, which allows you to create well-scaled services that operate under heavy loads. In BigData, too, you can easily see things like Akka Streams and RxJava. This is such a “cool” (loaded, distributed and bla-bla) service like Netflix written in RxJava almost completely.
As for the frontend, I do not really follow the trends of the web. But I know that they write a lot on ClojureScript and that there is RxJS, which also seems to have found its niche. The main thing is that further all this should be promoted and developed, because the reactive area of many places already comes in handy and it will be offensive if the whole approach falls into something niche.
- What will your The Art of Rx talk about at the Mobius 2016 conference ?
- The report is planned to be quite philosophical, about where the reactivism goes and how to actually prepare it correctly. I will look at some aspects related to building an application architecture using this approach. The language does not turn to combine the words "architecture" and "programming." Oddly enough, these mistakes are made by many! How did I find out about this? Yes, very simple! I often see them in all forums. And why? Because people do a lot of things wrong in the reactive society itself and it’s gone, it becomes very difficult to support all this and the whole idea of the reactive approach seems to be crumbling. Well, in the report I will try to consider some architectural things inside RxJava itself. Namely: how the same flatmap actually works, I will show interesting things related to Zip, and I will touch on several internal things, for example, how Observable is created from Observable. In general, I prepared interesting pieces decently :).
Many people probably never even thought about it and I will try to teach everything in such a way that it is interesting and informative. The most important thing is informative.
useful links
What is proper reactive programming on Android ?
')
- Good day. Tell us in a few words about yourself. Where do you work, what do you do when you start promoting a reactive approach?
- Hello. My name is Matthew Malkov (in haNr lNevermore ). I’m an Android developer, probably 5-6 years old. Specifically, now I am engaged in Scala-development in one startup. The startup is in Moscow and I can't talk very much about it. But the bottom line is that it will be such a community platform, like Telegram. And I actually write it under Scala for Android.
The first project that I completely translated into RxJava was with 2GIS. Architecture, base, work with the network - everything. After that, I began to actively promote the RxJava framework and the reactive approach in general at conferences. Now I am writing on Scala, where I use a functional approach with might and main, and in my free time I am interested in the news of the jet world.
- Users of Habrahabr are certainly aware of the concept of reactive programming. Tell us about the features of this paradigm on Android and about reactive data streams.
- There are a lot of features related to reactive programming in Android programming. I would just like to say that not all the principles of reactive programming, which we will discuss later, fit well Android. Not to be unfounded: there is such a thing as scalability, which is usually understood as scalability over a large number of nodes, that is, it is some kind of server scalability. In Android, this is just scalability for threads, which is not “true scalability”. And it does not give such a big powerful impact on the system as a whole. Although, of course, it still gives, but in a different way.
Another feature is that a lot of Android is tied to imperative. That is, for mutability, for data variability, and specifically because of it, it is very difficult to wrap all this into reactive streams. This leads to the fact that you have to do a lot of hacks, which complicates things a lot. The imperativeness of Android forces a large number of developers to use such things as sabzhekty, which in fact were conceived and made in order to merge the world of the jet and the world imperative. But in fact, in fact, everyone uses it to easily wrap something in the Observable. This usually occurs at the expense of architecture, especially in the long run, on large projects. It turns out a hodgepodge of imperativeness and anyhow as reactiveness made on it. And all because many people are just too lazy to do the right thing or they don’t know exactly how right.
Actually, this is in general all, because in the correct architecture for Android, interaction with the network, caching and in general all the common business logic should not be tied to some kind of android parts. Therefore, in fact it is just business logic that works, as in any other projects. Not only in android.
- The main principles of reactive programming (fault tolerance, responsiveness, event-oriented, more opportunities for scaling) were formulated long ago. How much do you agree with these principles now?
- If we talk about the principles of the reactive manifest, which, strictly speaking, is the foundation and foundation of the ideology of reactive programming, then in my article on Habrahabr I detailed all these five principles and projected them onto Android development. And surely yes, I still agree with them. This is the backbone, these are the basic principles, the main effects that you should count on when you are developing using the reactive approach, and these are the main things for which you have to fight when you are using reactive force.
If we take fault tolerance, then you should always think about it. It's pretty easy, but you should always keep this in mind. Correctly handle errors and ask yourself whether you have processed and reviewed all the cases. Reactive gives you convenient devices for this, but you still have to think about it. And following all these principles allows you to build very good architectures and very good applications. And, as I have already said about scalability, in Android it doesn’t give any impact, unless it is being projected onto threads.
- What is more important: resource intensity or reliability? After all, there is a limit on the issue of streams in Android, you can throw budget devices over the “board”, simply because the application (has become) more demanding on resources :)
- Of course, and certainly, reliability is much more important, because now there is a trend in the android world that there are a lot of devices in the cheap segment. In India, they launched Android One, in America they sell phones for a few dollars. That is, there were very cheap and super-cheap android-smartphones, which certainly can not work as well as the Nexus 6P. Owners of such smartphones are becoming more and more and it is impossible to write them all off.
But, of course, it is also impossible to forget about resource intensity. It is not secondary, these two principles should go parallel to each other. In the same reactive area, we can, depending on the device, on the number of cores, set a different number of threads for operations. That is, let something run slower in budget devices, but it works accurately and works out clearly. Let it take more time, but nonetheless. Between these things it is worth finding a balance, but you need to keep the attention on both!
- You said that you are quite conservative in terms of technology and frameworks. Tell me about the RxJava framework and its pros and cons.
- There is such a thing as framework-driven development. This is a disease, probably the front end first. And the whole android world. Imagine that you can not solve some problem quickly, and of course you are too lazy to think and you are trying to find some kind of framework that was written by an unknown Hindu. This framework has version 1.0.0 or 1.0.1, that is, it patched it only once, and wrote three years ago. And he somehow satisfies your needs. The library is not expandable, it may fall, but somehow it does its work. This is very common and people are constantly pulling such frameworks into their project. I believe that it is impossible to do this, and therefore I write everywhere that I am rather conservative in this regard.
What can you say about the framework RxJava? It's very cool that there is already a powerful community around him, he often rules, bugs are fixed all the time. It's cool that the RxJava improvisation goes in different directions, i.e. they are aiming to quickly process some events, which is very important for the android, and to the same extent they are working to ensure that RxJava works well in the server part. For example, backpressure processing has already been added, and this is already a backend piece. Previously, there was only on-backpressure-buffer and on-backpressure-drop, and now they allow you to customize all these backpressure. In modern Android, we also have to deal with this, not only in high-load systems. Especially if the system is built on reactive, there are a lot of streams, one writes the data very quickly, and the other stream reads them slowly (slow Norwegian reader) and then the handler starts choking. And this also needs to be processed, and usually Android developers are not very aware of what backpressure is, and they are very surprised when they hear these words. And this is important and you need to know in the process of Android development.
RxJava certainly has some disadvantages too. The fact is that this is a completely different approach if we are talking about Android. So far in this OS, the imperative approach is more used, and RxJava is more functional. And very few people know how to cook RxJava properly. Even I myself do not super-correctly understand all the concepts of RxJava, because this is a very deep thing. But in my defense I can say that even at a practical level, not everyone understands this framework. :)
Also in the obvious drawbacks it should be noted that there is a lot of copying of objects. What this leads to is understandable. This is an additional burden on the GC.
- RxJava vs Bolts: Is there a fundamental difference between them? What are your personal preferences, and the potential of each of the specific approaches?
- I practically did not work with Bolts, so I tried to poke it clean. RxJava seems to me more native and concise in terms of syntax. It looks good and quite comfortable. But at the same time, the Bolts are deeper in terms of the reactive approach. Async and await alone deliver, which, by the way, is not in the “normal” RxJava. Bolts, it seems to me, are lower level and close to fundamental things.
The potential is clear and it is huge. Both one and the other library caused a huge impact on the development. RxJava, as far as I can see, influenced more, since Bolts is still less used. Which library to use is the choice of each, but it seems to me that RxJava is simpler in terms of syntax and understanding.
- How do you evaluate modern applications from top developers: 2GIS, Soundcloud, Facebook and what is their difference in the approach to the paradigm?
- These are completely different applications, starting with the fact that they are about different things. 2GIS about geolocation and maps, Soundcloud about music, and Facebook about social things. They are interestingly chosen, because they are written on completely different technologies. 2GIS is written in Qt 5 + QML, Soundcloud is a Java application using reactive RxJava, and Facebook is now written in Reactive Native. At least there is already a fundamental difference. Plus there is a difference in how they relate to their users.
That is, for example, Facebook does not comply with all guidelines and the Facebook messenger has such a thing as Pop-Up or Overlay. When you are chatting, you have on your desktop the face of the person with whom you are chatting. And by clicking on it, an application opens that overlaps everything that is now on the screen. It’s not very right to do that, and personally I am very annoyed.
Soundcloud tries to bring a lot of standard material-user interface, but nevertheless it is very beautiful. All of their tracks, which run when the music plays, it's all very cool and difficult in the development of the front-end.
Well, 2GIS is 2GIS. (by the way, you know what to pronounce correctly not “duplicates”, but “dvagis”? Now you know! :) They have their own zapars, they have QML and they can't seem to particularly use standard Android widgets. The bottom line is that they also try to follow the standard material design, but they do not always succeed.
I really like applications like Soundcloud or Telegram, which work very fast. I do not know how to evaluate them. Applications work stably and well, the design can be liked by someone, but not by someone. And they all have different paradigms.
- How do you evaluate the dynamic development of reactive programming and application in areas other than mobile development (Elm)?
- I can’t say anything about Elm, because I have never used it. The very same reactive programming now, as I see it, is gaining momentum. It found a very good niche in the server-side, many companies use it in their servers, which allows you to create well-scaled services that operate under heavy loads. In BigData, too, you can easily see things like Akka Streams and RxJava. This is such a “cool” (loaded, distributed and bla-bla) service like Netflix written in RxJava almost completely.
As for the frontend, I do not really follow the trends of the web. But I know that they write a lot on ClojureScript and that there is RxJS, which also seems to have found its niche. The main thing is that further all this should be promoted and developed, because the reactive area of many places already comes in handy and it will be offensive if the whole approach falls into something niche.
- What will your The Art of Rx talk about at the Mobius 2016 conference ?
- The report is planned to be quite philosophical, about where the reactivism goes and how to actually prepare it correctly. I will look at some aspects related to building an application architecture using this approach. The language does not turn to combine the words "architecture" and "programming." Oddly enough, these mistakes are made by many! How did I find out about this? Yes, very simple! I often see them in all forums. And why? Because people do a lot of things wrong in the reactive society itself and it’s gone, it becomes very difficult to support all this and the whole idea of the reactive approach seems to be crumbling. Well, in the report I will try to consider some architectural things inside RxJava itself. Namely: how the same flatmap actually works, I will show interesting things related to Zip, and I will touch on several internal things, for example, how Observable is created from Observable. In general, I prepared interesting pieces decently :).
Many people probably never even thought about it and I will try to teach everything in such a way that it is interesting and informative. The most important thing is informative.
useful links
- Video and slides from the report of Matthew on Mobius 2015 about reactivity;
- Article Matthew on Habré about reactive programming for Android;
- Announcements speeches Matthew on Mobius 2016 about Rx and Scala for Android .
Source: https://habr.com/ru/post/282784/
All Articles