Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
When used correctly, the three components of the MVP pattern communicate to each other through clearly defined interfaces. This makes updates and enhancements much easier for ourselves and others.
Related Links
- Model-View-Presenter Pattern (Wikipedia)
- Introduction to Model View Presenter on Android
- What are MVP and MVC and what is the difference?
- Model-View-Presenter: Android guidelines
In this video we mention the Single Responsibility Principle, which basically states that each method or class should have a single responsibility. It makes for cleaner, more organized code. This is one of the SOLID object-oriented principles which are five basic principles for object-oriented programming and design.
GitHub Repo
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
So, how exactly does
the Model-View-Presenter pattern help us?
0:00
A big part of good programming
practice is separating concerns.
0:04
This means that we organize our code so
0:07
that different sections have
distinct responsibilities.
0:09
We don't want one class that
gets data from the network,
0:12
calculates some statistics,
plays a movie and sends SMS messages.
0:15
All those things should be handled
by distinct classes or components.
0:19
The MVP pattern is designed for
exactly this goal.
0:22
Where it really shines is when
we need to make updates or
0:25
big changes that only effect one
part of this MVP combination.
0:28
When we set it up correctly,
0:32
these three components communicate to each
other through clearly defined interfaces.
0:33
That means that we can completely
substitute any component in the pattern
0:37
with a different version, as long as
it uses the exact same interface.
0:41
Let's imagine that, instead of getting our
story data from directly within our code,
0:46
we want to download it from a server.
0:50
As long as the data was available
from the web in the same format
0:52
as how we store it on the phone then, we
can switch the model part of our app and
0:55
leave the view and
presenter parts exactly the same.
0:59
You would only need to change those few
parts of the code where the story is set
1:02
up as objects to be used in the activity.
1:05
The activity will use those
objects the exact same way,
1:08
no matter how they are created or
what data they hold.
1:11
And it will be presented on
the screen the same way, too.
1:14
On the other side,
1:16
we can completely change how our app
looks by just changing the layout files.
1:17
As long as the same fields and
controls are present with the same IDs.
1:21
Then we can completely change the color,
layout, images, or
1:25
whatever to totally overhaul
the user interface of our app,
1:29
without touching the activity
Java files or anything else.
1:32
Essentially, each component in
this pattern should not know nor
1:36
care how the other parts are implemented.
1:39
As long as the contracts of
those interfaces are met,
1:41
then everyone is happy.
1:44
When we are programming our model,
1:45
the model shouldn't know about
how it will be displayed.
1:46
It's like the model is saying, hey,
1:49
here I am, just do what you want as
long as you display me, I'm happy.
1:50
Following the pattern
also makes it easier for
1:54
others to work with our code rather than
wading through one big messy file of code.
1:57
A newcomer to our project can
know right away where to look for
2:01
certain things in the code and will be
able to pick it up more quickly for
2:04
fixes, changes, or enhancements.
2:07
Also, and we'll see this in later
material, using the MVP pattern in android
2:10
allows us to separate background tasks
from the presenter layer activities so
2:14
that the background work can
run independent of things
2:19
related to the lifecycle of an activity.
2:22
Another benefit of MVP is that, it helps
us follow another good programming
2:24
practice the single
responsibility principle.
2:28
Remember that good object oriented
design principle state that,
2:30
every class should have only
a single responsibility.
2:33
By structuring our code as models,
views and
2:37
presenters we keep responsibilities
nearly defined within each class.
2:39
Now, if we don't follow this pattern and
2:45
instead have everything in
a big messy file of code, well,
2:46
then we might have to update code all
over the app for even a small change.
2:50
Trust me, there are plenty of
ways to mess up this pattern in
2:55
any kind of software development.
2:58
But, don't worry about that right now.
2:59
Don't let it stop you,
it gets easier the more you use it.
3:01
That's actually how it went for me.
3:04
This is the kind of thing that I learned
in a classroom that really didn't
3:06
have much meaning until I started
writing code that implemented it poorly.
3:09
From my own headaches, I learned why it
was valuable to stick to this kind of
3:13
pattern and how to keep my components
self-contained with clean interfaces.
3:16
Now, I still mess it up sometimes and
that's okay.
3:21
I just refactor it until I'm happy
with it or, I get help from others.
3:24
You need to sign up for Treehouse in order to download course files.
Sign upYou need to sign up for Treehouse in order to set up Workspace
Sign up