The document summarizes goals and concepts for iOS development, including: 1. It discusses using common iOS UI elements like text fields, labels, sliders and switches, and handling actionsheets and alerts. 2. It explains application delegates and how they handle events on behalf of other objects. The UIApplication delegate is discussed. 3. It provides an overview of view controllers and their role in linking an app's data and visual interface, and describes their life cycle and common methods. 4. Automatic Reference Counting (ARC) is introduced as replacing the need to manually manage memory by releasing objects.

1. iOS Development (Part II)
COMPILED BY: ASIM RAIS SIDDIQUI

2. Goals of the Lecture
 Use of TextField, Label, Sliders and Switch buttons
 Handling ActionSheet and Alerts
 Application Delegates
 Handling ActionSheet and Alerts
 Application Delegates
 UIApplication Delegates
 View Controllers
 Life Cycle of Application & Methods
 ARC

3. Application Delegate
 A delegate is an object that acts on behalf of, or in coordination
with, another object when that object encounters an event in a
program. The delegating object is often a responder object—that is,
an object inheriting from NSResponder in AppKit or UIResponder in
UIKit—that is responding to a user event. The delegate is an object
that is delegated control of the user interface for that event, or is at
least asked to interpret the event in an application-specific manner.
 These objects are designed to fulfill a specific role in a generic
fashion; a window object in the AppKit framework, for example,
responds to mouse manipulations of its controls and handles such
things as closing, resizing, and moving the physical window.

4. UIApplication & Delegates

5. View Controllers
View controllers are a vital link
between an app’s data and its visual
appearance. Whenever an iOS app
displays a user interface, the
displayed content is managed by a
view controller or a group of view
controllers coordinating with each
other. Therefore, view controllers
provide the skeletal framework on
which you build your apps.
iOS provides many built-in view
controller classes to support standard
user interface pieces, such as
navigation and tab bars. As part of
developing an app, you also
implement one or more custom
controllers to display the content
specific to your app.

6. Life Cycle &
Methods

7. Note:
 When Apple switched the default compiler from GCC to LLVM
recently, it stopped being necessary to declare instance variables
for properties. If LLVM finds a property without a matching instance
variable, it will create one automatically.

8. ARC
 Automatic Reference Counting (ARC) is a new feature of the
Objective-C language, introduced with iOS 5, that makes your life
much easier.
 It’s no longer necessary to release objects. Well, that’s not entirely true.
It is necessary, but the LLVM 3.0 compiler that Apple started shipping
with iOS 5 is so smart that it will release objects for us, using a new
feature called Automatic Reference Counting, or ARC, to do the heavy
lifting. That means no more dealloc methods, and no more worrying
about calling release or autorelease.
 ARC is very cool, but it’s not magic. You should still understand the basic
rules of memory management in Objective-C to avoid getting in
trouble with ARC. To brush up on the Objective-C memory
management contract, read Apple’s Memory Management
Programming Guide at this URL:
 https://developer.apple.com/library/ios/#documentation/Cocoa/Con
cep tual/MemoryMgmt/

9. Subclassing
 It is an important feature of any object-oriented programming
environment and the iPhone SDK is no exception to this rule. Subclassing
allows us to create a new class by deriving from an existing class and then
extending the functionality. In so doing we get all the functionality of the
parent class combined with the ability to extend the new class with
additional methods and properties.

10. Subclassing
@interface Superclass : NSObject {
int v;
}
- (void)initV;
@end
@implementation Superclass
- (void)initV {
v = 20;
}
@end
@interface Subclass : Superclass {
int w;
}
- (void)displayVars;
@end
@implementation Subclass
- (void)initW {
w = 50;
}
- (void)displayVars {
NSLog(@"v is %d, w is %d", v, w);
}
@end

11. Subclassing
int main(int argc, char *argv[]) {
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
Subclass *sub = [[Subclass alloc] init];
[sub initV]; // Inherited method & ivar
[sub initW]; // Own method & ivar
[sub displayVars];// Inherited method [sub release];
[pool drain];
return 0;
}
Output:
v is 20, w is 50

12. Action Sheet and Alert
 Action sheets are used to force the user to make a choice between
two or more items. The action sheet comes up from the bottom of
the screen and displays a series of buttons. Users are unable to
continue using the application until they have tapped one of the
buttons. Action sheets are often used to confirm a potentially
dangerous or irreversible action such as deleting an object.
 Alerts appear as a blue, rounded rectangle in the middle of the
screen. Just like action sheets, alerts force users to respond before
they are allowed to continue using the application. Alerts are usually
used to inform the user that something important or out of the
ordinary has occurred. Unlike action sheets, alerts may be
presented with only a single button, although you have the option
of presenting multiple buttons if more than one response is
appropriate.

13. Conforming to the Action Sheet
Delegate Method
 In order for our controller class to act as the delegate for an action
sheet, it needs to conform to a protocol called
UIActionSheetDelegate.
 @interface BIDViewController : UIViewController
<UIActionSheetDelegate>
 Other parameter allow you to add more buttons
 E.g otherButtonTitles:@"Foo", @"Bar", nil

14. Switching Views
 presentModalViewController and presentViewController
 Other different techniques to switch views
 - view overlapping
 - navigation controller

15. Navigation Controller
 The main tool you’ll use to build hierarchical applications
is UINavigationController. UINavigationController is similar
to UITabBarController in that it manages, and swaps in
and out, multiple content views. The main difference
between the two is that UINavigationController is
implemented as a stack, which makes it well suited to
working with hierarchies.
 A stack is a commonly used data structure that works on
the principle of last in, first out.

16. Stack
 A computer stack follows the same rules:
 When you add an object to a stack, it’s called a push. You push an
object onto the stack.
 The first object you push onto the stack is called the base of the
stack.
 The last object you pushed onto the stack is called the top of the
stack
 (at least until it is replaced by the next object you push onto the stack).
 When you remove an object from the stack, it’s called a pop.
When you pop an object off the stack, it’s always the last one you
pushed onto the stack. Conversely, the first object you push onto the
stack will always be the last one you pop off the stack.

17. Setting Up the Navigation Controller
 Add property in main app delegate file
@property (strong, nonatomic) UINavigationController *navController;
Then implement
self.navController = [[UINavigationController alloc]
initWithRootViewController:self.viewController];
User push or pop, when needed:
[self.navigationController pushViewController:foo animated:YES];

18. TableViews
 First, what’s a Table View in iPhone app? Table View is one of the
common UI elements in iOS apps. Most apps, in some ways, make
use of Table View to display list of data.
 The best example is the built-in Phone app. Your contacts are
displayed in a Table View.
 Another example is the Mail app. It uses Table View to display your
mail boxes and emails. Not only designed for showing textual data,
Table View allows you to present the data in the form of images. The
built-in Video and YouTube app are great examples for the usage.

19. UITableViewDelegate and
UITableViewDataSource
 The UITableView, the actual class behind the Table View, is designed to be
flexible to handle various types of data. You may display a list of countries or
contact names. Or like this example, we’ll use the table view to present a list of
recipes. So how do you tell UITableView the list of data to display?
UITableViewDataSource is the answer. It’s the link between your data and the
table view. The UITableViewDataSource protocol declares two required
methods (tableView:cellForRowAtIndexPath and
tableView:numberOfRowsInSection) that you have to implement. Through
implementing these methods, you tell Table View how many rows to display and
the data in each row.
 UITableViewDelegate, on the other hand, deals with the appearance of the
UITableView. Optional methods of the protocols let you manage the height of a
table row, configure section headings and footers, re-order table cells, etc. We
do not change any of these methods in this example. Let’s leave them for the
next tutorial.

20.  numberOfSectionsInTableView
 numberOfRowsInSection
 cellForRowAtIndexPath
 didSelectRowAtIndexPath

21. Tab Bar App
 No more windows.xib file
 Add ThirdViewController subclassing UIViewController
 Add DetailViewController subclassing UIViewController
 #import "ThirdViewController.h"
 Create new class object
 ThirdViewController *navController = [[ThirdViewController alloc] initWithNibName:@"ThirdViewController" bundle:nil];
 Create Navigation instance
 UINavigationController *nav=[[UINavigationController alloc] initWithRootViewController:navController];

22. @class Directive
 The @class directive sets up a forward reference to another class. It
tells the compiler that the named class exists, so when the compiler
gets to, say an @property directive line, no additional information is
needed, it assumes all is well and plows ahead.

23. @Classs
Vs
#Import