A Swift Approach To Data Binding

Cocoaheads Berlin Talk 18.11.2015

Transcript

1. A Swift Approach To Data Binding Cocoaheads Berlin, 18.11.2015 Kersten Broich
 (iOS Developer at Kitchen Stories)
 
 @kersten_broich
2. Kitchen Stories • Backed by Parse™ • Content • Social App Some facts to start..
3. Trouble? .. of course!
4. Freestyle MVC Do what you want as long as a UIViewController is involved..
5. Freestyle MVC Models should be the backbone of the app..
6. Bad Model API Design?
7. Core Data – Soroush Khanlou “Core Data was designed before the prevalance of web services and APIs. It was intended to represent an object graph in its entirety, rather than a small portion that has been downloaded from a service. Since you don't have the whole dataset, you can't even effectively query against it.” http://khanlou.com/2015/07/cache-me-if-you-can/
8. Core Data • Slow.. But not necessarily Core Data’s fault • Notifications, Synchronisation, Data consistency • Do we really need it with our use case? • Object graph is relatively simple
9. Freestyle MVC How can I control something when I don’t know what’s going on..?
10. Massive View Controllers • No clear architectural guidelines • Huge implementation files • Lots of undocumented dependencies • A big mess
11. Maybe we can do it better?
12. …but where to start? • Time for research (very important!) • Build little prototype projects that demonstrate the use of core technologies. • Discuss as a team and ask other’s for input • Document your decisions
13. Decisions!
15. • Large Objective-C codebase (grown since ’13) • Swift is the future • It’s fun and it’s safe!
16. Immutable Objects “One thing that a lot of us learned the hard way is that these (model) objects should be immutable.” Chris Eidhof https://www.objc.io/issues/7-foundation/value-objects/
17. • Mutability is a source of bugs (Objects might change when you don’t expect changes) • Take every opportunity to reduce complexity (i.e. in multi-threaded contexts) • Swift makes immutability in models easy by just using ‘let’ Why?
19. MVVM
21. Clear separation of concerns
22. MVVM in every new module …when in doubt it’s a Service..
23. Architecture Proposal Service Layer (FeedService, UserService) API Client View (ViewController + Views) ViewModel Model (Recipe, Article) Cache
24. Data Binding …establish a connection between the application UI and business logic…
25. KVO in Swift
30. How do we define a Listener? Reference View Controller from a wrapping class
31. How do we define a Listener? Reference View Controller from a wrapping class
32. How do we define a Listener? Reference View Controller from a wrapping class Create a listener protocol and make listeners adopt to it
33. How do we define a Listener? Reference View Controller from a wrapping class Create a listener protocol and make listeners adopt to it
34. How do we define a Listener? Reference View Controller from a wrapping class Create a listener protocol and make listeners adopt to it Closure
36. Putting the pieces together
38. Basic data types are now boxing classes
40. Wouldn’t it be nice if… • Listeners and therefor closures are not referenced within the encapsulated data type? • We could register multiple observers to a property? • We could unregister an observer from a property? • and all of that is thread-safe?
42. • Event-Driven Data Binding framework in Swift • Abstract definition of an EventProducer type • Extension on UIKit components • Observing/Unobserving • Transforming Events • Bidirectional bindings
43. Bind all state-dependent 
 UI-Components to View Model properties!
44. The Observable
 (Dynamic) Encapsulates a value that can change and informs observers about that change The Event Producer
45. View Model performs data update performs batch operations on the array and emits a batch operation event when ready. leverage fine-grained change set events
46. View observers the View Model’s data
47. Transform Event Producer Map Filter DeliverOn Throttle Skip StartWith CombineLatestWith
48. Decisions!
50. Thank you!