This document discusses refactoring view controller code in iOS applications using coordinator patterns. It introduces the ViewCoordinator protocol to separate view lifecycle management from view controllers. Additional coordinators like ListCoordinator and QueryCoordinator are used to separate different responsibilities. An EventDispatcher is used to handle communication between coordinators following the patterns. The goal is to improve code structure by applying single responsibility and interface segregation principles.

1. epic refactorings and
patterns to make
your jesse collis (@sirjec)
code awesome
luke cunningham (@icaruswings)

2. firstly, read this book!

3. insert a pic of us
reading our books
having a
‘lightbulb’ moment
we did and it
made us better
engineers

4. we do agile...

6. write the minimum
amount of code to
implement the story

7. 12 months later...

8. 1 small card

10. But that isn’t
what this talk is
about

11. the problem
just too much for one
view controller

12. First Diagram

13. alright stop!
refactor time.

14. first problem

15. view controllers need
only worry about
standard UIViews and
manage the display.

16. coordination and
containment!

17. ViewCoordinator
view lifecycle

18. @protocol ViewCoordinator <NSObject>
- (UIView *)view;
- (void)viewWillAppear;
- (void)viewDidAppear;
- (void)viewWillDisappear;
- (void)viewDidDisappear;
- (void)viewDidUnload;
- (void)didReceiveMemoryWarning;
@end

19. @interface YourViewController : UIViewController {
id<ViewCoordinator> viewCoordinator_;
}
...
@end

20. @implementation YourViewController
- (id)initWithNibName... {
viewCoordinator_ = [[MyViewCoordinator alloc] init];
}
- (void)loadView {
[super loadView];
[self.view addSubview:[viewCoordinator_ view]];
}
- (void)viewWillAppear {
[[viewCoordinator_ view] viewWillAppear];
}
...
@end

21. single responsibility
a class should only
have one reason to
change.

22. second problem

23. they’re not
simple views

24. ListCoordinator
basic selection
callbacks

25. @protocol ListCoordinator
- (void)onSelectListItem:^(id)block;
...
@end

26. @interface YourViewController : UIViewController {
id<ViewCoordinator> viewCoordinator_;
id<ViewCoordinator, ListViewCoordinator> listCoordinator_;
}
...
@end

27. @implementation YourViewController
- (id)initWithNibName... {
listCoordinator_ = [[MyListCoordinator alloc] init];
[listCoordinator_ onSelectListItem:^(id listing) {
[self showListing:listing];
}];
}
- (void)showListing:(Listing *)listing;{
...
}
...
@end

28. interface segregation
clients should not
be forced to depend
on methods they
don’t use.

29. QueryCoordinator
after configure/
cancel configure
callbacks

30. SearchBarCoord...
and so on...

31. now our
structure is more
like this...

33. Go to Xcode

34. under the hood

35. EventDispatcher

36. @interface MapCooordinator <ViewCoordinator, ListCoordinator>
{
...
}
@end

37. @implementation MapCoordinator
...
- (void)onSelectListItem:^(Listing *)block;
{
[eventDispatcher_ on:@"select-listing”
performWithObject:block];
}
- (void)mapView:(... *)mapView didSelectAnnotationView:(... *)view;
{
Listing *listing = ... find listing ...
[eventDispatcher_ fire:@"select-listing" withObject:listing];
}
...
@end

38. there are no
special cases

39. If you implement
patterns -
follow your patterns

40. Coming in iOS5

41. thanks,
jesse collis (@sirjec)
luke cunningham (@icaruswings)