A Second Project

Last day, we began a second iPhone project. We selected a single view application
We gave the project a name MyButtonApp, and under class prefix used (MFA -- My First-real App or Master's Fine Arts).
We mentioned that iOS program typically use the Model View Controller design pattern, and the controller is where we specify what actions to take to process events like buttons being pushed etc.

If we look in the Navigator-View pane at the controller class created for us, the header might look like:

//
//  MFAViewController.h
//  MyButtonApp
//
//  Created by Chris Pollett on 9/10/14.
//  Copyright (c) 2014 Chris Pollett. All rights reserved.
//

#import <UIKit/UIKit.h>

@interface MFAViewController : UIViewController

@end

UIViewController is a generic controller class that is part of UIKit.

If we look at the implementation file it comes with a bunch of boilerplate functions which can be safely removed for this project to get:

//
//  MFAViewController.m
//  MyButtonApp
//
//  Created by Chris Pollett on 9/10/14.
//  Copyright (c) 2014 Chris Pollett. All rights reserved.
//

#import "MFAViewController.h"

@interface MFAViewController ()

@end

@implementation MFAViewController

@end

The Interface

Next, we can use Interface Builder to layout our two buttons and our label; we will use this class to implement the control for the buttons. To start click on the Main_iphone.storyboard.
Recall to show the object library of things we can drag to out storyboard using: View: Utilities : Show Object Library.
In the little search bar at the bottom we can type UIButton to just search for the item we want to drag out.
Let's drag out two buttons.
Now so get the top left pane in XCode to show the Attribute Inspector, we can go to View : Utilities: Show Attribute Inspector.
Using the attribute inspector we can change the text of the two buttons to Left and Right.
Finally, from the object library let's also drag out a Label, resize it so its the width of the screen, and then using the attribute inspector center its text.
So now the storyboard should look like:

Actions and Outlets

Our controller can refer to objects in the storyboard using an instance variable called an outlet.
For example, to control the text label, we might declare an outlet and point it at the label object.
In the opposite direction, interface objects in our storyboard can be set to trigger special methods in our controller class.
These special methods are called action methods.

To declare an action and outlet in our interface file we might have:

#import <UIKit/UIKit.h>
@interface MFAViewController : UIViewController
@property (weak, nonatomic) IBOutlet UILabel *statusLabel;
-(IBAction)buttonPressed:(UIButton *)sender;
@end

The syntax above has actually evolved since earlier versions of iOS. The book (and older versions of this class' notes can be used as a guide if you have to deal with old code).
IBOutlet is not a keyword in Objective-C or a class, it a C Preprocessor #define and is used as a marker to alert the Interface Builder that this is something that we can connect to from the storyboard. Literally, it looks like:
```
#ifndef IBOutlet
#define IBOutlet
#endif
```
You can actually get Interface Builder to help you to auto-generate this code (or at least a simplified modern version of it): You first drag a label onto your view. Switch to assistant view so that you have your code in a right panel then CTRL-click on your label and drag to the interface portion of your code. You would do a similar thing for the buttonPressed code.
Let me just say that the @property declaration is a shorthand... It tells the compiler we want to make an assessor (getter) and mutator (setter) method for statusLabel. i.e., we want to create a method -(id) statusLabel to get this instance variable; and a method -(void) setStatusLabel: (id) aStatusLabel to set it.
weak tells the compiler about that we don't want to become the owner of the object, so ARC doesn't need to generate a retain to bump up the reference count.
nonatomic says that the compiler shouldn't generate any extra code for the accessors and mutators which might be needed in a multi-threaded environment.

You often refer to properties using dot notation in Objective-C. i.e.,

  UILabel *tmp = myController.statusText;
  myController.statusText = someLabel;

Other Possible Action Method Prototypes

-(IBAction) buttonPressed:(id)sender; is one of three possible prototype selectors for actions.

The possibilities are:

-(IBAction) actionMethod;
-(IBAction) actionMethod:(id)sender;
-(IBAction) actionMethod:(id)sender withEvent:(UIEvent *)event;

Implementing Our Properties and our Action

Adding code for our buttonPress makes our implementation file look like:

//
//  MFAViewController.m
//  MyButtonApp
//
//  Created by Chris Pollett on 9/10/14.
//  Copyright (c) 2014 Chris Pollett. All rights reserved.
//
#import "MFAViewController.h"

@interface MFAViewController ()

@end

@implementation MFAViewController

-(IBAction)buttonPressed:(UIButton *)sender
{
	NSString *title = [sender titleForState:(UIControlState)UIControlStateNormal];
	NSString *newText = [NSString stringWithFormat:@"%@ button pressed.",title];
	_statusLabel.text = newText;
}
@end

Some remarks

The titleForState: selector of the UIButton takes as argument a control state. This can be one of normal, highlighted, disabled, or selected. Each might have different text. UIControlStateNormal corresponds to the normal state, which is what the text of all states defaults to unless you specifically set it.
This is the first time we have created an NSString and sent it a message: [NSString stringWithFormat:@"%@ button pressed.",title]
Notice we are using the dot notation we mentioned for properties a couple slides back: _statusLabel.text = newText;
Also notice, we have to have an underscore before statusLabel when we declare it as a property in this way. (In older code, we would have used @synthesize and wouldn't need this.)

Connecting Outlets and Action with UI

Go back to Assistant view with Interface Builder (IB) in the left pane and the controller implementation file on the right.
From the CTRL-click on label and drag to the line @property (weak, nonatomic) IBOutlet UILabel *statusLabel; in the header.
Similarly, CTRL-click on each button and drag to the buttonPressed method in the header.
That's all now these times are connected.

Connections Inspector

ATo see what UI element is connected to what code, is to use the Connection Inspector.
Then open the Connection Inspector under View - Utilities.
If we click on the statusLabel in the storyboard we'd see
Click on a button in the sotryboard might look like:
Notice there are a bunch of different triggers one could respond to. We are interested in Touch Up Inside. This happens for a button when someone touches the screen and releases inside the button on the screen.
Another way to connect this with our controller would be to click on the circle next to this trigger and drag it to the IB First Responder Icon. It will give a list of actions we can connect with. We choose buttonPressed.

Button App Simulator Screenshot

That's it for our app! To test it out, we save the files and run the project.
If you don't like the font, font-size of the label text, how it wraps, etc... Remember you can always go to Tools in IB to change these!

Adding Images

Let's talk about adding images to projects, as its part of HW1.
To do this, we can first create a PNG image and add it to the Resources of our project.
Then we can add an Image View (this corresponds to an UIImageView object) to our interface in IB.
Then in Inspector we can look at the Image View and set its Image attribute to be the png file we added.

Your Homework

So far we have only seen how to create an App with one View.
This is all you need for this homework...We will say how to create multiview apps later
We know how to switch a label for each screen now based on buttons clicked.
We would also like to make a background image that changes.
It is possible to make an IBOutlet for an UIImageView object. Such an object has an image property which can be set programmatically with a UImage object.
Suppose you have a image resource bob.png. You can create a UImage object with this images using:
```
UIImage *bob = [UIImage imageNamed:@"bob.png"];
```

Delegation

In Java when we create applications/applets, etc we tend to subclass some class and override methods to add functionality.
In Cocoa Touch programming, our applications will be UIApplication objects, which are part of UIKit.
You can see UIApplication being instantiated in Supporting Files - main.m
To change the functionality of the application, we modify application delegate classes.
The idea is that UIApplication has a number of delegate objects on it (which ones are set by you.) When it needs to perform some operation it calls methods of these delegates.

An example of a delegate in our project is MFAAppDelegate. The .h file for it looks like:

//
//  MFAAppDelegate.h
//  MyButtonApp
//
//  Created by Chris Pollett on 9/10/14.
//  Copyright (c) 2014 Chris Pollett. All rights reserved.
//

#import <UIKit/UIKit.h>

@interface MFAAppDelegate : UIResponder <UIApplicationDelegate>

@property (strong, nonatomic) UIWindow *window;

@end

The above says we extend UIResponder that conforms to UIApplicationDelegate protocol (we'll describe protocols in a moment).
If you wanted to find out more about this protocol you can access the quick help by option clicking on the item in the code.
At certain predefined places in our apps lifecycle it will can methods of this delegate. For example, just before the program quits it will call applicationWillTerminate

If you look at the .m file for it, you can see all the methods that can be overriden at different place in the app lifecycle:

#import "MFAAppDelegate.h"

@implementation MFAAppDelegate

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    // Override point for customization after application launch.
    return YES;
}
							
- (void)applicationWillResignActive:(UIApplication *)application
{
    // Sent when the application is about to move from active to inactive state. This can occur for certain types of temporary interruptions (such as an incoming phone call or SMS message) or when the user quits the application and it begins the transition to the background state.
    // Use this method to pause ongoing tasks, disable timers, and throttle down OpenGL ES frame rates. Games should use this method to pause the game.
}

- (void)applicationDidEnterBackground:(UIApplication *)application
{
    // Use this method to release shared resources, save user data, invalidate timers, and store enough application state information to restore your application to its current state in case it is terminated later. 
    // If your application supports background execution, this method is called instead of applicationWillTerminate: when the user quits.
}

- (void)applicationWillEnterForeground:(UIApplication *)application
{
    // Called as part of the transition from the background to the inactive state; here you can undo many of the changes made on entering the background.
}

- (void)applicationDidBecomeActive:(UIApplication *)application
{
    // Restart any tasks that were paused (or not yet started) while the application was inactive. If the application was previously in the background, optionally refresh the user interface.
}

- (void)applicationWillTerminate:(UIApplication *)application
{
    // Called when the application is about to terminate. Save data if appropriate. See also applicationDidEnterBackground:.
}

@end

Auto-release Pools

Traditionally, you can autorelease at the end of a method that creates an object for use by another object. This drops your retain on an object after the receiver of the object calls retain on it.

In main.m we see portion of how this mechanism works:

    @autoreleasepool {
        return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
    }

Here @autoreleasepool is syntactic sugar that is pre-compiled to something like what the older sdk had:

    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
    int retVal = UIApplicationMain(argc, argv, nil, nil);
    [pool release];

The first line creates an autorelease pool. This you can think of as a data structure that keeps track of objects that have been autoreleased.
This says that when you create an object in our application to use this pool. So for an object you can create it, use it, and call [myObj autorelease];
As we said above, this does not immediately drop the reference count of the object by 1.
Instead, it adds to a counter associated with myObj reference in pool.
When pool is released each object that pool was managing has is reference count reduced by its associated counter value.

Protocols

The MyButtonAppDelegate .h file also illustrates another feature of Objective-C, Protocols. The declaration
```
@interface MyButtonAppDelegate : UIResponder <UIApplicationDelegate> 
```
says we are extending NSObject and implementing the UIApplicationDelegate protocol.
Protocols in Objective-C are like Java interfaces.

You can declare a protocol with a syntax like:

@protocol MyInterface
-(void) myMethod;
@end;

To implement more than one protocol just separate each protocol by commas: < P1, P2, ...>

Inheritance

Notice to declare new classes we use @interface. For an @interface, we must implement each method.
Once a class is declared and implemented in this way it can be extended by a subclass.
Protocols can be declared. The name of the protocol exists without an @implementation for that name. Subclasses using the protocol promise to implement the protocol's method.
Like in Java, a subclass can extend only one class but can implement many protocols.
Like in Java, giving a new implementation of a function from the base class serves to override the function from the base class in the subclass.

Faking private variables

Objective-C doesn't directly have a notion of private variables like C++ or Java
Nevertheless you can use categories to achieve a similar effect.
To start suppose we have a class AClass whose header is AClass.h:
```
@interface AClass 
-(void) aMethod;
@end
```

Now in the implementation AClass.m file of AClass, we also give the interface and implementation of a categore involving AClass:

#import "AClass.h"
@interface AClass (Private)
-(void) niftyMethod;
@end
@implement AClass 
-(void) aMethod {
  //some code, could call nifty Method
}
@end
@implement AClass (Private)
-(void) niftyMethod {
   // some code
}
@end

Now if we use AClass elsewhere we would typically import the AClass.h header which has no mention of the AClass(Private) category, so in

#import "AClass.h"

int main( int argc, const char *argv[] ) {
   AClass *aClass = [[AClass alloc] init];
   // could not call [aClass niftyMethod];
}

Actions, Outlets, UI Elements, More Objective-C

Outline