Room + ViewModel + LiveData + RecyclerView (MVVM) Part 1 - WHAT ARE ANDROID ARCHITECTURE COMPONENTS?

hey guys in this video series we are going to build an app roof Android architecture components one of which is a library card room but before we talk about the different architecture components let me quickly show you how to end result will look so we are going to build a simple note-taking app where each node has a title a description and a number for the priority they are stored in SQLite and they are either displayed as items in a recycler view we can add new notes like this modify existing nodes and update them trapping them off and over this menu option up here we can also delete our nodes at once this app is not very fancy or special but the point of this tutorial is to get started with Android architecture components and learn how to implement them and the first part I will give an overview about the different architectural components that we will use in this app and how they work together and in the upcoming parts we will then learn about each component in more detail while we are building the app I will try to explain everything in a way that a beginner can understand it tour and I am NOT a professional myself but it definitely helps if you already have some experience in Android development so the Android architecture components are a bunch of different libraries that are supposed to help us build more robust and maintainable apps but what does maintainable mean and why do we need an architecture in the first place as beginners we often just put almost all the code directly into our activities and fragments we store and process data there we start and stop different long running tasks and we manage their life cycles in the different karbix I think as a beginner that's okay because we have to start somewhere and for smaller projects that's not really a problem but when an app gets bigger the sty decoupled code can turn into a problem because it gets harder and harder to make changes to it or even completely swap implementations without always having a huge ribbon effect through the rest of the codebase and managing the activity and fragment lifecycle becomes harder the more stuff we put in there also the souq hard spaghetti code is hard to test because many different paths depend on each other and architectural patterns are there to help us create more separated modular components where each part of the program has the way defined responsibility and can ideally be modified or replaced without touching any other component but until not long ago at the stands of the Android team about the topic was we provide you the framework and the core classes that interact with the Android system but your developers have to decide yourself how you organize your app and which architecture you use this model also gives application developers the freedom to choose whatever framework they want inside their application for their internal framework so that means that we on the add Bruyne team don't have to get involved in debates about whether MVC is better than MVP or whether MVP is better than mvvm you guys can take whatever makes sense to you and why we still have this freedom to build our apps in the way we want the entry team decided to actually give a recommendation on a certain época texture and also provides the necessary tools and form of the architecture components and they have announced all of this at the Google i/o 2017 the very first thing we are shipping is an architecture guide on developer.android.com/design us for our opinion like how do we think then an application should be built and this is that guide so we believe that is very good covers lots of application cases second we are shipping a new set of libraries that we call architecture components these are more fundamental components where you can build your application on top now we will not use all the available architecture components but I would say the most important ones that make sense to learn first we want you a state our binding navigation paging or work manager in this video but some of them like work manager are still in the a version at the time of making this video anyways but of course I will make videos about the other components in the future as well so stay tuned for that so let's take a look at how our app will be structured as I already mentioned we will save our data in an SQLite database in the past working with SQLite and Android was quite complicated we had to create an SQLite open hyper class write a lot of code to create different tables and make operations on them and small mistakes like forgetting a comma or a space in an SQL statement but caused a runtime exception which then caused the app to crash and in the worst case this could happen while the app was already in production for this reason the Android team created the room persistence library which is a wrapper around SQLite that takes care of most of the complicated stuff that we previously had to do ourselves we have to write much less boilerplate code to create tables and make database operations and room provides compile time verification for our SQL statements so when we for example try to create a column that doesn't exist or if we make a typo in an SQL statement we can't even compile our code and this is obviously much better than having the app crash at runtime where someone is already using it we are going to learn about room in more detail throughout this video series but just as a quick overview we can turn Java classes into silk identities which basically each represent a table in the SQLite database and then we have something called data access object or short Tower which is used to communicate with SQLite the next architecture component that we will use is a class called view model which basically has the job of holding and preparing all the data for the user and of his so we don't have to put any of it directly into our activities and fragments instead the activity or fragment connects to this view model gets all the necessary from there and then only has the job of drawing it onto the screen and reporting user interactions back to the view model the view model then forwards these user interactions to the underlying layers of the app either to load new data or to make changes to the data set so the view model basically works as the Gateway for the UI controller which is the activity or fragment to the rest of the app and we don't initiate any database operations from our activity directly so the activity itself doesn't know what is going on down here this way we keep our activity and fragment classes lean and the best thing about the zoom of the class is that it's arrived configuration changes so as you might know when we rotate an Android device or make any other runtime configuration change like changing the text size of the device the activity on the screen gets destroyed and recreated for the purpose of providing an alternative layout file or other resources this also means that we lose the state of this activity and its member variables and we basically start with a completely new one in the past there have been different ways of retaining and recreating the data like saving and restoring variables in the different lifecycle Quebec methods of the activity we also had to a start and stop and clean up different asynchronous operations like Network arts and the correct lifecycle methods otherwise you would get bugs memory leaks and crashes and all of this made our activity is pretty huge pretty quickly because we always would have distorted life cycle methods if you want to know more about the topic I report videos about the activity lifecycle and insensate into the info card box in the top right corner of this video but generally this whole saving and restoring process gets very complicated very quickly it's prone to errors and it also wastes resources because we sometimes have to reassure cards that have already been made with few models we don't have this problem anymore because there's a way of configuration changes and our new activity just receives the same view model instance that still contains all the data in our app the only data source will be our room database and our connection point to SQLite will be the doll but the view model will not Kile methods on the dough directly instead there will be another class in between card the repository is just a simple java class and not something special from the architectural components library but it's a recommended approach because in the repository we can mediate between different data sources like our local SQLite database and the web servers and the view model doesn't have to interact with the different data sources directly it doesn't have to care about where the data comes from or how it is fetched and instead the repository creates this clean API where the view model can connect to so it's just another abstraction layer that helps us modernize our app and it gives our view model in single access point in this tutorial we won't fetch data from the internet but we will still use a repository okay so these are the different layers of our app and this is also the recommended architecture now you have probably already heard about MVP and mvvm and abbreviations like that and this approach constitutes an mvvm architecture short for a model view viewmodel we are the data sources the model the activities and fragments by the viewer or the user interface in other words and the view model class is obviously the view model and if we implement this correctly we have a nice clean architecture where our layers are modular and decoupled from each other and every part has well-defined responsibilities every layer only knows about the component directly below it the view model gets the data from the repository but it doesn't have to know how to data is retrieved from the different sources and the UI controller trusts the data from the view model onto the screen but it doesn't have to store the data itself or initiate any database operations directly but that's not all there's another important architecture component that will play a major role here and that is life data life data is a wrapper that can hold any type of data including lists and it can be observed by the UI controller which means that whenever the data in this live data object changes the observer automatically gets notified with the new data and can refresh the UI in reaction to it another great thing about live data is that this lifecycle area which means that it knows when the activity of reg'ment that observes it is in the background and automatically stops updating it until it comes back into the foreground so we don't have to manually stop and resume observation in our activities and fragments lifecycle methods and it also cleans up any references when the Associated life for example activity is destroyed so to summarize we have the view model that survives configuration changes and in it we have observable life data that automatically does the right things at the right time in the life cycle of our activities and fragments and together the saves us from a lot of lifecycle related problems and potential bugs and memory leaks in the future instead of starting and stopping things and our activities and fragments it will be much more common to just initiate an operation one time in oncreate and then forget about it now usually we have to take care of updating the data in this life data object ourselves but since room is designed to work perfectly together with the other architecture components it can return live data out-of-the-box and we don't have to take care of updating it this means we can observe data in our database and whenever we make any changes to the database we can update our UI immediately and this is why when we add new data or make any changes to it everything gets displayed immediately because this is life data okay so this is a general overview about the architecture of our app and we will start building it in the next video so make sure to subscribe to the channel to not miss it and if this video is helpful please if you like take care you

Channel: Coding in Flow

Views: 334,856

Rating: 4.968852 out of 5

Keywords: 2018, android, android development, android studio, android studio tutorial, beginners, java, android architecture, android architecture components, android architecture overview, android mvvm, android mvvm tutorial, android mvvm architecture, android mvvm simple example, android viewmodel, android viewmodel livedata, androidviewmodel example, android viewmodel tutorial, android room, android room tutorial, android room persistence library, architecture components android, entity

Id: ARpn-1FPNE4

Length: 11min 27sec (687 seconds)

Published: Tue Aug 28 2018