 So good afternoon everybody, I am Garewa Jan and I've been working as an Android developer since past three years. Currently I'm working with the company Namels Fueled and we have developed and worked with a lot of clients which are summer start-ups, some are well established and some of them are like quiz-up, write-it pharmacy, Barney's New York, Barnes & Noble College, Vogue, and so it's a service-based company and we get to try a lot of different technologies and new stuff and from past two years I would say we have been like really delving deep into reactive and average ever and trying to use it in almost all of our apps and also it's one of the libraries that we make sure to use in all the apps that we write. So that is why my talk is on RxJava, it's called Rxify which is a simple spell for complex RxJava operators. So who is this talk for? People who are already working on RxJava, you might find that there is more to learn by this talk and people who are beginners I'd say that this is high time you start Rxifying your apps because it's highly useful and it has a lot of advantages and it makes things easier which I'm going to talk about in the presentation and for all the pros out there just attend sit and relax talk is going to be fun. So what is this talk about? It's about Rxify. So how many of you like RxJava? How many of you don't know about RxJava? How many of you like Harry Potter? So in this talk I might use a little of Harry Potter references but I'll make sure not to overuse them. So Rxify it terms the use of RxJava or use of the operators which comes along with RxJava and I'm going to focus on RxJava making our life simpler instead of like disturbing us a lot and I would say that what we need to do is we just need to cast a little spell that is use any operator and we're good to go perform any task and it will be really easy. So what is RxJava? RxJava is reactive extensions for JVM, our virtual machine and RxJava mainly works on the observer pattern that is for emitting sequences and data and events. I'll talk about the observer pattern not much in detail as I'll just show a little introduction model. How RxJava is making our life simpler? By using RxJava we do not have to worry about things like low-level threading synchronization background processing exponential backups retrying repeating and things like that. When you code it without RxJava you might have to use a lot of variables and a lot of stuff you'd have to use a lot of your head and if you just use RxJava it will be less error prone. So why am I giving the stock? So RxJava and the RxJava operators to some people it might seem a little overwhelming in the building and they might get a little confused because RxJava and its operators might be complex at first and it might be hard to understand and some of the marble diagrams of the operators they're a little too much. So what I'm suggesting is start RxJavaing your apps because as you might have heard about the Android podcast, fragmented podcast, Kaushik Gopal and Don Filger. Kaushik Gopal recently introduced many renowned developers in the Android community in the Google IO 2016 and most of them the top three apps they told us about that they're using is RxJava, Retrofit and Dagger. So start RxJavaing your apps. So let me go over the basics. We have three things, three main things. Observable, Subscriber and Actions. Observable is like anything that is producing a stream of wind emitting items. Subscriber consumes those items and actions are whenever any item is emitted in a stream, on next is called and which is followed by on complete if everything goes well and if God forbid you get an error, on error is called. It can get called even without on next being called or it can get called after some series of events have been emitted. So between producer and consumer that is observable and your subscriber we have some operators that can modify your data and we have different schedulers and schedulers are you're really good friend because they can make things easier. We have the main thread for Android, we have the computation thread that is the background thread and there's also a test scheduler which makes testing easier. So this is the basic observable pattern. We have a producer on one end and we have a consumer on the other end. The producer is emitting item that way B and C the consumer or the subscriber is consuming item. This is a simple observable pattern which on which are our or the reactor programming works. Let's create a simple observable now. We have a string called Hello World. We're going to use the justify spell on it, or you can call it just operator. From this we'll get the observable string. So this is a basic marvel diagram which shows time on the X axis and one item is getting emitted. That is a string Hello World by just using it just operator. So next we have an array of strings. We're going to use the from operator here or in our is our two which is now new you can like use from my table or from which was applicable and we get another stream of strings like A, B and C. Take a look at some spells or operators we which you should know. First is a map operator or the map widely known as map. So what map does is it transforms every item of a collection of items. It applies a function to each and every item. If I talk technically it transforms the items emitted by an observable by applying a function to each item. So this is a simple example. We have an observable of integers emitting one, two and three. We want to apply a map operator on it. So it's a map you spell we can apply on one. We can multiply it by 10 or two. We can multiply it by 10. So the function is going to be multiplied by 10. Let's see how we can do that. So this is a simple code snippet. We're first creating an observable from these three integers where then we're applying the map function. And we're supplying it a function that how do we want to modify the stream? So here simply we are multiplying it by 10. So we get 10, 20 and 30 as a stream. So in our Java, the func one thing you just saw this func one which we are supplying as an argument. It has changed to function and there is also something called func two which takes two inputs. It has become by function to see by function as well. So this is what it has become. So you don't really need to worry about all this because I'm not sure you are everything. It gets auto rated. But still it's good to know that function is when we have only one input and we're multiplying it by 10. So next is the flat map m spell or the flat map operator. What flat map does is as we saw just now map was converting one item into another item. What flat map does is it takes one item it convert it into more than one item like any list of items. Then what it does is it combines those items into stream. So technically we can transform the items emitted by an observable into observable then flatten the emissions from those into a single observer. Let's see by an example. So these, this is a simple observable which is emitting hello world and how are you? Hello world is getting converted into hello and world. How are you getting converted into how and RMU? Then it is getting combined into another stream. That is what flat map does. This is how we can do that. We'll again apply a function to it and here I'm just splitting it. The main thing to remember is that flat map returns an observable and a map returns the type of whichever data type you are passing to it. Why we're returning an observable here because from one item we want to emit more than one items and observable itself emits more than one item. So next is the filter room spell or the filter operator. As the name suggests, we have a collection of items. It filters those collections based on some conditions. So technically we are going to emit only those items from an observable that pass up predicate test. So here we have an observable of integers from one to seven. What we want to do is we want to filter out only the odd numbers. We're going to apply the filter room spell over it. We're going to pass a function to it that is percentile two equal to one and it will just filter out the odd numbers for us. So let's take a look at the some complex spells which are doing all the magic out there. Complex operators. First one is the Zipyosa spell or the zip operator. What zip operator does is it combines multiple collection together according to some function and then emits the result of the combination. For example, if you're getting something from one API call and you're getting something else from another API call, then you want to get those two results and you want to create another object from those two results. That is what zip will do. Technically combine the emissions of multiple observers together via specified function and emit single items for each combination based on the results of this function. So this is the marble diagram for zip. We have different observable streams. It takes one item out of this each and every stream and then it converts into a different thing. Yes, it looks a little overwhelming at the beginning. So instead just we'll take an example. We'll take a fictional example that if we want to create a polyjuice portion and Hermione wants to prepare this portion, she's waiting for the task Ron to bring her bring her fluff suite which is an ingredient of the polyjuice portion. She's waiting for task Harry to bring her hair that is here of some person which is also an ingredient of the polyjuice portion. So both tasks Ron, R and H are executing asynchronously and only after Ron, R and H have executed then we can start preparing the polyjuice portion. So here's a marble diagram for this problem. One observable is emitting fluff suite, one another observable is emitting crab hair and then we want to combine these two after both of these operations or tasks have completed and we want to create a polyjuice portion. What we can do is we can simply apply the zip POSUS spell over it. This is the zip operator. This is the static function of the observable class. We'll give it the fluff suite observable, we'll give it the hair observable and here we'll use the by function because the input is two objects and we are converting into a polyjuice. So can you relate this polyjuice problem to any coding problem? It's when multiple API calls are executing simultaneously then you can use this problem to do some things I'm going to demo about it, do a demo about it. Let's take a look at the other spells concatify that is a concat operator and merge use that is the merge operator. First let's take a look at the technical definitions of these two. What concat operator does is it emits the emissions from two or more observables without interleaving them and merge it combines multiple observables into one by merging their emissions. So the thing is concat can interleave and merge operator it cannot interleave. Concat and merge they both have the similarity that they both will combine similar type of data that is and observables having same types and that is the same thing with merge. So let's take an example we have two streams two streams emitting four two streams emitting integers one two three and four and eight and nine. We apply the concatify operator on it and as you can see it will first emit all the items from the first stream and then it will emit the second stream whereas merge will emit as in one when the items will come. So one is getting emitted then as eight is coming so it is getting emitted and then two and then so on. So what was this concat and merge all about? So I'll take have a given example of another fictional problem and let's try to imply these operators on that fictional problem. So this problem is called Snape's assignment. Professor Snape has requested all the students to write an essay on where was they can write any essay they have to write an essay and the students who will turn in the essay first will get more points than the ones submitting later. So students are divided into four houses Gryffindor, Slytherin, Hufflepuff and Ravenclaw. So this is how the assignment submission is done. As you can see the Gryffindor person is submitting the assignment first then Slytherin then Hufflepuff and so on. So there's a little child, weird child who want to like jinx this assignment evaluate and he wants to get the more points and he wants his house to win that's all he's called Draco. So he's going to apply a trick over it. He's going to concat these four observables. Let's get the observable of Slytherin observer of Hufflepuff, Ravenclaw and Gryffindor and apply the concat spell over it. Draco applies the concat spell over it and this is how what we'll get then. As you can see we use the Slytherin observable first. So Slytherin is getting emitted first then Hufflepuff then Ravenclaw and Gryffindor is the last. So guess who is not so pleased who was the first one to submit the assignment and now she's lost. Yes Hermione is not so pleased by this so she wants to make the thing she wants to make the things right. Now she's going to use the merged spell instead on the assignment evaluator and this is what is going to happen as in when the students will turn in the assignments everything is going to be in order G1, S1, H1 as in when the items is getting emitted we are combining and merging those items. Let's look at a coding problem first now. This is a classic problem what we want to do is we want to hit the cache first to get the data and if the data is found we'll return the data and as we want to place a network call. So what we can do is we can apply the concat spell easily on this problem. So here what we have is we'll get the lectures. Lectures is anything that we're searching from the server or getting from the cache. So we'll first get the lectures from cache we have in observable get the lectures from server we have another observable and we can combine or concat these two and what will happen is if the lectures are found in the cache we'll not be subscribing that is we'll not be making any api calls and if you were to do this without Ariesha you'd have to do some little of conditional things and Ariesha just lets you use a single operator and maybe a two maybe two operators and get this over with. So yeah I have used another operator in this example that is take one. So one caveat here is when there is no data for example if there is no data from cache or from server then take one will complete without exception and otherwise if we had used first then we would have got no such element exception if there is no data so that's why I've used take one over so next topic is the back pressure that is the defense against the dark art let's have a look at it so what is back pressure the term which many people use and did not really know about back pressure is frequency when the frequency of reducer producing an item is more than the ability of consumer to consume technically strategies for coping with observable that produces items more accurately than the observer consuming them. Good news is usually you do not even have to worry about back pressure in your applications. Ariesha ever to introduce is flowable which is an observable with back pressure support what you just need to do is forget about flowable and use observable instead and you do not have to worry about it at all. Observables do not support black pressure whereas flowables do it's totally good to know about things because if in future if you might have to like take care of back pressure then you should be knowing about it and how we should be dealing with the different strategies to deal with back pressure. So let's have a look at another fictional problem that is the back pressure. We have two armies one is the good army that is the Dumbledore's army and another one is the death heaters that is the bad army. Each team is fighting against the other team and Dumbledore's army is not as experienced as the death heaters. So the death eaters are emitting some spells and the Dumbledore's army that is a good one they're getting overwhelmed by those spells. So some kind of back pressure handling here is required because the frequency of producer is more than the ability of the consumer to consume. So let's take a look at some of the operators which can be used in this case or the strategies even if we do not have to worry about back pressure but still these operators as you see can come in handy in fusion. So first is the buffer operator. So what buffer does is as the name suggests it buffers small chunk of data and emits instead of emitting one item at a time it emits buffer I mean chunks of data. So technically periodically gather items emitted by an observable into bundles and emit these bundles rather than emitting the items one at a time. So this is a simple example this is an observable of spell which the bad army is producing and here they are a first spell, second spell, third spell and fourth spell. What we can do is we can apply the buff random spell over here that is as simple as buffer and the count and here these two spells will get buffered and this will also get buffered. So as I told you the Dumbledore's army was getting overwhelmed so they had decided to use this technique or this kind of strategy to cope with the back pressure in that case but as you can see they still have to like process all these spells so it is kind of a lossless kind of a strategy because they still have to process all the items so it's not going to work. So Sirius is not so happy about the strategy so what he's going to do is he's going to instead apply the debound strategy that is the debound C spell debounds operator. So what is debounds operator? Debounds operator from a list of items emitted emit an item only when some time has passed since it last emitted anything. Only technically only emit an item from an observable if a particular time span has passed without it emitting another item. Let's see how it works so here the previous marble diagram of a spell four spells so here we have this is how we can apply the debounds operator we'll take a time unit that is a 300 milliseconds and how this comes into picture is since there are three merely seconds had passed since something was emitted so one gets emitted again 300 milliseconds had passed since anything got emitted so two gets emitted. Now three milliseconds had not passed and four got emitted so it will skip the third one and it will instead emit four because again 300 milliseconds had passed without it emitting anything. So as you can see this is a lossy kind of approach and it works out well in this case and the Dumbledore's army is happy now problem solved. So let's apply these strategies in some applications which are not really related to back pressure but you do not have to like think about back pressure in these cases but these are kind of optimizations which you might want to do in your app. For example if you want to optimize network traffic the use case here is you want to track user events whenever a person like user clicked here, user clicked there with each and every event you want to send a server call. Simple approach of doing this will be server request whenever any event is occurring. So what will happen here is we'll have an overcharty producer that that is a user events and the slow consumer that is a network. So some kind of back pressure handling is required over here even if you do not think about back pressure you would still have to optimize this case. What we can do is we can use the random spell or the buffer operator over here. We can buffer some events before making a network request but you would have to see if you're tracking analytics API supports that kind of an operation and it can send a chunk of events instead of sending one event at a time. It can send a list of events. So this is how we're going to do it. We're going to get an event so observable. We're going to buffer three events at a time and we're going to send a list instead of one item at a time. So we won't be putting much load on the API or the server. So the next problem is the autosurge problem. This is the problem when we need to show some kind of autocomplete suggestions. So as you can see in this thing is whenever a person is typing any character we're placing a network call at each and every character. So this is not so optimized. This is a simple approach of doing things. Whenever any character is getting typed place a network request, get the results and show it as a like autocomplete list. So what we can do instead is we can handle back pressure over here and use the debounce C-spell or the debounce operator over here. How we can do that is we can place the time limit as 500 or whatever you want in milliseconds over here and only after 500 milliseconds had have passed then only the next character will be placing a server call. So this is as simple as writing a simple operator debounce and doing it. We do not have to really implement it ourselves. So the next topic is error handling or the model art. So we have repeatium spell over here, the repeat operator. What repeat is, as the name suggests, emit the same item multiple times, create an observable that emits a particular item multiple times. This is a simple example. We have an observable emitting one. We want to repeat this four times. We'll emit one, one, one, one. This is as simple as using, this is, we don't only have to use a single function and will be good. So next is the retrickle spell or the retry operator. That is also some kind of task which takes some time out of and some of our, we eat our brains doing synchronization and everything like that. What we can do is, so on error we can retry the same task until it's successfully completed. So if a source observer emits an error, then we'll resubscribe to it in hopes that it will complete without error. So this is a marble diagram. What's happening over here is we have a source which is emitting one, two, and three. What happened is when three was getting emitted, we got an error. So what we can do here is, we can apply the retrickle spell and resubscribe to this. So it will simply retry and this time the stream got completed successfully. The basic difference between these two repeat and retry is the repeat operator will resubscribe when it receives uncompleted because we are repeating something which had been successfully emitted and retry resubscribes when it receives on error. So let's look at a fictional problem that is called the Professor Lupin's Bogard. What it is about is we want to perform a ridiculous charm, which is any operation. What we want to do is we want to perform it successfully, then we want to excel at it. So a ridiculous charm, what is a ridiculous charm? It is a magical spell to turn a Bogard which is your worst fear. We want to turn it into something funny. So the Bogard, the fictional or magical object, it has three states that are scary, funny, and hilarious. So we are emitting these Bogard states. We will call this ridiculous charm operation to have been successfully completed if the laughter threshold crosses the funny threshold. There is a funny threshold is a value. If our threshold crosses this value, the spell is successful. And we would have excelled the ridiculous charm if the threshold crosses the hilarious value. Something is funny when it makes you laugh, but something becomes hilarious when it is extremely funny. So to state the problem Bogard has three states, scary, funny, and hilarious. We want to perform a ridiculous charm on Bogard. The state of Bogard will remain same. If it does not cross funny threshold, it will change into funny. If it crosses this funny threshold, it will change into hilarious. If it crosses the hilarious threshold. So we need to retry until the Bogard state is at least funny. Then we need to repeat this task until Bogard becomes hilarious. So let us look at the marble diagram. This is the solution like firstly the scary state emitted and then we applied the ridiculous charm or any function over it and it failed. So what we can do is we can retry over here, resubscribe to it. And this time we were able to perform the ridiculous charm successfully. The Bogard state changed into funny. And the operation got completed successfully. Now we want to repeat this thing as the operation has been successful. Now we want to excel at it. And fortunately this time the Bogard got converted into hilarious and our operation is successfully completed. This is the code for it. We will get the Bogard observable. We will apply our any function. In this case we are applying a ridiculous function over it. If the Bogard is funny, we are emitting the Bogard. Otherwise we are emitting the error. And if the Bogard is not funny, this will result into an error case. And whenever any on error is triggered, retry comes into picture. So now what will happen is retry. This will get retried. And this whole thing if it gets successfully completed, we will repeat it 10 times. And I have used another operator over here take until. So this thing will be repeated until our operation the Bogard gets hilarious. Enough about retry and repeat and this fictional problems. Let us take a coding problem into picture. So the problem is we want to keep the session alive while the user is browsing the app. So how we can do a simple approach would be checking for session validity before performing each and every API call. You would need to place if and if checks before placing any API call. So the drop back is as I told you placing the session dot is valid check before each API call. What you can do instead is renew the token repeatedly while the user is browsing the app. And that can be done using our repeat operator. So we will apply the Repetarium spell over here. We will get the session observable that is we will get the current session and we will check if it is valid. This can be done using the filter operator I told you about. So we have one observable which is checking the validity of session. We have another renew observable which is making the API call if our if our expiry time of the session has occurred. If the if the session has expired it is making the API call. So here we are using the repeat when operator which takes in a function and we can tell it when to retry. So what we are going to do is now we have two observables we can simply concat it. So if the session will be found in the cache it will return the session and if it is valid. And otherwise it will just keep on retrying in the background sorry repeating in the background and it will keep the session alive. So next let's take a look at the demo. We have multiple API calls the problem I talked about earlier is let's convert it into a coding problem. We are waiting for the flux feed API call to complete. We are also waiting for the student API call to get the hair of crab. Crab hair it is a like member variable of students last. Both calls are executing asynchronously. The problem is we want to initialize polyjuice that is we want from the results of API calls that is flux feed and student want to create another object called polyjuice and we want to hide loader only after both calls have completed. Without RxJava we would have to use CMA4 like if flux feed call would complete we would have to check if student call had come has been completed or not. And if the student response came first then we would have to check if flux feed response has yet come or not. And that way we would have to keep two bullions, two states that is like states are not that good. So let's take a look at the example. This is a simple demo that I created sorry for not using material design that much. We got crab hair, we got flux feed and we prepared the polyjuice as you can see let's see it again. This time we got flux feed first, now we got crab hair and we prepared the polyjuice. So these kind of things are really simplified by using our RxJava code which I have written. We are simply using the zip operator. We are getting the two observables and we are using zip operator on it to complete our task. And so we are not saving any bullions or anything. The code is clean and we are happy. This is the problem that we just saw. So what's next after this? I would suggest you guys should learn by practice, make RxJava your friend and not a foe because it has a lot of advantages, a lot of places and it makes things less error prone and makes your life easier. There is a repository from Kaushik Gopal that has a lot of examples, RxJava Android Example. This is from where I got the motivation to start working on RxJava because it had many examples which shows that there are so many things that RxJava can achieve. And also if you want to have a look at RxJava 2 there is another repository, sorry I messed up the link. It is from Amit Shekhar and it has examples on RxJava 2. Also if you want to pull your hair out, take a look at my source code of my demo app because and also you can go to the medium blocks for more detail. I'd like to give some acknowledgments. Vikas for pushing me into RxJava because at first it was really overwhelming. Julian for suggesting me to think about this topic, Ritesh for editing all my stuff and the DroidCon team for bearing me with the rehearsals. Also I'll state the links over here, lossy and lossy. Repeat and retry. This has been taken from a very good blog from Dan Liu which has repeat when and retry when, difference between those two. And these are some other definitions and the fragmented broadcast is really good. Just have been taken from here and thank you. Now, new question. Is there a way to test it? Yeah, just I mentioned about test scheduler. So what we can do is using the test scheduler. Otherwise we have the main thread, main scheduler. We have the computation thread and IO thread that are the background threads. We can do is we can instead use our structure, our apps in a manner that use test scheduler instead of those two schedulers. And what can we can happen is we can like call trigger events function on it and it will trigger and it helps us write a unit. So the problem that I was having is that I subscribe on a different thread and I listen back on the main thread. And in my unit test, I do. I don't have the access to the Android, right? Yeah, that is what so you can use test scheduler for that. How to handle the duplication of data in different streams? Like is there any operator already developed or we have to manage the duplication of data? What do you mean by duplication of data? You discussed the problem like using caching and using data from server API calls. Say if I have data in cache, say 10 records, I am displaying those records in a list. And in another stream, from another stream, I am getting data from API. So in that API hit, I get updated data, say 10 plus 2 records. So now that stream is returning 12 records and cache has 10 records. So if I can get in it on merge, like in the example you displayed, so that concatenate or merge would return the combined data of both streams. So that would be the duplication of data, 10 plus 12 now. So how would you handle that data? Didn't get the problem. There are methods in RxJava like you said about retry and these are the methods there. But there is also a method unique. If you use observable.unique and you pass those models, that observable model that contains duplicate data, it will filter out and give you a new model with unique data there. So there is a method in RxJava too. So you can use that. Yeah, it will compare all those two earlier models which you provide that or the list of the data which you provide it will check which are the data which is repeating. No, no, no. That unique operator is there like observable.unique. There is one operator. I'm not sure like it is unique or something. Hi, Garima. You said about autosurge via debounce. And in autosurge, like when I started typing a word apple, okay, first I typed A then P. Response for A came after two seconds and but the response for P came within a second. This might happen due to my speed of server or the internet. So my question is here like, is it handled properly? Like if A response is coming after the P, so will it be displayed in the UI or will that be? So you need to take care of that. Maybe in that case we can use the contact map instead of the flat map and contact map takes care of order. So that might work out for you. Okay, so like it is not handled with Rx properly. You would have to use another operator or any other kind of technique. Okay, we'll run the code and we'll see like what the result is. We'll run the code and we'll see like what the code, how it works in real examples. Okay, thank you. Hey Garip ma, question here from Balkan. All right, the question is here, here on the Balkan look up. Okay, the question is, let's say I have a lot of multiple upstreams and downstreams, right? So in between the streams, if some crashes happen or some error happens, so it fails down in my ultimate downstream and say, hey, so how do we debug that? What all tools you are used to debug the problem like this? So basically what I'm asking you is what all the problems you are faced using Rx and how did you solve that? One of the good practice to be able to debug this kind of thing is do not forget your onerror and recently I was reading about a tool which can be helpful. I do not, sorry, I do not remember the name, but yeah, if you properly declare your onerror method and also Dan Liu suggests that if he throws an exception like onerror not implemented exception, if your onerror is implemented correctly, you'll be able to debug it. We are not using any of the tools that onerror is our, I mean, I would say. Yeah, onerror is fine. But the question is, let's say I have multiple upstreams, right? Like five upstreams I have, right? Which stream did it crash? I wouldn't be knowing in onerror. Onerror will be generated. Yeah, sorry. Yeah, in onerror, you'll get to know that particular line. This is the particular line on which you are crashed. So you know this line is from that observable. You have different streams. You have different observables. So you'll get to know. Hi, I guess Google has recently released a similar library named Aghera similar to Rx. Have you tried that? Sorry. Google has recently. Aghera, what about it? Similar to, it's similar to Rx, right? Are you trying that? I haven't tried it. I've just heard about it in one of the podcasts and don't know what you want to ask about it. Okay, thanks. It's like some similar thing than in some other manner. Yeah, is there any API limitations for Rx Java? API limitation hasn't. Is in backward compatibility? Oh, okay. That thing API, as it is different library, I do not think there is much. I do not remember the exact number. Hi, so my question is, is Rx Java faster than writing the code in Android or the same level? It would depend upon what kind of operators you're writing. If you're using a lot of operators, I think it's not going to be that good. And it's definitely cleaner code and faster would be dependent on your implementation. So is it directly interacts with the JVM or it is a layer over the Java? Rx Java is a layer over Java or it directly interacts with JVM and compiler? Okay, thank you. Thank you, Karma.