5. ANATOMY OF AN APP
• UIApplication
• AppDelegate
• App Launch Cycle
6. • Controller object that maintains app event loop
• High-level app behaviours
‣ Interace orientation changes
‣ Suspend incoming touch events
‣ Proximity sensing of user’s face
‣ etc…
• When app is launched, UIApplicationMain function is called
• One single instance of UIApplication is created
• We can call the UIApplication object through the sharedApplication class method
• UIApplicationMain is made available by importing UIKit framework
UIApplication
9. UIApplication
Practical usage
// Hide status bar when app is launched
// AppDelegate.m application:didFinishLaunchingWithOptions:
[[UIApplication sharedApplication] setStatusBarHidden:YES];
12. • Custom object created at App launch time, usually by
UIApplicationMain function
• Main purpose is to handle transitions between states (the state of
your App)
‣ Not running
‣ Inactive
‣ Active
‣ Background
‣ Suspended
AppDelegate
13. • State Transitions are usually handled by corresponding call to methods of our app delegate object
‣ application:willFinishLaunchingWithOptions:
(execute code at run time)
‣ application:didFinishLaunchingWithOptions:
(perform final initialisations before app is displayed to user)
‣ applicationDidBecomeActive:
(app becomes the foreground app)
‣ applicationWillResignActive:
(lets us know our app is transiting away from being foreground app)
‣ applicationDidEnterBackground:
(lets us know our app is running in background and may be suspended at any time)
‣ applicationWillEnterForeground:
(lets us know our app is moving out of background and back into foreground but not yet active)
‣ applicationWillTerminate:
(lets us know our app is being terminated. This method is not called if app is suspended)
AppDelegate
17. • UIApplication object
• AppDelegate
• Data model objects (and documents)
• View controller objects
• UIWindow object
• View, control and layer objects
Anatomy of an App
18. • Representation of what your app does (using custom
classes, subclass from NSObject for example)
• Spaceship game app will have Spaceship class,
TakeNotes app will have Note class, Painting app
could define a Image class
• Can subclass from UIDocument as well if we want to
define a document-based data model
• Other possibilities if using CoreData
(NSManagedObject) or Realm.io (RLMObject)
Data model objects
20. • Manages the presentation on screen
• A view controller manages a single view and
its collection of sub-views
• When presented, the view controller makes
its views visible by installing them in app’s
window
• Uses base class UIViewController
View Controller
21. • Co-ordinates presentation of one or more views on
screen
• Most apps have only one window, which presents
content on main screen; but apps may have additional
window for content displayed on external screen
• To change content of app, use view controller to
change views displayed in corresponding window.
Never replace window.
• Besides hosting views, windows work with
UIWindow object
25. • View and controls and layer objects provide the visual representation of
our app
• They are subclassed from UIView
• View: object that draws content in a designated rectangular area and
responds to events in that area.
• Controls: “special” view which implements commonly used interfaces
like buttons, text fields, toggle switches etc
• We generally use the standard classes provided by UIKit framework to
create our views and controls
• If we want to, we can subclass from UIView directly to create our
custom visual element (object)
View
26. • We can control our views from storyboard
• Storyboards allow us to set view objects we
want on a view
• Storyboards also allow us to connect view
objects to our code
View
31. Some Explanations?
@property
A declared property so the values given to that property can be set and
accessed easily
@synthesize
If we declare a property name (e.g. tView), the default setter name is _tView
(setter is where we “set” the value(s) pertaining to the tView object). So we write
@synthesize tView in our implementation file so that we can call its setter by the
same name
IBOutlet
Identifier used to identify a property so that Interface Builder can synchronise the
display and connection of outlets with Xcode.
32. Some Explanations?
@property (weak, nonatomic)
atomic versus nonatomic as property attributes
• properties are atomic by default
• this means that a value is always fully retrieved by getter method or fully set by setter
method, even if accessors are called by different threads
• we use nonatomic property attribute to specify that our synthesised accessors simply
set or return a value directly, with no guarantees about what happens to this value if
it is accessed simultaneously from different threads, so it’s usually faster to access a
nonatomic property than an atomic one and we can combine a synthesized setter
with our own getter implementation
33. Some Explanations?
@property (weak, nonatomic)
weak versus strong as property attributes
• In example diagram, XYZPerson object owns the two string properties for
firstName and lastName. firstName and lastName is available in our app’s
memory as long as XYZPerson is in the memory. In other words, they are
strongly referenced by the XYZPerson object
34. Some Explanations?
@property (weak, nonatomic)
weak versus strong as property attributes
• we use weak attribute when working with groups of
interconnected objects. In our example, the tView property
can be controlled by other logic in future, so it is not a one-way
relationship.
35. Extra Explanations
IBOutlet vs IBAction
@interface Controller
// links to TextField UI object
@property (weak, nonatomic) IBOutlet id textField;
// e.g. called when button pushed
- (IBAction)doAction:(id)sender;
