Actions, Outlets, UI Elements, More Objective-C

CS185c

Chris Pollett

Sep. 8, 2010

Outline

Adding Outlets and Actions to a header
Implementing Outlets and Actions
Connecting Outlets and Actions with a nib file
Adding Images to Views
Comments on HW1
More on how iPhone apps work
More on Objective-C

A Second Project

If we look in the Group & Files pane at the controller class created for us, it might look like:

//
//  SecondProjectViewController.h
//  SecondProject
//
//  Created by Chris Pollett on 8/26/09.
//  Copyright San Jose State University 2009. All rights reserved.
//

#import <UIKit/UIKit.h>

@interface SecondProjectViewController : UIViewController {

}

@end

UIViewController is a generic controller class that is part of UIKit.
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.
Our controller can refer to objects in the nib file 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 nib file can be set to trigger special methods in our controller class.
These special methods are called action methods.

Declaring Actions and Interfaces in Our Header

To declare an action and interface we might do:

#import <UIKit/UIKit.h>

@interface SecondProjectViewController : UIViewController {
   IBOutlet UILabel *statusText;
}
@property (retain, nonatomic) UILabel *statusText;

-(IBAction) buttonPressed:(id)sender;

@end

We will continue with our project next day...
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 statusText. i.e., we want to create a method -(id) statusText to get this instance variable; and a method -(void) setStatusText: (id) aStatusText to set it.
retain tells the compiler to send a retain message to any object we assign this property.
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;
  muController.statusText = someLabel;

IBOutlet is a preprocessor directive that does nothing as far compilation.
```
#ifndef IBOutlet
#define IBOutlet
#endif
```
It is used as a marker by interface builder though when it looks at a header file.

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

Our implementation file looks as follows where stuff we added to the auto-generated file is in red:

//
//  SecondProjectViewController.m
//  SecondProject
//
//  Created by Chris Pollett on 8/31/09.
//  Copyright San Jose State University 2009. All rights reserved.
//

#import "SecondProjectViewController.h"

@implementation SecondProjectViewController


@synthesize statusText;

-(IBAction)buttonPressed:(id)sender
{
	NSString *title = [sender titleForState:(UIControlState)UIControlStateNormal];
	NSString *newText = [[NSString alloc] initWithFormat:@"%@ button pressed.",title];
	statusText.text = newText;
	[newText release];
}


/*
// The designated initializer. Override to perform setup that is required before the view is loaded.
- (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil {
    if (self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil]) {
        // Custom initialization
    }
    return self;
}
*/

/*
// Implement loadView to create a view hierarchy programmatically, without using a nib.
- (void)loadView {
}
*/


/*
// Implement viewDidLoad to do additional setup after loading the view, typically from a nib.
- (void)viewDidLoad {
    [super viewDidLoad];
}
*/


/*
// Override to allow orientations other than the default portrait orientation.
- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation {
    // Return YES for supported orientations
    return (interfaceOrientation == UIInterfaceOrientationPortrait);
}
*/

- (void)didReceiveMemoryWarning {
	// Releases the view if it doesn't have a superview.
    [super didReceiveMemoryWarning];
	
	// Release any cached data, images, etc that aren't in use.
}

- (void)viewDidUnload {
	// Release any retained subviews of the main view.
	// e.g. self.myOutlet = nil;
}


- (void)dealloc {
    [super dealloc];
}

@end

Some remarks

@synthesize - tells the compiler to autogenerate the code (I.e., write the setter and getter) for the @property we had in the header file.
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 alloc] initWithFormat:@"%@ button pressed.",title]
This class method is a factory method, and it returns an autoreleased object. The generally memory rule is that "if you didn't allocate it or retain it, don't release it".
Notice we are using the dot notation we mentioned for properties a couple slides back: statusText.text = newText;

Connecting Outlets with UI

Launch Interface Builder (IB from now on) on the Project View Controller, add two Round Rect Buttons and a Label to the View. Add some text to them by opening the Inspector.
In the Left Pane of IB (the main nib window), hold CTRL and click on File's Owner. Drag the icon to the Label on the View Window. A line should appear connecting the two. Let go of the mouse and it will give a list of Outlets you could connect to. Choose statusText.
The idea is that the nib file's owner will be the SecondProjectViewController class, and you have just told interface builder that you want to connect the File's Owner's statusText outlet with the label when the nib file is loaded.

Connecting Actions with UI

To connect a Button with an action, in the View window click on the button to select it.
Then open the Connection Inspector in the Tools menu.
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.
To connect this with our controller. We click on the circle next to this trigger and drag it to the File's Owner Icon. It will give a list of actions we can connect with. We choose buttonPressed.
That's it for our app! To test it out, we save the nib file, and compile 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 and open the Inspector 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"];
```

More on How iPhone Apps Work

Recall we said the File's Owner's statusText outlet is connect with the Label when the nib file is loaded.
You might be wondering what exactly is the life cycle of an iPhone App. It is:
1. Launch App
2. App Initialized
3. Load Main Nib
4. Wait for Event/Handle Event cycle
5. Exit
When we are editing nib files in IB, we are actually modifying properties of a UIView Object.
When we click save this object is serialized as an XML file.
This is unlike interface builders for some other frameworks like Java where code for a subclassed View class might be generated and this code might late have to be compiled.

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 Other Sources > 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 SecondProjectAppDelegate. If you look at the .m file for it, you can see where it sets up how our controller works, as well as an example of a method that is called at a given point in the app lifecycle:
```
- (void)applicationDidFinishLaunching:(UIApplication *)application {    
    
    // Override point for customization after app launch    
    [window addSubview:viewController.view];
    [window makeKeyAndVisible];
}
   
```

Auto-release Pools

We briefly mentioned autorelease objects when we talked about NSString's initWithFormat: method.

In main.m we see another portion of how the autorelease mechanism works:

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

The first line creates an autorelease pool.
Thereafter, you can create an object, use it, and call [myObj autorelease]; 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 Second_ProjectAppDelegate.h file also illustrates another feature of Objective-C, Protocols. The declaration
```
@interface Second_ProjectAppDelegate : NSObject <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];
}