Hey, welcome back.

We're gonna take a short break from code to talk about the popular software

design pattern called model-view-presenter, or MVP, for short.

Now don't worry if this video seems a little unrelated at first

to the app that we're working on.

We don't need to know all the intricacies

of the model-view-presenter design pattern.

But the more we know about it and

keep it in mind, the better software developers we will be.

We don't necessarily need to follow it for smaller apps like this.

But good programming patterns and

practices are invaluable on larger projects or when working with teams.

By the way, in a previous version of this course,

we taught this as the model-view-controller design pattern.

The two are often used interchangeably, but there are subtle differences.

And the model-view-presenter pattern more closely aligns

with how Android apps are architected.

So first off, what is a software design pattern?

When writing code,

you'll always end up facing problems that are common to all developers.

For example, one of those problems is how to architect our apps so

that our components are largely reusable.

Solutions to these common problems are known as design patterns.

And while you weren't explicitly aware of it, we've been working with

the model-view-presenter design pattern all along.

Let's start with a very generic example.

Think of a slideshow presentation you have given at work or

in a class using a tool like PowerPoint, Google Slides, or Keynote.

In this case, you are the presenter.

Your job is to control what is on each slide and when they are displayed.

These slides are being presented on a large screen, which is the view.

This is how the audience views your material.

Lastly, the data used to create your slides is the data model.

Maybe your presentation is about earnings, or the results of experiments, or

maybe your favorite episodes of Dr. Who.

Whatever it is, you collected data and

formatted it in some way to be viewed on the screen.

This pattern is the same for Android apps and games.

The model is the data that you use in the app,

the view is how it is actually displayed on the screen, and

the presenter manipulates the data and objects in some way.

So next, how does this apply to our current app?

Think for a moment about how this interactive story is set up.

On the phone, itself, is the screen that the user interacts with.

The layouts we create for our activities are what are shown on the screen, so

let's call those the views.

The layout is a presentational aspect of the app that the user views and

interacts with.

Now what piece of our app presents these layouts, these views?

What part of our code manages how and when things are shown?

And what should happen when things are tapped?

That's right, the activities.

These are the presenters in the MVP pattern in Android.

As a side note,

you will sometimes hear the presenter referred to as the controller.

Since it controls both the view on the screen and the data model.

We'll stick with presenter, though, as that's more widely used for Android.

If you're interested in reading more about the exact differences between MVP and MVC,

check the teacher's notes for some links.

The presenter's also responsible for interacting with the data model behind

the scenes, just like how you create and display slides in a presentation.

Presenter is what adds, changes, or deletes data in the model

based on what the user is doing on the screen, or the view.

So that leaves us with the model.

All the data in our app,

as well as the logic around that data, goes into model objects.

It helps to make the connection by thinking of the phrase, data model.

Now what kind of data are we about to work with?

That's right, in this case, it's our story.

The data can really come from anywhere.

We'll build it right into our app here, but it could be data from someplace

on the web or even elsewhere on the phone, like from a gallery of photos.

Wherever we get our data from, the model object's represented, and

our presenter gets it ready for display.

Presenter may even adapt the data, like when we take a long time step and

convert it to a shortened representation that may differ from region to region.

When we follow this MVP pattern,

the model does not communicate with the view in any way.

This way the model object can be separated from the view and

reused across other views without having to repeat or

re-implement some of the same functionality.

This setup is the basic architecture for most Android apps.

The core Android code that we use to develop apps has been designed in

such a way that we're kind of forced to follow this pattern.

The model is whatever data we need to work with.

The views are the actual user interface of an app.

The layouts of buttons and other things are the XML layout files.

And the presenter is the activity where we do stuff behind the scenes and

update the view or the data model.

As you go further with Android development, you may even come across

variations of these patterns that have the same basic ideas,

but differ in some of the details for very specific reasons.

We'll eventually talk more about those in later courses and workshops.

But understanding the basic MVP architecture is some key groundwork.

All right, so that tells us a bit about what MVP is and how it's used in our apps.

But we're still missing the why behind it.

Don't worry, though, that's coming up next in the next video.