 So hi, I am Manas Saudhary. I will be speaking on functional MVVM using RxJava and data binding. So this talk is about building user interfaces. And there are lots of patterns on the web that people recommend that use MVP or things. So I have been exploring MVVM recently by using RxJava and data binding both. And it has been working really well. And I would like to share how this happens. So what's the issue with user interfaces? So as Anup also mentioned in his talk, there's a lot of changing state. And so for example, we have data coming in from server or maybe there's some interaction based on which your user interface changes. So many of, so I have at least heard this a lot of times that web apps get developed very faster than Android apps. So I'm sure that pretty much everyone of you must have heard this. So well, so I think that since web technology has been around since quite longer than Android, the tools have matured to deal with these states. For example, there are frameworks like Angular which help you a lot. And I believe that with these RxJava and data binding on the Android also we can increase our speed of development a lot. So let's take a simple example. So I have a login page in which I have two inputs, email and phone number. And I have a button. So I need validations as the user types. So I need to validate my email and phone number and my button needs to enable it only if both of them are valid. So if everything was static, so if nothing was changing, you were to just simply render a page and wait for the submission and then check the errors. So this is how the code would look like. You would just get the inputs from the user. You will check their validity and then you'll see calculate the errors. What's the error? So like this code is very straightforward. It's clearly it's exactly what we want to do and it's easy to understand. So but then our code is not so simple. So because the dynamic changing state starts to come in. So the first thing is that we need listeners. So the text is not constant. You cannot just get it once and be done with it. It keeps changing. So the first thing you will do is add listeners. So what was that single line change to this bunch of code in this? I am invoking the check email function whenever my text changes. So my further calculations can be done in this function. So here I am checking the validity of my email and then updating the error accordingly. And then I'll have to do the same thing for phone number also. Now login enabled depends on both email and phone number. So I had to since the both the check functions were invoked independently. They did not have any awareness about whether phone has. For example, the check email function had nothing to do with phone. So I'll have to refresh the login enabled in both these check functions. So what has happened here is by doing this refresh, we have started a chain of refreshes. So for instance, if there was some another property that was dependent on let's say the login enabled value, then you'll have to refresh it here inside this refresh function. So as your form expands, you will end up refreshing a lot of things when something changes. And then eventually you'd probably give up and create a single refresh function that does everything. So and the root cause of this is mutation. So because our login enabled state depends on phone valid and because the phone valid variable can change, hence we need whenever we change anything, we need to think that, okay, I am changing this. Now what else depends on this? I also need to refresh that. So that and that is a very common source of errors that you change something and then you forget to update something else and then later while it crashes and then you realize, oh, I forgot to invoke that. So the first problem is mutation as we discussed. The second issue that I find with this code is this changing capturing input that is capturing this change is such a common phenomena in our apps that this 10, 15 lines of code is not justified. So I need a very concise way to deal with this change. So let's look at how the solution is going to look. So I'm going to capture all my logic inside a class. I'm naming it login state. It has it clearly specifies my inputs and outputs. So I have two inputs here, email, phone, which are of type string and three outputs, email error, phone error and my state of my login button. Now this login state class will also have logic which connects these inputs to outputs. Now this code will look scary, I guess. So focus on these parts. So these are basically transformations from inputs to outputs. So we start with email and phone and we derive the values of email error, phone error and login input. Now earlier we looked at the static code in which everything was simple. Now if you look at the side by side, you will note that there is a exact one-to-one mapping between these two codes. So basically by using, by following this pattern, the code that you will write is as if everything is static. So there is no hassle of listeners and that is, and other things. But then they are there. It's just that you don't have to take that effort to write listeners. They are happening internally. So that's the beauty of this. And then we have, so I showed you how the login state looks. Now here's how my XML layout will look. So I have introduced a variable, this and then in the XML itself I'll link these inputs and outputs to my views. So we'll go into it later. And my activity will simply initialize the login state and link it to the XML. So there is no need to find my child view by ID or set up any listeners. Everything is done in the background. So let's look at how this works. So the first part is mutation. So normally when we see any code. So here is a simple code and assigning starting with a equals one. Then I'm changing seed equals 10 times a and an updating a and then I'm printing C. So by default, this value of C will be 10 in all our common languages. So that is because when you say C equals 10 times a, that means that when this program is executed at the point that this statement is executed, C means 10 times a. After that, if a changes, then it has nothing to do with C. So there's another word. I'll call it reactive word. So in the active code, if you write these same statements, the output of C would be 30. So that is because when in this world, when you say C equals 10 times a, that means C equals 10 times a forever. So whenever a changes, C also changes automatically without you having to explicitly set up any listeners and those things. So and basically this kind of solves our refresh chain problem because now we don't need to think about refreshing C. We just change a and based on the definition of C, it will get updated automatically. So now we want this behavior in Java, but Java does not have this behavior. So then here this is where Rx Java comes in. So Rx Java is a library through which you can get this reactive behavior. So Rx Java provides an observable class which you can think of as a stream of values. So different values are occurring at different points of time and it provides operators for manipulating these streams of values. So let's take an example. So this is an example of a stream. It has three values, one, two, three. So I want to do some manipulation with this. So to manipulate, I'll need operators and one example is a map operator. So what map operator does is it takes each value from the input stream and applies a function that you provide and creates a value in the output stream. So in this case, the function is 10 times X. So every value in my output is 10 times the input value. So let's see another example. This is a diagram of combined latest operator. So combined latest has multiple inputs. So you can see two lines at the top and a single line at the bottom. And what it does is it combines the latest value from each of the inputs into a single value in the output based on a function that you provide. So here the function is what this function is doing is it's concatenating the two inputs. So whenever either of the two inputs changes, we have a new value in the output which concatenates the latest value. So for example, when the upper value changes from one to two, we know that the previous last value of the second input is A. So A is combined with two and we get two A there. So there are a lot of operators. So Garima told showed us a lot of operators, but these two are enough for our use case. So let's see how we can build the login example with Rx Java. So again, I have these inputs. Now whatever was string, whatever was Boolean that was changing, everything becomes an observable now. And then we can start writing these transformations. So from email, I want to calculate if it's valid or not. So I can use the map operator and in that to that map operator, I'll pass a function which is basically checking if that email is valid or not. So now I can use lambda syntax here to make this concise. So then this is what I will end up with. Similarly, I'll do the same for the phone. I'll check whether my phone is valid or not. Then again, I can go ahead and calculate my errors from my validities. And lastly, since my login enabled state is dependent on both the two validities, I can use the combined latest to determine whether my login is enabled or login should be enabled or not. So now it's time to connect these to the views. So in the previous slide, we looked at transformations from input to output, but we never saw where those inputs are coming from or where those outputs are going into. So for the inputs, these should be derived from our views. So the data is flowing from our views to observables. In case of outputs, the data is flowing from observables to views. So for the flow of view to observable, there is a library by Jake Wharton called RxBinding. So what it provides is it provides you helper methods for creating observables for all possible properties of all possible views. So for instance, here I need an observable for the text property of an edit text. So I have a helper method RxTextView.TextChanges and to it I pass my email edit text and I get an observable of string that represents my text of my email edit text. So I won't go deep into this, but you can check out the source code to know how this is actually being created. So for the reverse scenario, in order to access any value inside an observable, you need to subscribe to it. So subscribing is like adding the callback. So since observable is changing at all times, there is no single value that you can get. So it has to be in the form of callback. So whenever something is changing, you get an update. So when you subscribe to it, you need to pass an callback and RxBinding again comes here and provides you helper methods for these callbacks. So here I need to update the enabled state of my button. So RxBinding provides me an RxView.Enabled convenient method. So that whenever that value inside observable changes, my enabled attribute of the button will get updated. Now these subscribe methods return an observable. So when you're using RxJava, it's your responsibility to clean up these subscriptions, otherwise it will result in memory leaks. So basically in the process of removing boilerplate, we have added this new kind of boilerplate that comes with RxJava. And data binding help us get rid of this also. So how many of you guys have used data binding? So data binding allows you to include variables inside your XML and then you can use those variables to assign attributes inside your views. So for instance here, the XML shows that there is an enabled attribute which is linked to the login enabled field of my state. And the type of login enabled is observable field. Observable field is a class provided by data binding, so don't get confused between this and the RxJava's observable. And now what happens is whenever you update the value inside your login enabled observable field, data binding takes care of updating the view for you. So you don't need to think about whether my view is getting refreshed or not. You can simply update the field and your view attribute will get updated. And same for the reverse scenario. So whenever my user types in my edit text, my observable field will get updated. So I can add listeners on my observable field to know when the user is typing. I don't need to work with the views. I just need to work with the field. And how this is happening is behind the scenes data binding generates code. So to do this listener to set up these listeners for you. So for activity login XML, it will create a class named activity login binding. And since my XML declares a variable named state, it has a corresponding setter set state which I can use to populate that variable. So this set state method will internally kind of set up the listeners to get your observable field and view attributes in sync. And then in order to set up my view, I need to create an instance of this binding and creating an instance is very similar to how we inflate a view. So whatever helper, whatever methods view has to, for example, inflate or set content view, data binding provides similar utility methods to create, which return an instance of binding instead of a view. And then this binding object has these setters that we discussed, which you can use to pass in the state objects. So we have looked at our data binding, which has allowed us to connect observable field to attributes of our view. And the code to set up the listeners was auto generated in this case. Now earlier we looked at RxObservable and RxBinding to link these same components. But we had to write the subscription code and then there was the boilerplate to clean up these subscriptions also. So now ideally it would have been really great if I could simply refer to an RxJava's observable inside my XML directly. I don't need, instead of working with fields, if I could work with observable, I would have all the benefits of RxJava plus data binding. But data binding hasn't provided any APIs to work with custom fields. So it expects that whatever you are referring in your XML that has to be of type observable field. So then what we can do is we can convert an observable to an observable field and vice versa. And this conversion is possible because both of these components are basically similar. They have some value inside them, which is changing and they provide APIs for listening to them. And when we use this converter, then the RxBinding layer goes away. Whenever we want our data to flow from an observable to view, we will convert it to an observable field. And then we can use the data binding in the XML to connect it to the view. And for the reverse flow data binding will provide us an observable field and then we can convert it to an observable. So let's say we have this converter APIs. So again this source code is available on GitHub. I will be sharing the link soon. So there are two methods to observable and to field. The first method converts a field to an observable and the other one does it in the reverse way. So I have this login-enabled observable which I want to connect to this enabled attribute of my button. But then as I said data binding expects that login-enabled has to be of type observable field. So I can use the two field converter here. So then data binding is happy now that the login-enabled type is observable field and this works. So what's happening is data binding is adding a listener to my observable field whenever it sets up the view. And that observable field is internally subscribing to the observable. That's the source observable that is the one on the top. And similarly when data binding cleans up it removes the listener. At that time the observable field will also unsubscribe from the upper observable. So that way you don't need to think of work with subscriptions. That is directly integrated into the life cycle. For the other scenario your data binding will update my email observable field whenever user types on the edit text. So in order to use these RxJava operators I want to convert this into an observable. So I can use the two observable method and I get an observable which I can then use to... Then I can use the map combined literature and all the possible operators to work to further calculate. So to summarize we removed the find view of ID and other listeners boilerplate by using data binding. Then because we wanted to solve the mutability issue and the refresh chain issue we added converters between observable field and observable. So this has enabled us to use RxJava operators to convert between two observable fields. And as a bonus there is no subscriptions here. Everything is cleaned up in the conversion layer itself. So the code is memory leak free by default. And the pattern till now is that we have a state class that has all the presentation logic. Then we set up all my view inside the XML itself using this state instance. And the activity is very minimal it just initialize both of these and connects them. Now the talk says MVVM right? So you must be thinking where is MVVM? So this is MVVM actually. So let's go into what it is. So MVVM stands for model view view model. There are three parts. So model stands for business logic. So if you think of it as the logic that will remain same even if you are building a console app for your business. The view model has two responsibilities. The first one is maintaining the state of the view. So if anything can change on my view there has to be a corresponding data field to store on my view model. So for example whenever if my button can be enabled or disabled I'll have to keep a Boolean field on my view model to remember it. The second part is presentation logic. So when my button should be enabled that is also a part of the logic and that also belongs to the view model. So my button should be disabled when email is invalid that is an example of a presentation logic. The view simply observes for changes in the view model and whenever it gets a notification that something has changed it updates it. And the second part is that whenever user interacts with the view it informs the view model that okay something has happened. And the dependencies between these components are in this way. So the view has a reference to the view model. The view model has a reference to the model. And this implies that the model is unaware about the view model and the view model is unaware about the view. And because the view model is unaware about the view multiple views are free to use a single view model. So this is what allows you to reuse your presentation logic for multiple views. So like if you had let's say you want to display some item in an e-commerce app and you had two kinds of views. You have a small compact view and you have a big view. But the logic is same when something is unavailable you had to feed it something like that. So then you can reuse the same view model and create two XMLs which refer to that same instance of view model. So that way your presentation logic gets reused. So the login state that we looked at earlier is actually a view model. Now let's look at how this enables us to compose different views. So till now in the login example we have looked at building a single view. So now the second part is about how we can link smaller views into a bigger view. Because that is necessary for reusing. So I have an example here in which there are two pages item listing and item checkout. The listing pages shows a page shows a list of items. There are some details for every item. On the checkout page I am repeating the same details perhaps in a different layout. And there is another component for customizing that item. So now I would want to reuse the code between the two details components. So I can plug in my same view model at both the place. So let's look at the checkout page first. Since it has two components I will have a similar hierarchy in my view model. So my checkout view model contains detail view model and customization view model. And there will be a similar structure in the XML also. So my checkout page XML will include the item details XML and the customization XML. And because both these XMLs expect view models I can use the data bindings feature of passing in variables. So by doing this I am basically linking the child view model of my parent of my item checkout view model to the child layout. And why is this possible because MVVM makes you follow some rules. And because of those rules you have a consistent way to set up any view. So to set up any view you just need a layout ID and you need a view model which is compatible with that layout. So given these two things I can set up any view. I don't need anything else. So now let's and this this feature of MVVM also allows you to create very generic adapters. For example, recycler view which will soon look at. So to display a list of items I need a list of view models and I need a layout ID for my individual for each child. And as I said if I have a view model and if I have a layout ID that's enough for me to set up a view. So then this allows me to specify set up a recycler view using these two arguments. So I have this I have the list of items and the item layout. So now this these two attributes are not available by default. These are custom attributes which data binding allows you to provide. So you can create your own custom attributes as per your application. And to define how these custom attributes get updated on the view you need to write an adapter. So basically this adapter that I have written that takes these two inputs and creates an adapter. A recycler view adapter and sets it on the recycler view. So basically I have set up a recycler view in XML itself. And that is what the pattern is about because when you write an adapter it's available in all the pages of your app. So you need to write it only once. So whenever you have any complex view you just write adapter once and then you can do the rest of the setup in XML itself. And as because there is no Java code you're just writing XMLs and you're writing new models. And the activities which are kind of the root they are just initializing the root parts. And everything is linked through includes and through recycler view or other containers. And then obviously I can write same adapters for view pages also. So that way I have a consistent API to configure any kind of view. So there are some catches in working with this pattern. So one is the dependency part. So when we looked at the login example we never discussed what happens when someone clicks on login. So when you click on login you'll probably have to invoke some API network call or navigate to a different page. And navigation requires a context. But context belongs to a view and view model is not allowed to have a reference to a to a view by principle. So to do this what we can do is abstract everything into an interface. So navigation is kind of some action but I want to abstract it into a navigator interface which has a method for opening details page for any item. And then in my view model I can pass in the navigator instance and then my view model knows the trigger to invoke the navigation which user interaction will actually invoke the navigation that is the presentation logic and that belongs to the view model. But it does not know how exactly the navigation should be invoked which is the correct way. So basically if you see this view model is plain Java there is no reference to Android related components. And if you had to write this view model for iOS or some other platform it will probably look exactly the same. So that actually helps us in testability. So view model has all the input and output fields clearly so you can invoke any action easily. Then because all anything that changes is captured in the view model you can assert your test state. And then because this is independent of Android it does not have any dependency on Android classes. Everything every test becomes an unit test instead of instrumentation test because of this your tests will run lot faster than otherwise. So this is an example of a unit test. So I want to check if the detailed page is opened on click. So I'll initialize an item. I'll initialize a fake navigator. So I have chosen to use a mocking framework but I can easily create an anonymous class here because everything is an interface. So then I'll initialize the view model. I'm invoking the call function for my item click action and then I'm verifying that my detail page is getting called. So because you can see that because view model clearly has all these inputs and outputs it's this is very clear. I don't need to refer to any view IDs or anything in order to write a test. And that concludes my talk. So there are two points that I would like to make. So by using RX Java and data binding we have cleaned up a lot of boilerplate and the building of you we have kind of there is an analogy between this and function. So we have all we wrote on the in the view model was transformations from input to output. So that's a different perspective to think about a view. When you're building UI you are basically writing transformations from input to output. And that there is and that even with this clean approach there is no it also removes boilerplate. Then we looked at MVVM which allows us to connect multiple views into a bigger view. So this is analogous to composition in functional programming. So MVVM is kind of allowing you to write higher order views which is similar to higher order functions. So yeah, so that's it. And so I have created a library which has the tools mentioned here and feel free to contribute. So you talked about like binding between the UI and the like the code, right? Basically in abstracting it into a model view, right? But what about database and the view or like, you know, network calls and the view. So is there a way we can database and the view can also be interchangeably, you know, if there is a change in the database we can directly change the view. How can how do we do that using this? Yeah, so the linking works seamlessly with observable as I discussed. So if you can find an adapt if you can get any data in terms of an observable then it will get updated on the view whenever that value changes. So for example, the retrofit if you use retrofit it will give you your API response in the form of an observable. So you can directly link it to your view. So whenever the network request completes, your view will get updated automatically. In case of database, I have not looked at ways, but I think SQL Bright is a library which might give you observables. So you can look into that. Then the your again the link gets set up. Yeah, so this is another thing that I need to evaluate. I have not done any benchmarking on this, but I have used this in production and I have not found any critical issues. Any more questions? Thanks.