Main iOS Architecture and Patterns

Main iOS Architecture and Patterns

The following design patterns are present in many of apple's iOS frameworks:

1. Target-Action: Can be used to connect a UI control to an implementation of what it does upon being activated by the user.  You can see this pattern in Storyboards when dragging from a control to the code and creating an "Action". Even if your UI classes come from different parents, for example: UIBarButtonItem vs UIButton, they still both use the Target-Action mechanism to handle their pressed events.  The same target-action mechanism is used by gesture recognizers.  A message is also sent along with the action to the target. 


2. Responder-Chain:  Lets your application handle events without knowing which particular object will handle them. An initiator kicks off an action to the first responder.  That responder may or may not respond to it, or forward it on to the next responder. Typical responder chain (Default view hierarchy):  View-->ViewController-->Window-->Applicastion-->AppDelegate. 


3.  Composite: Manipulate a group of objects as a single object.  Example: create two views: A and B.  Add B as a subview to A. Now manipulating A will also operate on B, because B is inside A's composite.  Now also B's nextResponder is A, because that is its super view.  UIDynamicBehavior is another place where the same pattern is found: a child behaviour can be added to your dynamicBehavior.  Now the physics simulation running in the background will manipulate the parent dynamicBehavior object as a composite, affecting all nested behaviors inside (nested tree) as one object. 


4. Delegation: Customize behavior without subclassing the customized object.  For example: UIApplication --> UIApplicationDelegate.   The App Delegate specifies behaviour for various methods of your application.  The app delegate doesn't have to know anything else about the UIApplication.  It only needs to know how to react to 7 application life cycle events.  If you had to override UIApplication instead of receiving it's delegated events, you would have to understand how UIApplication works:  
1. Which methods must you override?
2. Which methods are optional?
3. Do you have to call super on overridden methods?

Other examples of Delegates:
AVAssetResourceLoader --> AVAssetResourceLoaderDelegate
CALayer --> CALayerDelegate
GKSession --> GKSessionDelegate 


5. Data Source: Customize the data retrieval without having to subclass the object that needs the data.  Example:  UITableView --> UITableViewDataSource.  The tableView asks you for things that it needs from the data source, such as: number of rows, number of sections, view for row, etc.  Other examples: 
1. UICollectionView --> UICollectionViewDataSource
2. UIPageViewController --> UIPageViewControllerDataSource
3. UIPickerView --> UIPickerViewDataSource


6. Model-View-Controller:  Build organizational structure around application's responsibilities. The model is your business data definition, and possibly functionality related to that particular entity.  The view is your UI which fires events to perform certain actions.  The controller handles the View's actions, reads models, returns data to Views, and does everything else necessary to allow the View to do its job, and update the models accordingly. 

The below steps are a good general process when building a simple application: 

1. The Human Interface Guideline

https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/

Should use this as a guide when designing an application. 

2. Application Definition Statement

Important to come up with a focused application statement.  It's a 30 second elevator pitch of exactly what the application is and who it's for.  For example:  "Allow people to share simple, short updates about what is happening in their lives".  The come up with a list of features that are likely to be used.  In this case:  Networked, Lists of data, Good performance, Add an entry, Add photos, Mark items, Edit posts.  Then figure out what to say No to.   So according to our above application statement, we would drop the following 3:  Add photos, Mark items and Edit posts, because they do not fit into the statement. 

3. Come up with simple wire-frames of all screens. 

This will help visualize layout, content, models and ui controls needed.

4. Define Models

Based on the user story statements, pull out the nouns, and that will likely tell you what models will be used. 

5. Define Views

For example:  Use a tableview. Have table view cells with wrappable text fields and images.  Use UIBarButtonItem to display the + button in the Top right, to create an entry. 

6. Define ViewController

Most likely our View Controller will serve as a data source to our table view.  It will also have actions, such as the "add new entry".  In a simple example, VC also has to manage the networking, such as using NSURLConnection, to retrieve model data, and expose it to the views.  However, ideally we don't want the VC to know anything about the networking layer, and instead use a Query object to retrieve the data.