Epic Refactorings - Melbourne Cocoaheads June 2011

421 views

Published on

By Jesse Collis and Luke Cunningham. June 2011

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
421
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Epic Refactorings - Melbourne Cocoaheads June 2011

  1. 1. epic refactorings andpatterns to makeyour jesse collis (@sirjec) code awesome luke cunningham (@icaruswings)
  2. 2. firstly, read this book!
  3. 3. insert a pic of usreading our bookshaving a‘lightbulb’ moment we did and it made us better engineers
  4. 4. we do agile...
  5. 5. write the minimumamount of code toimplement the story
  6. 6. 12 months later...
  7. 7. 1 small card
  8. 8. But that isn’twhat this talk isabout
  9. 9. the problemjust too much for oneview controller
  10. 10. First Diagram
  11. 11. alright stop!refactor time.
  12. 12. first problem
  13. 13. view controllers needonly worry aboutstandard UIViews andmanage the display.
  14. 14. coordination andcontainment!
  15. 15. ViewCoordinatorview lifecycle
  16. 16. @protocol ViewCoordinator <NSObject>- (UIView *)view;- (void)viewWillAppear;- (void)viewDidAppear;- (void)viewWillDisappear;- (void)viewDidDisappear;- (void)viewDidUnload;- (void)didReceiveMemoryWarning;@end
  17. 17. @interface YourViewController : UIViewController { id<ViewCoordinator> viewCoordinator_;}...@end
  18. 18. @implementation YourViewController- (id)initWithNibName... { viewCoordinator_ = [[MyViewCoordinator alloc] init];}- (void)loadView { [super loadView]; [self.view addSubview:[viewCoordinator_ view]];}- (void)viewWillAppear { [[viewCoordinator_ view] viewWillAppear];}...@end
  19. 19. single responsibilitya class should onlyhave one reason tochange.
  20. 20. second problem
  21. 21. they’re notsimple views
  22. 22. ListCoordinatorbasic selectioncallbacks
  23. 23. @protocol ListCoordinator- (void)onSelectListItem:^(id)block;...@end
  24. 24. @interface YourViewController : UIViewController { id<ViewCoordinator> viewCoordinator_; id<ViewCoordinator, ListViewCoordinator> listCoordinator_;}...@end
  25. 25. @implementation YourViewController- (id)initWithNibName... { listCoordinator_ = [[MyListCoordinator alloc] init]; [listCoordinator_ onSelectListItem:^(id listing) { [self showListing:listing]; }];}- (void)showListing:(Listing *)listing;{...}...@end
  26. 26. interface segregationclients should notbe forced to dependon methods theydon’t use.
  27. 27. QueryCoordinatorafter configure/cancel configurecallbacks
  28. 28. SearchBarCoord...and so on...
  29. 29. now ourstructure is morelike this...
  30. 30. Go to Xcode
  31. 31. under the hood
  32. 32. EventDispatcher
  33. 33. @interface MapCooordinator <ViewCoordinator, ListCoordinator>{ ...}@end
  34. 34. @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
  35. 35. there are nospecial cases
  36. 36. If you implementpatterns -follow your patterns
  37. 37. Coming in iOS5
  38. 38. thanks, jesse collis (@sirjec) luke cunningham (@icaruswings)

×