This document provides an overview of the anatomy of an iOS application. It discusses the key components including the UIApplication object, which maintains the app's event loop. The AppDelegate handles state transitions like launching and becoming active. View controllers manage views and their presentation. Data model objects represent app data. The UIWindow displays content and views provide visual representation. It also covers view controller code examples and different app templates like single view, tabbed, and master-detail apps.

1. UNDERSTANDING
iOS Specifics

2. OVERVIEW
• Lesson 1: Introductions
• Lesson 2: iOS specifics
• Lesson 3: Data Model
• Lesson 4: Logic (Controller) & Interface

3. LESSON 2: IOS SPECIFICS
• Hour 1: Anatomy of an App
• Hour 2: View
• Hour 3: Different types of applications with
Xcode

4. ANATOMY OF AN APP

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

7. UIApplication
main.m

8. UIApplication
Access UIApplication from anywhere
UIApplication *application;
application = [UIApplication sharedApplication];

9. UIApplication
Practical usage
// Hide status bar when app is launched
// AppDelegate.m application:didFinishLaunchingWithOptions:
[[UIApplication sharedApplication] setStatusBarHidden:YES];

10. UIApplication
TakeNotes-Info.plist

11. UIApplication
TakeNotes-Info.plist

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

14. App Launch Cycle

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

19. ANATOMY OF AN APP

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

22. UIWindow object

23. ANATOMY OF AN APP
UIWindow

24. ANATOMY OF AN APP
View

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

27. View

28. View Controller
DetailViewController.h
@property (weak, nonatomic) IBOutlet UITextView *tView;
DetailViewController.m
@synthesize tView;
- (void)configureView
{
// Update the user interface for the detail item.
if (self.detailItem) {
self.tView.text = [self.detailItem description];
}
}

29. View to View Controller

30. View to View Controller

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;

36. Different App Templates

37. • Master-Detail Application
• Tabbed Application
• OpenGL Game
• Utility Application
• Page-based Application
• Single View Application
• SpriteKit Game
• Empty Application
Different App Templates

38. Master-Detail App

39. Tabbed App

40. OpenGL Game App

41. Utility App

42. Page-based App

43. Single View App

44. SpriteKit Game App

45. Empty App

46. WHAT’S NEXT
• Lesson 1: Introductions
• Lesson 2: iOS specifics
• Lesson 3: Data Model
• Lesson 4: Logic (Controller) & Interface