Now, before we jump into the android stuff, please be aware that the audio quality does improve.

After the first section of this course.

Be sure to check out the time stamps in the Description box and also check out the pin comment down below for links to more awesome educational content.

So that's it.

Hopefully you enjoy the tutorial.

What's up, everybody?

This is right here and you're watching my jetpack notes and E v M Android Scotland tutorial.

So in this video, what I'm going to do is I'm going to demonstrate the application that will be building throughout this tutorial, Siri's or building in increments.

And then we also have a look at basically a huge list of topics that will be covering so that you know what to expect in this tutorial.

Siri's.

So before we get to those finer details, let's do a quick demo of the application.

Jetpack notes has three features or primary user interface screens.

We're looking at the note list feature currently, and as you can see, we don't have any notes.

So it's kind of in a non Idol ST.

So notice display displays all of the notes, which are currently stored either in the local room database or the remote fire store database.

And the decision of where to save or retrieve notes is based on what they're the user is logged in or not.

And that's actually a concern, which is handled in the back end of the application.

So from this screen, we can also create a new note.

So I'm just gonna hit the plus button and we'll just create new groups.

Can't type new note like so and then I'll hit the checkmark button.

This is also where you can delete notes, and as you can see, we have the new note here.

Next thing I'm gonna do is I'm going to hit the key Ike icon, which will open the log in feature.

And as you can see, we are currently signed in.

So what I'm going to do is I'm going to sign out, okay?

And then I'm gonna head back to the note list feature by heading the backbone.

And as you can see, we have totally different note currently present for because that is, uh, what's coming from the local room database.

So I'm just gonna hit that hit the delete button, and as it can see, that's cleared that out and then we'll just log back in again.

Sometimes it takes a moment.

Here we go.

Area hand boom, you know.

So that's a quick demo of the application, and this is what we will be building in this tutorial.

So in order to fall along with the editorial, you're going to need to visit the depository link down in the description box below, and you'll need to either clone or download the code so that you can follow along properly.

What'll you is in each lesson, all sort of go through with you.

I'll give you specific instructions on how to create a starting point, so we're all on the same page, and then we'll carry on from there.

This tutorial will cover both front end, middle and back in topics for Android development.

For front end will look at constraint Leo Simple Android animations using animation lists using vector graphics which will basically allow you to have cool graphics and animations, which will scale with whatever resolution or screen size we're working with.

I'll show you how to build a recycler view, which happens to be the first thing I ever taught people do on YouTube on.

Then we will look at implementing the navigation library from Jet Pack View models from injured architecture components fragments.

And I'll do in the next video a big talk about model, view, view, model, front end architecture pattern for back in topics I'll teach you about using fire Base Off and Google Sign and provider for a quick and easy user management.

Look at using room and fire store for local and remote data storage, respectively.

I'll teach you how to hide these things behind a repositories so that the front end doesn't know or care where the notes come from, and also learn about simple dependency injection using android view, model and view model providers to get everything nice and wired together.

And finally, we'll talk about how to wire the end to end application together using Katelyn co.

Routines.

And let me tell you, I think you're really gonna enjoy that part, and in this video, I'm going to be giving you on overview and kind of an examination of the pros and cons of using the model view, view model architecture ER, which is the architecture that will be using in this particular tutorial.

Siris.

We'll also have a quick look at the packages and files for the demo application.

Just so you understand what's going on there now, Before we look at this pattern in detail, I'd like to address what I consider to be a few misconceptions about not just model Viv you model but software architecture front end geoeye patterns in general.

So I'm going to assume that most of you have heard about all kinds of different three layer architectures.

There's model view, controlar la TV presenter, Model View view model, which Google seems to be putting all of their weight behind or sorry, the answer came rather.

And then we have other options, like Viper or there's motive, You intent by Highness Dorfman, And I'm sure what most of you are wondering is, would someone please just tell me which one of these is the best architecture?

Well, I'm going to try and burst your bubble right now, because in my personal opinion, the answer and this is opinion is fairly widely shared among senior developers is that the project requirements at hand will dictate the best architecture for you.

So one of the things that I've noticed over the years of trying several different approaches, different patterns is that they work good in some situations, and they can be counterproductive in others.

Now it's better to follow on architecture, which doesn't really work super well for your problem requirements than no architecture at all.

But what I'm trying to say here is that over time when you know things about all these different patterns, just start to see Okay, well, this particular feature of this pattern is useful in situation A.

But it's kind of a problem in situation.

Be so what I would like to do is basically explain in this video that motive you view model is not an exception to that rule.

It is not necessarily the best architecture for all situations, even on the invert platform, but it does have some benefits and some deficits.

So what I would like to do is basically give you an idea what those benefits and deficits are.

And, uh, yeah, we'll get into that in a moment.

But before we talk about that, I'm going to try to give you, like, a general overview of the architecture used by port example.

Okay, so what we're gonna do now is we're gonna talk a little about the model view, view, model, front end graphical user interface pattern before I jump into this.

One thing to note is that unfortunately, developers do not always consistently build these things the same way.

So what I'm going to explain to you is a generalization.

This is my interpretation of the model view, view, model architecture.

But like I say, you're going to find different variations of this.

And the most important thing for you to know is that different variations will work better in different situations.

So what exactly happens, how does it work?

So the first and most important thing that the defining characteristic of model, view, view model, in my opinion is that essentially we have this thing called a view model in the middle, which encapsulates the both the behavior and the state of the front end of the view.

Both the behavior in the state.

So state being the data and the behavior being, what do we do when some event happens?

Kind of deal.

So the thing that's unique about model Viv, you model Is that the this thing in the middle of the view model?

You're not allowed to have this view model actually directly tell the view what to dio.

I'm not allowed to draw a line from here to here, which would be a dependency.

So if you're doing motive, you presenter, you are allowed to do that in model Viv.

You model.

You know these from interpretation Instead, what happens is we basically have to have two dependencies, two different channels from the view to the view model.

This is typically how we like to seven up, So one channel is just synchronous.

And this would be the kind of thing where let's say, for example, if we're coating for android or whatever, the user hits a button and then the view congee just if you know, just do a synchronous call, just a function called to the view model.

Hey, this button was clicked, so that's one of the ways it can communicate with the view model the other way.

And this is how it actually gets the data out of the view model.

And this is confusing for some people.

Is that you see this eyeball thing here?

This is my representation of what's known as the observer pattern s so you could use data mining.

What I like to do is I like to use basically, ah, a producer, consumer consumer relationship or the observer pattern.

It's called between the view model between the view and the view model.

So basically, what I'm saying here is at the start, At some point, the view model will ask for observable Sze.

So it's going to ask for something from the view and this thing that it it gets started.

It's gonna ask for something in the out of the view model.

And when it gets that object that observable object, I want you to think of that observable object as like a pipe that data pops out of at on indeterminate time whenever the data pops out of the pipe.

Whenever the V model asked the model the back end for some data, it's going too.

Then published that data.

And if the view is listening than the View's gonna grab that data that pops out of the the observable pipe, and then it's gonna render that on the screen.

So that's basically how model view of you model.

Generally speaking, works.

So one of the things to keep in mind about this is that the benefit of model Viv you model is can also be the deficit.

So one of the main benefits of it is we can have a many to one ratio of use to view models, and that's because the view model does not depend on any view.

Specifically, the cost of that is that you lose fine grained control over what the view does.

So naturally, in many cases, you're going to have to actually have more logic in your view, because the view is going to have to be able to interpret what's coming in from the observable streams.

So there's different ways to solve that, Um, and the logic isn't necessarily gonna be super complicated, but this is one of the things you want to think about when you're working with model view via model in particular.

So now that I've given you like a general overview of the pattern.

I just wanted to get a little bit more specific about the things I am fond of and not so fond of in this particular architecture, with the hopes that it can help you inform your decision about whether you think it's a good idea to use it or not.

So the most important thing just to start with the cons here in this particular architecture, er, is that the synchronization between the View and the View model presents a problem of separation of concerns.

If you're not sure what separation of concerns is, I've written an article and a link it down in the description box below, and it'll basically explain my perspective on separation of concerns.

But I actually do consider it to be probably the most important principle to observe in software architecture.

And it was the reason why the synchronization logic can be awkward and there are ways around.

It is because we don't have that fine range control over the view.

So this means we have basically two options and these air kind of what I would consider to be subsets of model, view, view model.

So option number one is to basically fill the view with all bunch of logic to interpret the data, which the view model publishes to it.

So this approach will allow you to have very reusable view models, but it's going to basically make it so that you feel your fragments or whatever view class you're using with a whole bunch of logic.

When you feel something with a whole bunch of logic, that's really the time when you really need to be careful about testing now.

I personally don't like to test you.

I classes.

Instead.

I use humble object or passive you, which basically makes those classes generally speaking one liners.

And it makes them simple enough that they don't even directly need to be tested.

If you don't take that approach and you want to fill your fragments or reviews with lots of logic, you will need to probably use espresso or Roble electric to make sure that you're testing everything adequately.

So one of the ways around this, and this is the key problem is the presentation.

Logic is awkwardly distributed between the view and the View model.

One of the ways around this is to actually make it so that your view model knows a fair amount about the particular view that it's working with.

So what I mean by that is it's not that it has a direct dependency, but you can fill your view model with all kinds of in this tutorial would be like live data observable Sze uh, You can fill it with a whole bunch of these observable fields, which will dictate, for example, should this text box be highlighted, or this that and the other basically details about the view without actually having indirect dependency.

So this will allow you to basically pull a lot of logic out of back out of the view and into the view model, and that's gonna make for a much easier to test view.

The caveat to doing this is that if you have all kinds of details about a specific view interview model, even if there's no direct dependency, you are still tightly coupling that view model to that particular view.

So you lose the reusability of the view model if you take that approach in exchange for not having to have a whole bunch of logic in your fragments.

So with those considerations in mind, which aren't necessarily application breaking.

But as you can see, there's not actually a truly specific motive you view model pattern here.

There's actually some variations in it, and this is something that I've even heard the Android team admit when they were looking into this particular pattern.

So, as you can see, we've kind of got these different approaches to it, and they're gonna have different benefits.

So if your user interfaces air like super simple, then you're probably gonna be able to get away with having fairly decoupled on specific view models.

And that's kind of one of the main benefits of this particular approach is that if you don't tightly couple your view models to predict particular views, great English, er, then you can promote the reusability of those real models.

Ah, side benefits is, of course, you are applying some kind of separation of concerns by separating the these things out.

So you're gonna get some benefits to testing and modularity as well.

And one important feature which this is something that specific toe Oh, and for its particular tools or inferred architecture, components and jet pack in that.

But one of the biggest benefits for this particular approach on the under platform is that concurrency and life cycle really is a breeze.