HOW TO DESIGN YOUR VIEW CONTROLLERS 

No content

Server API integration Gorgeous animations Gestures Responsive interfaces Bussiness logic Local persistence Social networks integration Interface flow Localization App analysis 

–Robert Martin “A class or module should have one, and only one, reason to change” SINGLE RESPONSIBILITY PRINCIPLE 

Conflicts 

CONSEQUENCES • Hard to read/find Code • Hard to test Code • Hard to change code • Conflicts with team mates 

A BETTER WORLD IS POSSIBLE 

THE VC RESPONSIBILITIES • Acts as an use case conductor • Is agnostic on how other components implement functionalities • Knows on how to react to events 

THE VC RESPONSIBILITIES View Controller UIKit events User interaction Model changes Server side events Change model Send URL requests Show user feedback Change system state The VC needs to be aware of what is happening The VC needs to know what to do 

COMPONENTS View Controller Model objects Data sources Handlers View Framework events UIKit User interaction User feedback Read state Interact with business logic Obtain objects from model State changes 

SEPARATE VIEW AND VC • The VC only controls one View • The VC should know what to show but no how • The View implements all the details of the interface (hierarchy, layout, animations, ….) View Controller View User interaction User feedback 

No content

No content

IMPLEMENTATION BENEFITS • Smaller VC • Simpler VC • The Interface can be refactored without changing the VC • Be able to work with team (S.R.P) 

TESTING BENEFITS • When testing the VC change the View for a Fake View • The Fake View is synchronous • Use the delegate of the view to simulate events from user • Use the Fake View to spy the VC orders • Analyse View Models VC creates View Controller View 

TESTING THE VIEW • The View is a boundary • The View is hard to test • You can use snapshot from Facebook to test layout • You can test your datasources • You can use KIF to do acceptance tests 

EXAMPLE • Building Paper for iOS Facebook Talk to get more information • Find an extended article on how to separate View and VC at jpellat.com • Also find an article on how to test VC • Find an implemented example on my github @jpellat 

DATA SOURCES • The VC has to be agnostic on how we obtain objects • The Datasource are used to obtain and save objects • DataSource interface should allow operations to be asynchronous • You should have different datasources for different kind of objects that can be stored/saved View Controller Data Source obtain objects Save objects 

No content

• The Storages implement how to store and retrieve data from local storages • The Services are interfaces that defines the API of our servers DATASOURCES IMPLEMENTATION • The Datasources components should not work on main thread • DS decides how to retrieve the data, the components implement it 

No content

• Inject the DataSources using the init • Fake your DataSources to return the objects you need for your test TESTING BENEFITS FOR VC View Controller DataSource 

TESTING THE DATASOURCES • The DataSource is a good target for testing • Test that it is obtaining the data from the source you expect depending on the conditions • You can test your storages by saving and retrieving objects and compare they • You can do integration tests with your API for services but can be a blocker on continuous integration :( 

MORE INFORMATION • See Martin Fowler’s article about DataSources • Coming soon on jpellat.com a complete implementation 

HANDLERS • Implement complex operations in Business Logic • Coordinates elements of our system • Is not coupled to the interface View Controller Handler Interact with BL 

No content

No content

No content

• Inject the Handlers using the init • Fake your Handler to spy the interaction of the VC and the Handler TESTING BENEFITS FOR VC View Controller Handler 

TEST HANDLERS • Handlers are a good target for testing • The handlers contain Business Logic we need to test • We can fake the Datasources and services for our tests 

FINAL RESULT • Now we have small and readable classes • Decisions can be delayed • Most of our stack can be unit tested • Our system is easy to extend and change 

No content

@jordipellat jpellat.com github.com/jpellat Doubts?