 My name is Denis, I've come to Singapore from Russia, from cold-freezing Moscow, just about one month ago. And this is actually my first presentation in Singapore. I'm really glad that you've come here. Please raise your hands. Who already developed something for Android? Okay, cool. But who I want to become a developer? Okay, that's great. Maybe for others it will be a little bit boring because we talk about code, we talk about how to build Android apps well. And if you develop for Android or any other systems, there are a lot of talks about architecture and one of them is which architecture should I prefer. And for last year's because Android applications get much more bigger and it needs to support by many developers in one team, it becomes not so easy to support it, so why people care about architecture more. And there are several reasons why people care about it. First of all, the people want to separate logic and view because we don't want to tide your logic of the app, your business logic, your getting data from the web, your caching logic from your view layer that shows the data to user. Also, you don't want to care about async operation, sometimes it's really harder and if you develop for Android, you know the problem that all your network calls should run on background thread, but UI updating should show on view on UI thread, that's the problem. Also, you need a handful error check and also you need a state return and you know if you rotate the device, the activity, the main architecture point of Android recreating, destroyed and creating from the scratch and lose all data that already shown and already loaded for the screen. So, you need some place where you store data when it rotating and restore it after rotate. Also, you want easier effector because you want to change some part of your app, some, for example, HTTP client logic or logic how to load image or any other part of your app without rewriting the whole code in every place. Also, last but not least, the testability. You want testable code and you know the problem in Android that it's not so easy and it's not so fast to test the code that's related to Android context and other classes that comes from Android framework, not from pure Java framework. So, testability is the main reason why we separate Android related code from code that tied to Java APIs. Right from the Android release, the MVC pattern becomes for all of us and we start using it. We place all logic, data loading and we care about how to show it, how to handle it in activity or fragment or service and it called controller because we start thinking that this class is controller and the view is just XML and model somewhere else like on web server. After that, people start thinking how to test it and test all logic in activity is not so easy. So, it's better to move to presenter class. All the logic that's related to business logic to how to get data, how to parse data, how to convert. And now view the activity class and fragment class get more lighter and it's much more easy to test the presenter and model because it only pure Java, no any Android related stuff. But now, right after data binding library by Google becomes released, it gets much more easy to create the app without no worrying about how it will be showed and write less code than you do it than you did it before using MVP or MVC architecture. So, how it looks like? The first brick, the first building block is the view. And now in view we have the link between the view and the model and that's great because now we don't need to write fine view by ID in your activity or your view class or your fragment and find the view and call view, set text or view, set image. That's pain. You don't need to do it. You just need to set, hey, I got a user model and I want the first name will be set to text field just in XML and no any fine view by IDs. That's the main cornerstone of MVVM architecture and the user class here, it is the MVVM architecture, it's a view model class. So, it's cloud that store our current state of the screen. All that we show on the screen is stored in fields of this model. So, it called view model because it's the bridge between view and model. We can have in our model class some data but we can wrap it by any other classes as we want and show it in view model like this. So, what we see here, we have a class user and the observable field string. What mean observable field? Observable field is the class from data binding and it provide the automatically updating logic if we call first name set and provide some text. This text will be updated in our view automatically and don't need to care about updating no more. Just update this state class called view model and the model class. This class and it's not a class actually, it's a whole layer. This layer is actually a repository. It's a famous pattern in development. So, here all logic how to fetch the data from the web or from the cache, how to parse it, how to convert it and make some other modifications. And here's the overview. So, we have a view. View start observing changes of view model fields. After that, view model know the heavy link to model and ask it for fresh data. After that model send the fresh data to view model. And as view model updated, the view will be updated simultaneously, automatically we don't need to care about. That's the great. And also, the view model is actually the state that we need to serialize when we rotate our device. So, when we rotate the device, the view model will be serialized and we put it in a save instance state. And when we restore the state, we just restore this radius of these fields and it automatically tied to view and updated the new created activity or fragment with the data from previous state that was destroyed on rotation. Okay. So, how looks like the whole layout? For example, on this screen you see the tabs with the search bar and the list of some features from the web data for this search result. This is actually the topics from Reddit. The sample available on GitHub. On the last slide you'll see the image, the core code and the link where you can see the sample code. Okay. So, it's a bit confusing too many lines. Let's start from the header, from the top. The header a little bit different than previous we do on Android when we create Android layouts. Now, we have a layout root attribute, not the linear layout, not the relative or frame. No, just layout and here we pass the main building block data. Here's the bridge between our view model and this view. So, we provide the name of the view model and where it's stored in our code base. And after that, down of the data text, we have some views, some layouts. And for example, we can use not only Android framework classes, we can write ourselves from here. You can see here the search view. Search view not by Android or support library but search view from some third part library. And here is the some fields. For example, the second field on subreddit click. What's happening? The framework of the data binding framework bind click listener automatically to view if there is the setter. For example, if our view, this search view, have a method called set on subreddit click. And as parameter, it want to be passed on subreddit click listener. And if we provide on subreddit click listener that's stored in our view model, it will be automatically set it if we provide this binding string. Really easy. And the same for on search query change. We provide listener for on search query change and it will be called. And the model, the list of our data that will be set to listed data and showed in the search view. It's field called subreddits and we provide our own logic for subreddits. We call the adapter setter subreddits. I'll show you how to do it in the next couple slides. But let's get back how to build bridge between view model and this view. All we need in our activity no write the long, long, long list how to read in activity code. All we need just to write three lines. First unit in your activity call data binding util set content view and provide link to context. Here is the activity context and the link to layout that we just show. And the second line all you do is create new instance of view model. Or if you restore it from the previous save state, you restore it and get the link to it. And on the third line you call binding set view model. And now here is the link between view model and our layout. No more care. How to build custom binding adapters. For example, if it's not just a simple setter, we want to do something more. We can create binding adapter with the name. This string is that string that we use in our XML. And we can provide any name. It should be static and we can place it in any place in our code base. We don't care that the binding framework find all binding adapter annotations in our code and start using it in layouts. So in this code we use the simple setter. But we can't provide any other logic. Here is just example. So really easy to maintain. And what it gives for us? It gives for us easy ability for refactoring. But before we start to look at it, let's look at how view model looks like. In this sample we have three fields. The first field is loading observable boolean parameter. Observable boolean is the same as observable generic class with boolean generic type. But it's for primitive types. So binding framework provides for us for any primitive type. Observable boolean, observable float, observable integer and so on. And also we can provide observable of our custom class. And here if we use set loading is loading. And for example in our XML we set logic like visibility and link the visibility to field is loading in this view model. When somebody change from our code this field to true, the progress bar will appear. And after that it will be hide. So really easy. Also the second field sub-radius. This is the link for our data that will be set to adapter to show in the list. And the third is the on-click listener that will be automatically said happened called when we use on-click event happened in our view. So if our view have on-click set on sub-rated click listener method and we provide the link here in the XML to this method. It will be set and the implementation of this class will be called right on this event. So the power of refactoring. Power of refactoring provide for us, we once in our code, in the whole code, we don't need to care about where we place it. So we place somewhere binding adapter called image URL. And in the image URL all we need to solve one of the main Android problems. It's actually not a problem but sometimes you need to do it. You need to load some image from the web in the background thread cache somewhere. And you use for this third party libraries. There is many third party libraries and you call in your activity or somewhere else. Like for example here PyCasso with this context load URL into this view. And you call it everywhere or you write a wrapper of your image loading library and call it somewhere. But it's easy to refactor. Here with MVVM architecture it's much pretty easy. All you need is provide binding adapter image URL. And in any place of your code on your XMLs you just use image URL and provide link to the observable string in your view model with the URL. So if somebody changed the URL it will be loaded. But if you want to change the library which handle the logic of the loading from this URL you just can change in one place by for example here Glide or Wally or Fresco or SuperDuper image loader. Many on GitHub different loaders. Easy in one single place. That's the power of data binding. So thank you for your time. This is the sample. You can use it. You can check it and also read the documentation. It's really good on the developers.com Android data binding library MVVM architecture. Thank you for your time. Any questions? Thank you. Thank you. Hope you started Android development. Thank you.