This course will be retired on June 1, 2025.

Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll

Build an Interactive Story App

Preview

Start a free Courses trial
to watch this video

Sign up for Treehouse

Why Do We Use MVP?

3:28 with Ben Jakuben

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.

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 up

    Related 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 up

      You need to sign up for Treehouse in order to set up Workspace

      Sign up