INTRODUCTION TO ARCHITECTING YOUR IOS APP · Practical tips. GOALS OF SOFTWARE ARCHITECTURE. GOALS...

Preview:

Citation preview

INTRODUCTION TO ARCHITECTING YOUR IOS APP

AGENDA

Goals of software architecture

Design guidelines

Practical tips

GOALS OF SOFTWARE ARCHITECTURE

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

THINK IN DOMAINS NOT IN OBJECTS

DOMAINS NOT OBJECTS

Business Logic

PersistenceUI/UX Code

NetworkingReusability

User Object

Trip Object

DOMAINS NOT OBJECTS

Business Logic

Persistence

UI/UX Code

Networking

Reusability

User Object

Trip Object

User View

Trip View

SINGLE RESPONSIBILITY PRINCIPLE

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.

ENCAPSULATE

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

ENCAPSULATE

Add Trip View Controller 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

ENCAPSULATE

Add Trip View Controller Core Data Client

saveTrip(newTrip)

saveErrorOccurred(error)

Small communication interface reduces dependencies!

PRACTICAL TIPS

#1 AVOID THE MASSIVE VIEW CONTROLLER

AVOID THE MASSIVE VIEW CONTROLLER

Rule of thumb: A View Controller with > 300 lines is

probably doing more than it should do

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

THINGS A VIEW CONTROLLER SHOULD NOT DO

Construct complex network requests

Construct complex database queries

Take care of object serialization / deserialization

#2 DEFINE EXPRESSIVE APIS

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)}

#3 USE VIEW OBJECTS

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

USE VIEW OBJECTSclass UserView: 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!

USE VIEW OBJECTS

class UserView: UIView {

@IBOutlet var nameLabel: UILabel! @IBOutlet var profilePictureImageView: UIImageView! }

let userView = UserView()let currentUser = User()currentUser.name = "TestUser"

userView.nameLabel.text = currentUser.nameuserView.profilePictureImageView.image = currentUser.profilePicture

Code that uses UserView nowdepends on its UI components.Violates encapsulation!

#4 BE WARY OF INHERITANCE

BE WARY OF INHERITANCE

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

BE WARY OF INHERITANCE

Base View Class

Trip View

More Specific Trip View

Trip View

ErrorRepresentable

Restorable Presentable

SUMMARY

SUMMARYDivide 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

ADDITIONAL RESOURCES

ADDITIONAL RESOURCES

Talk: Refactor the Mega-Controller

WWDC 2015: Protocol Oriented Programming

WWDC 2014: Advanced Application Architecture

Ray Wenderlich: Protocol Oriented programming

Recommended