Download as PDF, PPTX
![DEFINE EXPRESSIVE APIS
E.g. instead of exposing details of the network layer,
provide functions with a simple interface:
func fetchAllUsers(callback: [User] -> ())
fetchAllUsers { users in
print(users)
}](https://image.slidesharecdn.com/architecture-151017203333-lva1-app6891/75/Intro-to-iOS-Application-Architecture-21-2048.jpg)
Uploaded byMake School
Intro to iOS Application Architecture
This document provides an introduction and guidelines for architecting iOS apps. It discusses goals of software architecture like comprehensible code that can adapt to changes. It recommends thinking in domains rather than objects, and following principles like single responsibility and encapsulation. Practical tips include avoiding massive view controllers, defining expressive APIs, using view objects, and being wary of inheritance. The document emphasizes dividing code into logical units with narrow interfaces to reduce dependencies.
More Related Content
Similar to Intro to iOS Application Architecture
Intro to iOS Application Architecture
- 2.
- 3. AGENDA Goals of softwarearchitecture Design guidelines Practical tips
- 4.
- 5. GOALS OF SOFTWARE ARCHITECTURE Codeis comprehensible for other developers Code can adopt to changing requirements Code can be shared within the project and throughout multiple projects
- 6. THINK IN DOMAINSNOT IN OBJECTS
- 7.
- 8. DOMAINS NOT OBJECTS Business Logic Persistence UI/UX Code Networking Reusability UserObject Trip Object User View Trip View
- 9.
- 10. SINGLE RESPONSIBILITY PRINCIPLE Avoidhaving many responsibilities within a single class Very important when implementing UIViewController subclasses Bad View Controller handles: Persistence, Business Logic, View Logic, etc.
- 11.
- 12. ENCAPSULATE Every component shouldknow as little as possible about its surrounding components → reduces dependencies between components How can this be accomplished? → small interfaces for communication
- 13. ENCAPSULATE Add Trip ViewController Core Data Client startSavingNewTrip(newTrip) displayError(nameError) setNameOfTrip(“SF Trip”) disableSaveButton() Classes are poorly encapsulated and very dependent on each other - very hard to change code in any of the two classes
- 14. ENCAPSULATE Add Trip ViewController Core Data Client saveTrip(newTrip) saveErrorOccurred(error) Small communication interface reduces dependencies!
- 15.
- 16. #1 AVOID THEMASSIVE VIEW CONTROLLER
- 17. AVOID THE MASSIVEVIEW CONTROLLER Rule of thumb: A View Controller with > 300 lines is probably doing more than it should do
- 18. THINGS A VIEWCONTROLLER SHOULD DO Listen to callbacks from the View → invoke methods on the model layer → send responses from model back to the view
- 19. THINGS A VIEWCONTROLLER SHOULD NOT DO Construct complex network requests Construct complex database queries Take care of object serialization / deserialization
- 20.
- 21. DEFINE EXPRESSIVE APIS E.g.instead of exposing details of the network layer, provide functions with a simple interface: func fetchAllUsers(callback: [User] -> ()) fetchAllUsers { users in print(users) }
- 22. #3 USE VIEWOBJECTS
- 23. USE VIEW OBJECTS Viewobjects encapsulate multiple properties that are relevant for a type to be displayed by a custom view This is preferred over setting individual properties from outside the view
- 24. USE VIEW OBJECTS classUserView: UIView { @IBOutlet var nameLabel: UILabel! @IBOutlet var profilePictureImageView: UIImageView! var user: User? { didSet { nameLabel.text = user?.name profilePictureImageView.image = user?.profilePicture } } } let userView = UserView() let currentUser = User() currentUser.name = "TestUser" userView.user = currentUser View encapsulates how an object is displayed!
- 25. USE VIEW OBJECTS classUserView: UIView { @IBOutlet var nameLabel: UILabel! @IBOutlet var profilePictureImageView: UIImageView! } let userView = UserView() let currentUser = User() currentUser.name = "TestUser" userView.nameLabel.text = currentUser.name userView.profilePictureImageView.image = currentUser.profilePicture Code that uses UserView now depends on its UI components. Violates encapsulation!
- 26. #4 BE WARYOF INHERITANCE
- 27. BE WARY OFINHERITANCE Base View Class Trip View You can only inherit one set of functionality You tend to inherit functionality that you don’t need More modular alternatives: Functions that can operate on relevant types (using generics) Protocols & Protocol Extensions
- 28. BE WARY OFINHERITANCE Base View Class Trip View More Specific Trip View Trip View Error Representable Restorable Presentable
- 29.
- 30. SUMMARY Divide code intological domains Strive for each unit of code having a single responsibility Consider using protocols instead of inheritance Define narrow and expressive APIs that hide implementation details of other units of code and reduce dependencies between your units
- 31.
- 32. ADDITIONAL RESOURCES Talk: Refactorthe Mega-Controller WWDC 2015: Protocol Oriented Programming WWDC 2014: Advanced Application Architecture Ray Wenderlich: Protocol Oriented programming