Introduction to MVVM on Android - Tutorial - Learn Android Architecture Patterns

making an Android app in itself is not all that hard once you get the basics right making a maintainable app is a whole different story though you have to give your code a furbish structure prevent yourself from putting all the code inside an activity or a fragment and make many smaller classes which have a single responsibility how can you achieve all of this with architectural parents MVC MVP mvvm which stands by the way for model view viewmodel and while anything is better than the dreaded spaghetti code mvvm is one of the best options for android development it's even fully supported and encouraged by Google with their first party libraries [Music] hello welcome to reso coder and in this video you are going to learn all you need to know to have an idea about what mvvm model view viewmodel actually is as much as I don't like theory sometimes is just important to know before jumping into actual coding there is nothing worse than writing code that you don't understand in another video you will create a real app demonstrating the principles outlined in this theory centric video so make sure you subscribe and also hit the bell button so that you are notified about all of my new videos including this one also if you want to go through the contents of this video at your own pace and have a nice slow look at them you can do so by reading an article over at reso code recom to which you can get by clicking on the link in the video description so now without any further ado let's get started with mvvm on android first why do we even need something like model view viewmodel well it's separation of concerns and separation of concerns is a beautiful thing and every single design parent tries to do the best that it can to achieve it in the case of model view viewmodel there are three different parts which help in accomplishing the separation of concerns models views and view models you can also add and actually should add a repository which acts as a single source of truth for all the data that you are getting and we will come back to single source of truth in the form of repository later now let's dissect the different parts of mvvm and we will start with view in the context of mvvm view doesn't mean the base class of all of your text views and recycler views and so on instead it's a part of your app which handles what the user sees and touches on the screen in other words a view does all the things an activity or fragment can do here comes the most important part though views handle only the immediate interaction with the user what does this mean well you simply don't put any business logic like communicating with a database inside your activities or fragments directly your activities or fragments in our words views can only display stuff on the screen and that stuff they get from view models they can also do android specific operations but you should probably separate it out into another class but if you have something really simple to do you can do it inside an activity or a fragment and also views can dispatch user interaction events obviously which are something like clicks or swipes and they are dispatching it to their respective view model so most of the UI logic is actually centered in the view model there is no real logic inside the view except for really simple cases next up comes the view model and the view model is like a glue between a view and business logic it provides data for the view by getting it from the repository and when you take a look at the diagram which is now on the screen you might wonder how does the view get all the data which it should display the arrow is pointing on in one direction toward the view model this means that the view model doesn't have any clue about which views are using it because it doesn't have a direct reference to it as opposed to the view which has a reference to its view model well this is amazing for testing and simply for less entanglement between classes is also known as tight coupling so we want to have loose coupling the view model still needs to tell the view what data to display otherwise the app will not be functional the trick here is to make the appropriate data and view model observable by doing this we get rid of the need to directly update the view from the view model when data changes a view already has the reference to its view model so it can simply observe some data which the view model exposes when the data changes all of the views which are observing it will be notified about this change this is contrary to model-view-presenter pattern where a presenter has a reference to its view here the view model doesn't have any reference to its view but it simply exposes some data some functions and the view can then observe this data this observation can be done through live data which is a handy life cycle where library for creating observables you can also use rx Java or something else if you so desire but live data is really the first-class citizen it's also supported by Google and it's a first-party library one of the advantages of live data is that it automatically doesn't notify the observer if it's activity or fragment is already destroyed so this leaves you free for managing the lifecycle yourself otherwise you will need to unsubscribe from your observers in ondestroy function then we have the model model is where you put all of the business specific code well technically there is an intermediate set between the view model and the model in the form of a repository as you can see on the diagram you can kind of regard everything from repository downwards at its own group of classes which are far away from the user interface these operate on your ABS data and fetch it from the local database or from the network repository has a special role of being a mediator between local storage and the server this is where we check whether the remote data should be cached low cailli and so on repository is also the single source of truth for view malice as I have mentioned previously in other words when a view model wants to get some data it gets it from the repository then it's up to the repository to decide what to do next as far as the view model is concerned the data could be fetched from a toaster or from a supercomputer it doesn't care that's the business of the repository repository cares view model doesn't now let's also talk about the connectedness of model view viewmodel components not only that the view observes data in the view model but also the view model observes data in the repository as you can see on the diagram which in turn absorbs data coming from the local database and also from the remote data source to put this all into perspective you can think of the connections between models views view models and repositories in our classes in the following manner when traversing down the hierarchy which you see on the screen the upper class has a direct reference to its child so view has a direct reference to view model view model has a direct reference to repository repository has reference to model and remote data source and so on on the other hand the child doesn't have a reference to its parent children only expose some data by allowing it to be observed through live data or any other library if you so desire so from this simple diagram we get this arrow clutter diagram which you can see right now I wanted to spare you of the non necessary clutter at the start so that's why those observable arrows weren't present in the first diagram showing mvvm as you can see the solid lines represent a direct reference whereas the dashed lines represent observables the last important thing which I need to mention here is that you should always adhere to the reference tree which you can see right now for example don't make your view model get data from the database directly while bypassing the repository everything has its perp and makes the code modular easy to maintain and nice to read also you will read your code many more times than you write it so make readability the number one priority don't be lazy to create abstractions and trust me you will thank yourself later alright so that's it for this video in the next tutorial you will build a real Android app which utilizes the mvvm architectural pattern so be sure that you subscribe to this channel and also hit the bell button so that you aren't going to miss it if this tutorial helped you understand model view viewmodel pair and give it a like and also share it so our people can learn about it too check out the post from the link in the video description leave a comment follow me on social media and see you in the next video [Music]

Channel: Reso Coder

Views: 132,435

Rating: 4.9657664 out of 5

Keywords: resocoder, tutorial, programming, code, programming tutorial, mvvm android tutorial, android design patterns, android mvvm, android architecture components, android mvvm tutorial, android mvvm architecture, android mvvm kotlin, android architecture, android architecture components tutorial

Id: _T4zjIEkGOM

Length: 10min 3sec (603 seconds)

Published: Fri Aug 31 2018