INTRODUCTION TO ARCHITECTING YOUR IOS APP

Transcription

1

2 INTRODUCTION TO ARCHITECTING YOUR IOS APP

3 AGENDA Goals of software architecture Design guidelines Practical tips

4 GOALS OF SOFTWARE ARCHITECTURE

5 GOALS OF SOFTWARE ARCHITECTURE Code is comprehensible for other developers Code can adopt to changing requirements Code can be shared within the project and throughout multiple projects

6 THINK IN DOMAINS NOT IN OBJECTS

7 DOMAINS NOT OBJECTS Reusability Business Logic UI/UX Code Persistence Networking User Object Trip Object

8 DOMAINS NOT OBJECTS Reusability Business Logic UI/UX Code Persistence Networking User Object User View Trip Object Trip View

9 SINGLE RESPONSIBILITY PRINCIPLE

10 SINGLE RESPONSIBILITY PRINCIPLE Avoid having many responsibilities within a single class Very important when implementing UIViewController subclasses Bad View Controller handles: Persistence, Business Logic, View Logic, etc.

11 ENCAPSULATE

12 ENCAPSULATE Every component should know as little as possible about its surrounding components reduces dependencies between components How can this be accomplished? small interfaces for communication

13 ENCAPSULATE startsavingnewtrip(newtrip) setnameoftrip( SF Trip ) Add Trip View Controller displayerror(nameerror) Core Data Client disablesavebutton() Classes are poorly encapsulated and very dependent on each other - very hard to change code in any of the two classes

14 ENCAPSULATE savetrip(newtrip) Add Trip View Controller Core Data Client saveerroroccurred(error) Small communication interface reduces dependencies!

15 PRACTICAL TIPS

16 #1 AVOID THE MASSIVE VIEW CONTROLLER

17 AVOID THE MASSIVE VIEW CONTROLLER Rule of thumb: A View Controller with > 300 lines is probably doing more than it should do

18 THINGS A VIEW CONTROLLER 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 VIEW CONTROLLER SHOULD NOT DO Construct complex network requests Construct complex database queries Take care of object serialization / deserialization

20 #2 DEFINE EXPRESSIVE APIS

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 VIEW OBJECTS

23 USE VIEW OBJECTS View objects 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 class UserView: UIView var namelabel: var profilepictureimageview: UIImageView! var user: User? { didset { namelabel.text = user?.name profilepictureimageview.image = user?.profilepicture } } } let userview = UserView() let currentuser = User() currentuser.name = "TestUser" View encapsulates how an object is displayed! userview.user = currentuser

25 USE VIEW OBJECTS class UserView: UIView var namelabel: var profilepictureimageview: UIImageView! } let userview = UserView() let currentuser = User() currentuser.name = "TestUser" Code that uses UserView now depends on its UI components. Violates encapsulation! userview.namelabel.text = currentuser.name userview.profilepictureimageview.image = currentuser.profilepicture

26 #4 BE WARY OF INHERITANCE

27 BE WARY OF INHERITANCE You can only inherit one set of functionality Base View You tend to inherit functionality that you don t need Class More modular alternatives: Functions that can operate on relevant types Trip View (using generics) Protocols & Protocol Extensions

28 BE WARY OF INHERITANCE Base View Class Error Representable Restorable Presentable Trip View More Specific Trip View Trip View

29 SUMMARY

30 SUMMARY Divide code into logical 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 ADDITIONAL RESOURCES

32 ADDITIONAL RESOURCES Talk: Refactor the Mega-Controller WWDC 2015: Protocol Oriented Programming WWDC 2014: Advanced Application Architecture Ray Wenderlich: Protocol Oriented programming