5. Some assumptions
★Core Data for persistence
★As few external dependencies
as possible (i.e., no
Reactive Cocoa)
★Examples referred to iOS.
(Many similarities with OS X,
but some differences too)
5
6. Design Patterns
★Predefined solutions to common
problems with additional benefits:
๏Reusable
๏Loosely coupled
★Some examples:
๏Singleton
๏Delegate
๏Observer
6
7. Defining a design pattern
1. Name
2. Problem
3. Solution
4. Consequences
7
9. "Different people reading about MVC in
different places take different ideas from it
and describe these as 'MVC'. If this doesn't
cause enough confusion you then get the
effect of misunderstandings of MVC that
develop through a system of Chinese
whispers.”
Martin Fowler
Painful truth
10. A tricky question
If [Model] + [View] + [Controller
/ Presenter / View Model] =
[TheApp]
How can Controller != Presenter !
= View Model?
★Responsibilities matter!
★Other components (patterns)
might be involved.
10
11. The goal
★Separation of responsibilities
into roles. Is it? Not
historically. Other motivations.
Solving problem d’jour.
★Now why?
๏Testability
๏Reusability
๏Extensibility
11
12. Responsibilities
★Handle low level events
★Handle high level events
★Update user interface
★Apply changes to the domain
model
★Presentation logic
★More…
12
14. MVC: The early days
★View
๏Visual representation of the model
๏Receives references to the model to
know the data to display. (Not too
reusable views)
★Controller
๏Deals with user input, app <-> human
(old paradigmas)
๏Shows the widgets change and tell the
model what to do.
★Model
๏Data and business functionality
(domain).
๏No references to the UI.
๏It is observable.
๏Display logic is part of the model.
Ctrlr
ModelView
15. MVC: The early days
★Separated presentation: Model
<-> Presentation (= V+C)
★Observer originated from MVC,
but observing full object
(properties = scalars)
★Variations: Passive model The
model cannot send updates
(for example HTTP)
15
17. Apple’s MVC
★View
๏Only UIView subclasses
๏Show information and handle input to generate
higher level events passed to controller
๏Fully reusable views library. Consistent L&F
★Controller
๏Views delegate / control what’s displayed
๏Receive the events and converts them into
calls to the model.
๏_Knows_ about changes in the model and update
what is displayed on the view. Typically a
UIViewController. Responsible of presentation
logic.
★Model
๏Contain the business logic. No references to
the UI.
Flow synchronization vs Observer synchronization
MVC = Composite + Strategy + Observer
Ctrlr
ModelView
19. Apple’s MVC: testability
★The views are somebody else's (Apple's)
problem.
★Model is easy to test.
★Controller is huge & has dependencies
on the model and on the views. =>
Complex to test.
★Too many levels of abstraction, only a
few methods exposed.
★Some stuff in view controller that it
is usually not tested.
19
21. MVP
Origin: IBM & Taligent (=IBM + Apple)
★View
๏Shows information and process the
input gestures transferring control
to the presenter.
๏View is updated using the observer
pattern.
★Presenter
๏Respond to high level events (user
acts)
๏Generates commands (Command
pattern) for the model. (Easy undo
redo)
★Model
๏Receives the commands and acts on
the domain information
Prstr
CmdsInteract
ModelView
Selec
22. MVP Code Distribution
★Model:
๏NSManagedObjectModel,
NSPersistentStore,
NSPersistentCoordinator,
NSManagedObjectContext, &
UIManagedDocument
๏NSManagedObject subclasses and
its categories (or additional
methods).
๏NSFetchRequests
★Selections:
๏NSFetchedResultsController
★Commands:
๏NSInvocation / NSUndoManager
★Presenter:
๏Observer
๏Targets/selectors for the
views actions & View
delegates.
๏Presentation logic
๏View controller
★Interactors:
๏Gesture recognizers
★Views:
๏UIButton, UILabel…
23. MVP testability
★Apple's MVC is closer to this than to
classic MVC (Even more compared to the
Dolphin MVP).
★View Controller belongs with the view.
★Properties are now objects, instead of
scalars, so observation is per property.
Easier to deal with indirect invocations.
★More parts, more difficult to write, but
easier to test and reuse.
★If model uses Core Data the command
pattern is almost there (undo/redo).
23
25. MVVM
★View
๏Shows information and process the
input gestures transferring control
to the presenter
๏View is updated using the observer
pattern. View + View Controller
๏Responsible for display logic,
themes...
★View Model
๏Respond to high level events (user
acts) Provides calls to the View
(invoked via the view controller)
๏Validation logic.
★Model
๏Receives the commands and acts on
the domain information
VM
VC
ModelView
26. MVVM Testability
★The view controller is conceptually attached to the
view role.
★The View Model would be the same for different
platforms, since there isn't any specific mention of
the views.
★Presentation logic (like formatting strings) belongs
to the model. Easier to test exposed methods.
★MVVM is the E&E (embrace and extend) version of MVP.
★Data binding is NOT a key difference.
★Rx programming claim increased testability:
๏doesn't need shared mutable state
๏can be composed
๏no callback hell.
26
29. Lessons Learned
★Same name used for different
patterns.
★Good to understand patterns
for your business (& mental
health).
★A range of possibilities =
trade offs.
29
30. References
★Alfonso Alba García
“Bienvenido a la república
independiente de las pruebas
unitarias con Core Data”,
2013
http://es.slideshare.net/
aalbagarcia/bienvenido-a-la-
republica-independiente
★The Gang of 4, “Design
Patterns: Elements of
Reusable Object-Oriented
Software”, 1994
★Derek Greer “Interactive
Application Architecture
Patterns”, 2007
http://aspiringcraftsman.com/
2007/08/25/interactive-
application-architecture/
★Martin Fowler, "Patterns of
Enterprise Application
Architecture”, 2002
★Martin Fowler, “GUI
Architectures”, 2006
http://martinfowler.com/
eaaDev/uiArchs.html
★Ash Furrow “Model-View-
ViewModel for iOS”, 2014
http://www.teehanlax.com/
blog/model-view-viewmodel-
for-ios/