ios beginners lesson 2

UNDERSTANDINGiOS Specifics

OVERVIEW

• Lesson 1: Introductions

• Lesson 2: iOS specifics

• Lesson 3: Data Model

• Lesson 4: Logic (Controller) & Interface

LESSON 2: IOS SPECIFICS

• Hour 1: Anatomy of an App

• Hour 2: View

• Hour 3: Different types of applications with Xcode

ANATOMY OF AN APP

ANATOMY OF AN APP

• UIApplication

• AppDelegate

• App Launch Cycle

• 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

UIApplicationmain.m

UIApplicationAccess UIApplication from anywhere

UIApplication *application;

application = [UIApplication sharedApplication];

UIApplicationPractical usage

// Hide status bar when app is launched

// AppDelegate.m application:didFinishLaunchingWithOptions:

[[UIApplication sharedApplication] setStatusBarHidden:YES];

UIApplicationTakeNotes-Info.plist

UIApplicationTakeNotes-Info.plist

• 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

• 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

App Launch Cycle

• UIApplication object

• AppDelegate

• Data model objects (and documents)

• View controller objects

• UIWindow object

• View, control and layer objects

Anatomy of an App

• 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

ANATOMY OF AN APP

• 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

• 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 UIApplication object to deliver events to views and view controllers

UIWindow object

UIWindow object

ANATOMY OF AN APP

UIWindow

ANATOMY OF AN APP

View

• 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

• 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

View

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]; }}

View to View Controller

View to View Controller

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.

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

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

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.

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;

Different App Templates

• Master-Detail Application

• Tabbed Application

• OpenGL Game

• Utility Application

• Page-based Application

• Single View Application

• SpriteKit Game

• Empty Application

Different App Templates

Master-Detail App

Tabbed App

OpenGL Game App

Utility App

Page-based App

Single View App

SpriteKit Game App

Empty App

WHAT’S NEXT

• Lesson 1: Introductions

• Lesson 2: iOS specifics

• Lesson 3: Data Model

• Lesson 4: Logic (Controller) & Interface