Design your UIViewController

The View Controller subclasses are by default complex, hard to test and hard to read classes. In this talk we will define techniques we can use to implement our view controller simpler, testable and clean

Transcript

1. HOW TO DESIGN YOUR VIEW CONTROLLERS
3. Server API integration Gorgeous animations Gestures Responsive interfaces Bussiness logic Local persistence Social networks integration Interface flow Localization App analysis
4. –Robert Martin “A class or module should have one, and only one, reason to change” SINGLE RESPONSIBILITY PRINCIPLE
5. Conflicts
6. CONSEQUENCES • Hard to read/find Code • Hard to test Code • Hard to change code • Conflicts with team mates
7. A BETTER WORLD IS POSSIBLE
8. THE VC RESPONSIBILITIES • Acts as an use case conductor • Is agnostic on how other components implement functionalities • Knows on how to react to events
9. 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
10. 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
11. 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
14. IMPLEMENTATION BENEFITS • Smaller VC • Simpler VC • The Interface can be refactored without changing the VC • Be able to work with team (S.R.P)
15. 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
16. 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
17. 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
18. 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
20. • 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
22. • 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
23. 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 :(
24. MORE INFORMATION • See Martin Fowler’s article about DataSources • Coming soon on jpellat.com a complete implementation
25. HANDLERS • Implement complex operations in Business Logic • Coordinates elements of our system • Is not coupled to the interface View Controller Handler Interact with BL
29. • 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
30. 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
31. 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
33. @jordipellat jpellat.com github.com/jpellat Doubts?