Clear the UIViewController Mess
-
Upload
giorgio-natili -
Category
Mobile
-
view
79 -
download
1
Transcript of Clear the UIViewController Mess
@giorgionatili#MobileTea
Clean up the MVW
messa journey into the abomination of MVC
architecture on iOS
@giorgionatili#MobileTea
Who am I?
Technical Leader and Agile Coach·
Front-end Developer (test first!)
Mobile Developer (iOS, Android, Hybrid with Cordova, c++)
Organizer of Mobile Tea and New England Software
Engineer meetups
Mobile and devices instructor at General Assembly
the mobile dude!
@giorgionatili#MobileTea
on stage
The
UIViewController
spaghetti monster
The invincible
delegates
The wild seguesfor tonight only!
NO.1
@giorgionatili#MobileTea
SmallTalk MVC
courtesy of http://hollance.github.io/
@giorgionatili#MobileTea
Architecture horrors!
What’s Wrong with This?
Controllers are not
just controllers (the
class name should
suggest this)
Controllers are to
much tied in the view
(aka IBAction and
IBOutlet)
UI element s are
configured in the
viewDidLoad
Location services,
map services, etc. are
normally used in the
controller (delegates
arena)
@giorgionatili#MobileTea
Xcode Defaults
The workflow of the interface builder brings you to do a mess!
With IBOutlet how can we
resist to configuring UI
items in the viewDidLoad?
How can we resist to
configuring segues in the
interface builder?
@giorgionatili#MobileTea
Why sucKh a Poor Design?
speeds up the development
decreases the learning curve
reduces the amount of code to write
More often misused and sometimes abused, however:
@giorgionatili#MobileTea
Cleaning Side Effects
97%43%
Reduced size of controllers, improved testability, increased
code base
code will increase
@giorgionatili#MobileTea
VIPER
DECOUPLING LOGIC
FROM UI
PROPER DATA HANDLING
REUSABLE CODE
PONSOS
ALL WELCOME!
SPLIT IN MULTIPLE LAYERS
View Interactor Presenter Entity Routing
CLI support
http://bit.ly/viper-ios
@giorgionatili#MobileTea
View
Handle events invoking presenter’s methods
Exposes a very precise interface completely UI agnostic
The view is passive, it waits the presenter to render data
It’s no longer a Mess View Controller
UI items configuration is now delegated to UIView subclasses
@giorgionatili#MobileTea
Interactor
represents a single use case in the app
contains the logic to manipulate entities (local
and remote)
communicate with the view through the presenter
It’s a wrapper around the data communication layer
Business logic is not anymore in the
controller
@giorgionatili#MobileTea
Presenter
gathers user input and send the request to the interactor
Receives results from the interactor as simple data structures
Updates the view
Orchestrates the communication and
business logic
The controller logic is now completely
decoupled
@giorgionatili#MobileTea
Entity(ies)
It’s a model object manipulated by the interactor
An entity is never passed around the app
The entities are simple and maintainable
CoreData, services, etc. are no longer mixed up
with the view
@giorgionatili#MobileTea
Routing
handles navigation from one view to another
owns the UIWindow and installs the
view(controller) in the window
knows how to react to presenter “signals”
Communication handled through NotificationCenter and
Key-Value Observing
Segues and present/push VierController(s) are not
anymore in the view
@giorgionatili#MobileTea
Files Structure
.objc +-- DataManager | +-- VIPERDataManager.h | +-- VIPERDataManager.m +-- Interactor | +-- VIPERInteractor.h | +-- VIPERInteractor.m +-- Presenter | +-- VIPERPresenter.h | +-- VIPERPresenter.m +-- ViewController | +-- VIPERViewController.h | +-- VIPERViewController.m +-- WireFrame | +-- VIPERWireFrame.h | +-- VIPERWireFrame.m +-- Protocols | +-- VIPERProtocols.h
swift +-- DataManager | +-- VIPERDataManager.swift +-- Interactor | +-- VIPERInteractor.swift +-- Presenter | +-- VIPERPresenter.swift +-- ViewController | +-- VIPERViewController.swift +-- WireFrame | +-- VIPERWireFrame.swift +-- Protocols | +-- VIPERProtocols.swift