iOS$BestPrac-ces:$...Raonale:$BestPrac-ces$ • Avoid$common$mistakes$ • Consistency$ •...
Transcript of iOS$BestPrac-ces:$...Raonale:$BestPrac-ces$ • Avoid$common$mistakes$ • Consistency$ •...
iOS Best Prac-ces: Avoid the Bloat
Twi7er: @JAgostoni h7p://jason.agostoni.net
h7p://bit.ly/SportsApp
Jason Agostoni
• Sr. SoBware Architect at CEI – Lead for Integra-on and Mobile Areas
• 14+ Years in MicrosoB and Mobile PlaMorms • Apps in the App Store: – Pi7sburgh Code Camp – Sports Schedules (give me a good review?)
• h"p://bit.ly/SportsApp – Several clients’ apps
• Clients of all sizes
Challenges
• We have learned to apply best prac-ces and design pa7erns for RIA/Rich/Web apps
• Why is mobile different? – Symptom of learning on-‐the-‐side?
– Feeling that it doesn’t ma7er? – Less experienced developers?
• It may be even more important to apply best prac-ces in mobile development
DO YOU BELIEVE IN BEST PRACTICES AND DESIGN PATTERNS?
Ra-onale: Best Prac-ces
• Avoid common mistakes • Consistency • Security • Maintainability
• Etc.
WE ALL KNOW ABOUT BEST PRACTICES IN SOFTWARE DEVELOPMENT: WHY DO WE SEE THEM ONLY IN POWER POINT PRESENTATIONS? – Prakash J
Ra-onale: Design Pa7erns
• Most problems have already been solved • Easy to recognize by developers • Nearly all frameworks embrace pa7erns
• Tested over and over again • Not just reusable code but reusable ideas • Reduce implementa-on -me
Big Ball Of Mud
• Very common an--‐pa7ern in Objec-ve-‐C
• Makes code un-‐maintainable
• High code risk • Insecure • Ugly
The Ugly App
• It ain’t pre7y • It has lots of problems • It’s unmaintainable
• It’s fragile • It’s full of risk • Worst yet: It’s not atypical
• It can’t be that bad … can it?
Complexity Indicators
• More than one protocol in a class • Large number of proper-es (not a model)
• Direct references between views/controllers • Lots … and lots … of scrolling • Long list of #import statements
• Really long-‐winded methods
Problem #1: Responsibili-es
• AppDelegate has TOO many responsibili-es – Holds a reference to the Data Model – Responsible for loading the data model
– Responsible for parsing the XML – Responsible for being the AppDelegate
• Each class has to reference the delegate and has control over the data source (NSMutableArray) and can corrupt it
Solu-on: Two Pa7erns
Singleton
• Encapsulate control, life-me, scope, crea-on of an object
• Ensure only one copy of an object exists
• Perfect replacement for “global variables” in the App Delegate
• Ugly App: the data source
Single-‐Responsibility Principle • Any class should have at
most ONE purpose • A class should completely
encapsulate that purpose • A class should have only
one “reason to change” • Cohesiveness • Ugly App: Split the XML
parsing from the data model
Singleton in Objec-ve-‐C • Shared Manager
• Instance Variables
• Convenience Methods
FIX #1: SPLIT OUT THE DATA AND XML RESPONSIBILITIES
Problem #2: Class Coupling
• Too many classes have direct references • All classes rely on AppDelegate making: changes are HIGH impact
• Different views/ViewControllers refer to each other (BAD)
• Change is DIFFICULT
AppDelegate -‐ Model -‐ XML
Dash View / Controller
List View / Controller
Solu-on: Observer Pa7ern
• Model updates are coordinated through events bubbled to concerned views
• “Publisher” pushes event to a central framework – publish/subscribe
• “Observers” listen for specific events to take ac-on, data are frequently packaged in event
• No direct coupling is necessary between publishers and observers
Observer in Objec-ve-‐C
NSNoMficaMonCenter • Broadcast between objects
within an applica-on • Each NSNo-fica-on as a
name, sender and info dic-onary
• Observers use the addObserver method to route no-fica-ons to a given method/selector
• By default, no-fica-ons are routed synchronously
Observer in Objec-ve-‐C
Key-‐Value Observing
• Observers are automa-cally no-fied when a property changes on an object
• Subject must be “KVO” compliant
• Subject can be single object or collec-on
h7p://developer.apple.com/library/mac/#documenta-on/cocoa/Conceptual/KeyValueObserving/KeyValueObserving.html
FIX #2: DECOUPLE THE VIEWS USING AN OBSERVER PATTERN
Improvements
• Using these design pa7erns: – The applica-on is more maintainable – Code risk is greatly reduced – The code is easy to follow and understand – There is less impact to change
• Other Developers will appreciate it – The code is intui-ve – The design pa7erns are recognizable
Built-‐in Design Pa7erns
• Model View Controller – Presenta-on pa7ern na-ve within CocoaTouch
• Category – Provides ability to extend func-onality of a class without subclassing
• Delega-on (Protocols) – Same as interfaces in other languages
• Proxy (NSProxy) – Stand-‐in object which forwards calls to another object
• Factory – Object which creates other objects
– Interes-ng in Objec-ve-‐C where the Classes themselves have factories
Resources
• Books – Cocoa Design Pa7erns Buck, Yacktman Addison Wesley
– Pro Objec-ve-‐C Design Pa7erns Carlo Chung Apress
• Online – My Blog
h7p://jason.agostoni.net
– Objec-ve-‐C Design Pa7erns h7p://www.informit.com/ar-cles/ar-cle.aspx?p=1566875
– Wikipedia • Has some good examples in the general design pa7ern pages
Thanks!
• Twi7er: @JAgostoni • Blog: h7p://jason.agostoni.net
• Sports Schedules: h7p://bit.ly/SportsApp
• Code samples: h7ps://github.com/JAgostoni/iOS-‐Best-‐Prac-ces