Things wot I learnt from Stanford – iPad & iPhone App Development – Fall 2011 – Lecture 7

Great tip: viewDidLoad: is always called AFTER all outlets are wired up when a view controller is instantiated from a storyboard. Therefore, this is a good place to shove any initialization code that need to reference outlets.

UIToolBar

  • Usually at the top or bottom of your view.
  • A collection (NSArray) of UIBarButtonItems easily accessed read and written using self.toolbar.items.
  • Has a default “steel” effect UI, but can be customized using barStyle, backgroundColor or a background image etc.Fig 1
  • The UINavigationController has an optional toolbar at the bottom – its toolbarHidden @property is set to YES by default but you can switch it on by setting this to NO programmatically or via a toggle button in the Storyboard.
  • Set the toolbar.items @property in each embedded view controller to an array of UIBarButtonItems to control what buttons appear for that view controller.
  • A UIBarButtonItem can show text or an image, or you can even set it to a custom view.

UISplitViewController

  • Only available on the iPad.
  • A UISplitViewController will not even be presented as an option for an iPhone storyboard.
  • A storyboard can be either iPad or iPhone specific. You must specify which when you create it.
  • A split view is generally a “root” UI element only – i.e. it fills a whole screen.
  • It is usually the initial view controller and not normally embedded in another view controller.
  • Usually you would only have one split view controller in your app.
  • The master and detail view controllers are specified in an NSArray accessible via the viewControllers @property in the split view controller. The master view controller is element 0 and the detail view controller is element 1.
  • Usually you’d just specify these using drag and drop in your storyboard.
  • Note that the viewControllers array is passed as a “copy” @property, not a strong reference, so you can’t pass in a mutable NSArray then change its elements later and expect the split view controller to change.
  • The UISplitViewController requires a delegate @property for use in portrait mode or, by default, there will be no way to display the hidden master view controller.
  • Usually you set the delegate in viewDidLoad or awakeFromNib.
  • Depending on the implementation, either the master or detail view controller may be the delegate. More often, it is the master since it is often always present in memory (even when not displayed).
  • The delegate controls in which screen orientations the master view controller appears or is hidden. The detail view controller (normally to the right) is always visible.
  • The delegate is declared as:
    @property (nonatomic, assign) id <UISplitViewControllerDelegate> delegate;
    So beware, assign is like a “weak” pointer but without the “zeroing” action – so in theory, you could get a dangling pointer, but this is unlikely within a split view controller.
  • The delegate is asked about when the master should be on screen. When the master is about to be removed from the screen, your delegate will be informed and passed a UIBarButtonItem which you need to display on screen in your detail view controller. When selected by the user this button will display the master (usually in a popover).
  • When the master view controller is about to be hidden from view, your delegate will again be informed and be responsible for removing the UIBarButtonItem.
  • The screen shot below shows the delegate message and demonstrates how you can instruct the split view controller when to hide/show the master view controller.
  • Fig 2Note how you can specify that the master (left) view controller is ALWAYS visible by returning NO for every orientation:Fig 3
  • The default is to hide the master in portrait mode:
    return UIInterfaceOrientationIsPortrait(orientation);
    This is why you always need a delegate or you’ll never see the master view in portrait mode:Fig 4
  • You handle the following message in your delegate to show the bar button – see how iOS kindly passes the UIBarButtonItem to use! easy!Fig 5
  • When the master view controller is about to be shown, you handle the opposite message and remove the bar button:Fig 6
  • Here’s a typical implementation for the setSplitViewBarButtonItem: method. This will show the button when passed, and hide it if the passed button is nil:Fig 7
  • You could handle this in the master or detail view controller – it depends which one you set as your delegate. Normally, you’d chose the view controller that’s gonna be in the split view controller all the time (even when it’s not visible), or you might chose the least generic controller. Obviously, the button is always shown in the detail view.
  • The simplest way to update the detail view is by using a target/action.
  • Note we can pass messages to the detail view controller using:
    id detailVC = [[self.splitViewController viewControllers] lastObject];
    See slide…Fig 8
  • …or, you can use a “Replace” segue. This is actually more hassle though. Note the warning in the above slide. You’d normally pass the UIBarButtonItem in prepareForSegue.

Popovers

  • A Popover is not a UIViewController – it just inherits from boring old NSObject.
  • Its content is provided by an embedded “Content” view controller which you supply.
  • You can animate a change of content in a Popover already on screen with:
    – (void) setContentViewController: (UIViewController *) viewController animated: (BOOL) animated;
  • You can also animate a change in size using:
    – (void) setPopoverContentSize:(CGSize) size animated:(BOOL) animated;
    This can look sweet.
  • in prepareForSegue, the segue argument will be isKindOfClass:UIStoryboardPopoverSegue which has a popoverController @property which you can use to grab a reference to the Popover.
  • Tip: Detect whether a Popover is visible using its isPopoverVisible @property.
  • WARNING: You MUST keep a strong pointer to your Popover controller since when a local variable goes out of scope your Popover will be deallocated! This is a common mistake!
  • You can add views to a Popover’s NSArray *passthroughViews @property if you want to ensure your Popover is not dismissed by the user touching certain views outside the Popover.
  • If you want, you can add the whole screen to passthroughViews – in this case you absolutely need a button in the Popover content to dismiss it.
  • It’s best practice to always call dismissPopoverAnimated: from outside your Popover – probably triggered via a delegate message to the view controller that initially presented it – rather than from inside – even though the latter seems easier. This is good object-orientated practice since the Popover content view controller should not need to know it’s in a Popover!Fig 9
  • The best way to specify your Popover’s size is to set the contentSizeInPopover @property of your content view controller since this is most likely to know the size it “wants” to be and can also be calculated on the fly and set programmatically.Fig 10

Universal Applications

  • Use a single binary image with separate storyboards for the iPhone and iPad.
  • How do I figure out I’m running on an iPad?Fig 11
  • BUT – whenever possible, don’t do this! Instead, use “feature-sniffing” rather than forking based on the platform. For example, if self.splitViewController is not nil you must be running in a split View Controller on an iPad. Anyone coming from a JavaScript background will recognize this technique.
  • A handy tip to find out if a view is actually on screen is to check its window @property:Fig 12Other handy ways to get the size of the current screen and the resolution:Fig 13The contentScaleFactor will return pixels per point e.g. 2 on a retina display. It’s a good way to find out what kind of screen you’re running on.
  • By default a UIViewController doesn’t support landscape orientation. This is why, if you just drag a generic view controller onto a storyboard and add a segue to it, when it runs the view will appear in portrait mode regardless of the device’s orientation. To solve this you can create a generic, custom sub-class which inherits from UIViewController and merely overrides the shouldAutorotateToInterfaceOrientation: method. A nice name for this would be “RotatableViewController”. You can use this class for all these instances even in other applications.
  • You can easily copy and paste view controllers from one storyboard to another. This is a great way to create a new storyboard e.g. for the iPad based on an existing one for the iPhone.
Advertisements

Things wot I learnt from Stanford – iPad & iPhone App Development – Fall 2011 – Lecture 6

Multiple MVC’s and Segues

A common design pattern is for an object to pass a reference to itself (using ‘self’) when sending a message to a delegate so that the delegate can ask our object for more information if they want. For example in the @protocol definition shown below, the FaceView control will set the sender parameter to self when it calls the delegate which handles the smileForFaceView: message:

Fig 1

An object sends a reference to itself to the handler.

If you want the fact that your class implements a @protocol to be kept private (i.e. it’s not of interest to an external developer), you are allowed to specify the @protocol name in your private @interface declaration  – i.e. the one (normally) in your “.m” file rather than in the header “.h” file. See screenshot.

Fig 2

Declaring a protocol implementation privately

CGPointZero is a handy, predefined constant for specifying a point of (0, 0) for example when resetting translations passed to gesture handlers. See screenshot.

Fig 3

Using CGPointZero to reset a translation in a gesture recognizer.

One MVC (Model, View Controller) should never control more than one screen. If we need to add another screen we should add a new MVC.

Fig 4

Multiple MVCs working together to show multiple screens.

We need a “controller of controllers” to switch between multiple MVCs (or screens) for example a UINavigationController. These are sometimes referred to as “container controllers”.

Fig 5

A UINavigationController acts as a “controller of controllers” and allows us to co-ordinate between multiple MVCs

Fig 6Fig 7A UINavigationController is a subclass of UIViewController with its own view which can have a title bar and always has an area below it in which to show the view from another MVC. It has no model, it is purely a UI controller.

It has a rootViewController @property which can point to another MVC. This controls what appears in its view (the white area in the screenshots above). It actually “embeds” that MVC’s view into this area. It will change the bounds of your MVC’s view to fit (note your “springs” and “struts” defined in Interface Builder and the view’s contentMode therefore become important during this resizing).

Segues

Only in iSO 5 and later. To create a segue in your Storyboard, hold down Ctrl and drag from the source object (e.g. a button) to the destination view controller.

Fig 8

Creating a Segue

Segues always instantiate a new instance of a view controller. Segues ALWAYS instantiate a NEW instance of a view controller. That’s not a Ctrl-V stutter- I said it twice as it’s important! They always create a new instance from scratch. This allows iOS to dispose of the destination view controllers and free up memory as soon as they’re dismissed.

Segue styles (at the time of writing) can be Push, Modal or Custom (your own subclass of UIStoryboardSegue). Push is used inside a UINavigationController. The iPad also supports Replace which allows you to replace the right-hand view of a UISplitViewController. The style can be set in the Storyboard by selecting the segue and choosing it from a list as in the slide below.

Fig 9

Specifying a segue style (and identifier)

The slide below shows how you can embed your view controller (often your startup one) in a Navigation Controller using the Storyboard interface. The process is similar for embedding within a Tab Bar Controller.

Fig 10

Embedding your view controller in a Navigation Controller.

This leads to this…

Fig 11Your view controller is added to the Navigation Controller as the rootViewController @property (an outlet).

Fig 12Here’s an example of how your view could appear embedded within a Navigation Controller. Notice that the “back” button takes it’s label text from the title @property of the previous UIViewController and the title of the current View Controller is shown at the top.

Fig 13

Using a UINavigationController

A really quick way to set the title @property is just to double-click it directly in the Storyboard and type it in.

Fig 14

Entering the title @property for your View Controller.

Pressing the “Back” button pops a pushed MVC back to the original, source MVC, but you can also do this programmatically using the UINavigationController instance method:

– (void) popViewControllerAnimated: (BOOL) animated

It’s rare but sometimes handy to call this. In this example, we actually call this function from within the controller on screen – i.e. the one to be “popped” – when its display is no longer required.

Fig 15

Popping a view controller programmatically.

All UIViewControllers have a navigationController @property. If the controller is not embedded in a Navigation Controller this will be set to nil. There are similar properties to access other container controllers such as tabBarController.

Triggering a segue from code:

Fig 16When a segue fires, the destination view controller is instantiated with all its outlets then the following message is sent to the source view controller to give it the chance to pass it information:Fig 17A common pattern here is to set ‘self‘ as the delegate for the the new, destination controller using the id type. Using the id type is important! DO NOT PASS THE ACTUAL TYPE. Always treat the new View controller as you would treat a view – give it as little information as possible. This approach greatly enhances the portability (“re-usability”) of your controller and code.

You can also instantiate a view controller programmatically using the Storyboard method:

– (id)instantiateViewControllerWithIdentifier:(NSString *)identifier

You can obtain a reference to the Storyboard by calling self.storyboard – as long as self was created from the same Storyboard.

Fig 18

Instantiating a view controller from the Storyboard programmatically.

Note the use of pushViewController in this example which assumes the current controller is embedded in a Navigation Controller.

Tip: Did you know a UILabel control can have more than one line of text simply by selecting it in your Storyboard and setting the “Lines” attribute to a number greater than 1?

Things wot I learnt from Stanford – iPad & iPhone App Development – Fall 2011 – Lecture 5

Protocols and Gestures

When rotated, the frame of all sub views in your controller’s view will be adjusted based on their “struts & springs”.

You define the struts & springs in the Interface Builder:

Slide: Struts and Springs

Defining Struts and Springs in Interface Builder.

The outer, white rectangle in the preview represents the superview. The inner, red box is the view you’re defining your struts and springs for.

By default, after a rotation, drawRect is NOT called – instead the “bits” of any custom drawing in your view will be stretched or squished or moved according to a UIView @property contentMode:

@property (nonatomic) UIViewContentMode contentMode;

There are many possible values for contentMode all prefixed UIViewContentMode including Left, Right, Top, Bottom, BottomLeft, BottomRight, TopLeft and TopRight

These modes have a similar effect to struts and springs i.e. they move your bits to that location but the contentMode is actually applied AFTER any struts and springs.

There are also some content modes which describe how you want your bits to scale UIViewContentModeScaleToFill, UIViewContentModeAspectFill, UIViewContentModeAspectFit.

UIViewContentModeScaleToFill is the default and is the reason why, if you don’t specify a mode, any drawings can become elongated or squished into a different aspect ratio – like your gran’s new TV.

contentMode UIViewContentModeRedraw ensures drawRect is called. This is usually what you would want if you have custom drawing.

There is another @property:

@property (nonatomic) CGRect contentStretch

This allows you to control which bits get stretched and which don’t. This is useful for example if you have a button where you’d like the middle part stretched but the ends to stay the same.

Note that you can set the contentMode in code usually when your view is initialized, or you can simply set it using a drop down in Interface Builder – select your view and navigate to the Attributes Inspector – the list is labelled “Mode”.

Storyboards and UIView Initialization

Warning: when a view is initialized from a nib file or Storyboard, initWithFrame (the designated initializer) DOES NOT GET CALLED. Instead, awakeFromNib is called. If you have a habit of putting setup code in initWithFrame you need to be aware if this. Move your setup code into a separate method and call from both as per the slide.

Warning: awakeFromNib

Call setup() from Warning: awakeFromNib: AND initWithFrame:

Note it’s neater to put your setup stuff in property setters or getters rather than doing this. If you’re the lazy kind, you could also put it in viewDidLoad and avoid the issue altogether (depending on what your setup does).

Protocols

It is considered good practice to always include <NSObject> as a required protocol in any protocol definition. This ensures that only descendants of NSObject can use your protocol since descendants of NSObject will, by inheritance, handle the <NSObject> protocol. Since we mainly work with NSObject descendants in Objective-C this could also be considered a waste of typing unless you’re a pedant – but we all are aren’t we? 😉

Protocols - Syntax

The syntax for defining Protocols

Protocols are defined in a header (.h) file.

A Protocol can be the only thing in a standalone header file – handy for sharing between many objects. Often though a Protocol will be in the header file of the class that wants other classes to implement it. For example the UIScrollViewDelegate Protocol is defined in UIScrollView.h along with the definition for the UIScrollView itself.

You can refer to an object that implements a protocol using the <Protocol> specifier e.g.:

id <Foo> obj = [[MyClass alloc]init];

This allows the compiler to alert you with warnings if you assign any object that doesn’t implement <Foo>. You can also use this in arguments and @property declarations (see slide).

Declaring Protocol Implementers

Declaring Protocol Implementers for the sake of the compiler.

A view should never need to know the class of its controller.

The most common use of a Protocol is for delegates. A delegate or dataSource is almost always defined as a weak @property.

@property (nonatomic, weak) id <UISomeObjectDelegate> delegate;

This is common sense really since the object serving as a delegate will usually outlive the object doing the delegating – especially when the delegator is a view (such as UIScrollView) since the delegate is that view’s controller. Controllers always create and clean up their views. Views are just their minions. They are Gaga’s little monsters.

A dataSource is just like a delegate in that we’re delegating the provision of data. Views often have a dataSource delegate as they cannot own their data.

Gesture Recognizers

Gesture recognizers are usually added by the controller and handled by the view – adding the gesture recognizer is the equivalent to “switching it on”. Views often “know” what to do with the gesture e.g. “pinch”. If a view doesn’t make sense without the gesture then it may even add its own gesture recognizer as well as handling it (e.g. a UIScrollView). Even in this case, the handler may instead be handled by the controller if you want to handle things differently – e.g. a gesture that effects the model since the view should not modify the model directly.

The initWithTarget: argument of a gesture recognizer actually specifies the gesture handler NOT the object on which the gesture will operate – that is specified by the receiver of the addGestureRecognizer message.

A reference to the gesture recognizer itself is sent to the handler so it can be examined for its state. Every gesture recognizer has a readonly “state” property of type UIGestureRecognizerState.

The Initial value of state is “Possible”, another value is “Recognized”. Discrete gestures such as tap can go directly to this state. Continuous gestures like pan can also have states of “Began”, “Changed” and “Ended”. At any time, the state can change to “Failed”, for example if a phone call interrupts a gesture, or “Cancelled” if the recognizer realizes its not a gesture after all.

Handling the pan gesture (slide)

Handling the pan gesture

A Nice Tip

If your custom view has a writable property, the value of which can effect any displayed, custom drawing (e.g. a “scale” property) a common pattern is to call [self setNeedsDisplay] in the property setter. This queues up a call to drawRect: which will redraw your view with the new property value – neato!! TIP: Wrap this in a check which makes sure that setNeedsDisplay is only called if the property value has actually changed. Calls to drawRect can be expensive so shouldn’t be done if not necessary!

Tip: Calling setNeedsDisplay in your setter (slide)

Tip: Calling setNeedsDisplay in your setter

Things wot I learnt from Stanford – iPad & iPhone App Development – Fall 2011 – Lecture 4

This lecture was mainly to introduce views.

If you expose a public method that accepts an id, use introspection to check that it is what you expect e.g. if ([theParam isKindOfClass:[NSArray class]]) {…do your stuff…}

Any view has only one superview which can be referenced via the (UIView *)superview @property.

A view can have many (or no) subviews, which can be accessed via the (NSArray *)subviews property. Note that those views later in the array are on top of earlier ones (z-order wise).

In iOS, there will only be one UIWindow right at the top of the view hierarchy. You almost never need to interact with this. Normally the highest view you interact with is the one belonging to the view controller at the top of your hierarchy which controls the whole screen.

Important: Although you add a subview by calling addSubview on the parent view, you remove a subview by calling removeFromSuperview from within the subview – i.e. you ask the subview to remove itself.

The CGFloat structure is used for all view coordinates.

Common structures used for views are:

  • CGPoint  – created with CGPointMake
  • CGSize  – created with CGSizeMake
  • CGRect  – created with CGRectMake

View coordinates and sizes are measured in “points” not pixels. To be future-proof, try to avoid any reference to pixel sizes.

There is a UIView @property CGFloat contentScaleFactor which returns pixels per point on the screen the view is on. This can be used when you really need to know the scaling factor e.g. when drawing charts etc.

Views have 3 important properties related to their location and size:

  • @property CGRect bounds; // Your view’s internal drawing space’s origin and size. Normally you always use bounds coordinates when drawing within your view.
  • @property CGPoint center; // The American centre of your view in it’s superview’s coordinate space.
  • @property CGRect frame; // A rectangle in the superview’s coordinate space that entirely contains your view’s bounds.size.

Use center and frame to position your view within it’s superview (see slide)

Slide from Stanford Lectures Fall 2001To calculate the centre point of a view in bounds coordinate space use:

= (bounds.size.width/2+bounds.origin.x, bounds.size.height/2+bounds.origin.y)

The designated initializer for UIView is initWithFrame:

self.view is always a Controller’s top-level view (i.e. the first subview in the self.subviews array).

One common reason to create a custom view (a UIView subclass) is to handle touch events in a special way.

To draw in a UIView, just override one method:

- (void)drawRect:(GCRect)aRect;

You can optimize by not drawing outside aRect if you want – but this isn’t a requirement.

NEVER, EVER call drawRect: !! – drawing is expensive! Let iOS decide when to do it!!!

Instead, let iOS know that your view’s visual’s need updating with one of these UIView methods:

  • – (void)setNeedsDisplay:
  • – (void)setNeedsDisplayInRect:(CGRect)aRect;

iOS will then call drawRect: for you at an appropriate time.

Like ye olde Windows 3.0 programming days, you draw into a “context“. The context determines where your drawing goes e.g. screen, off-screen bitmap, PDF, printer etc.

drawRect sets up the current context for you – a new one is set up each time drawRect is called – so never cache the current context in drawRect: to user later!

You get the current context within drawRect: by calling:

CGContextRef context = UIGraphicsGetCurrentContext();

This is usually your first line within drawRect:

Drawing…

  1. Get the context.
  2. Define a Path.
  3. Set the graphics stroke and fill
  4. Call CGContextDrawPath
Drawing

Drawing

Note that you don’t specify the context for setFill & setStroke – they assume the current context (i.e. the one obtained with UIGraphicsGetCurrentContext())

You can also save and reuse paths using similar functions to the CGContext… ones but prefixed CGPath… This is useful if, for example, you wanted to define a star and then display it 100 times.

UIColor is a class. Methods exist for obtaining common colours e.g. [UIColor redColor]

Call UIColor with setFill and setStroke to return fill and stroke styles in a particular colour.

In iOS, alpha values range from 0.0 (transparent) to 1.0 (opaque).

UIView has a backgroundColor @property which can be set to transparent values.

You have to set UIView @property opaque to NO if you want to use transparency. By default it is YES for performance reasons.

The UIView @property alpha can be used to make the entire view support transparency.

The UIView @property hidden allows you to hide a view. When hidden, it will not be shown on screen and will not handle events. This is a great way to de-clutter a screen by hiding a temporarily unused view. I suspect this is a good performance tip too since it doesn’t handle events when hidden.

Pushing and Popping contexts…

Use UIGraphicsPushContext and UIGraphicsPopContext to preserve a context’s state e.g. if you’re calling a sub-routine which may effect it. See slide.

Preserving Graphics State

Preserving Graphics State. (© Standford University)

Drawing Text in a Custom Font…

You can simply use a UILabel to display text. You can get very fancy using this! However, if you really want to have full control of your font, you can use the UIFont object. See the slide. Perhaps surprisingly, NSString is used to display text in your custom font. These NSString methods are actually defined in UIKit using a mechanism called categories.

Drawing Text

Drawing Text. © Standford University.

Drawing Images…

This refers to bitmap images. Commonly you’d use a UIImageView to display an image (or animation). But this is not the only way. You can even create a bitmap image by drawing with the CGContext functions. See the slides , below…Drawing Images - Slide 1Drawing Images - Slide 2

Things wot I learnt from Stanford – iPad & iPhone App Development – Fall 2011 – Lecture 3

If you implement the getter and setter for a @property yourself, there is no need to call @synthesize at all.

Its possible that some (usually read-only) @properties might be “calculated” rather than stored to a member variable.

C structures (quite common in iOS) are (almost) never allocated on the heap and so are not referenced by pointers. They are passed around by value. E.g. CGPoint:

typedef struct {
    float x;
    float y;
} CGPoint;

Like class names, it is standard practice to capitalize structure names (and enums) such as CGPoint.

Pointer Referencing

strong reference
– means “keep in the heap until I don’t point to it anymore”.

You won’t point to it anymore if:
You set your pointer to nil.
Or
Your pointer is removed from the heap because no one strongly points to it!

weak reference
– means “keep this as long as someone else points to it strongly“.
If your pointer is thrown out of the heap in iOS 5 or later, it is automatically set to nil so its safe and easy to check for this.

Unlike garbage collection (as used by other frameworks such as .NET) Automatic Reference Counting (ARC) IMMEDIATELY frees objects as soon as they become unreferenced.

Local variables are strong by default and get cleaned up by ARC as soon as they go out of scope.

-(void) dealloc: is called on your object when it is freed – but by this time its really too late to do anything useful. You’d rarely intercept it. dealloc has become less important since iOS 5.

Since the introduction of ARC with iOS 5, release, retain and autorelease are no longer used.

Class methods are normally used for creation and utility functions (e.g. alloc) or to get a reference to a shared instance. They are called with the name of the class or by obtaining a reference to the class by calling an instance with the “class” method.

[[ship class] myClassMethod];

Instance methods are normally called with a pointer to an instance.

Classes cannot have properties as properties are instance variables.

All objects must have “init” or some form of init called immediately after alloc. We ALWAYS nest these calls in one statement e.g. [[MyObj alloc] init];

All classes inherit init from NSObject. If a class cannot be fully initialized with a call to init the guidelines suggest that (strictly) you should code init to raise an exception.

Designated Initializers…

All your classes should declare a designated initializer for sub-classes to call (using [super init…]). Sub-classes MUST call this initializer from their designated initializer (using [super…]). E.g. a sub-class of UIView should ALWAYS call [super initWithFrame]. You should declare your designated initializer in your documentation, there’s no way to indicate this in code. Consult Apple’s documentation to find out the designated initializer for classes you wish to sub-class in the Objective-C framework.
Only call the super-class’s designated initializer from your designated initializer – no-where else. If you have other initializer’s in your class, make sure they call your designated initializer to guarantee the super class’s designated initializer is called regardless of which initializer is called to initialize your class (dig? – dug).

init methods should return an id (not a static type). The caller though should use a static type for the returned pointer.

An example of an initialization method

DYNAMIC BINDING – VERY IMPORTANT!!!

Objective C is different to most statically typed languages in that the code to send a message to an object method is generated at runtime NOT at compile time. This is very important to realize as it is intrinsic to the way an iOS app operates. Static typing in your source code is purely an aid to the compiler to help you find bugs at write time. Dynamic binding at runtime allows messages to be sent to any object at runtime. As long as the object supports that message this is fine – if not, your app will crash. you can use the “introspection” method respondsToSelector to test whether a receiving object supports a particular message.

(See “The Objective-C Runtime Programming Guide” for the technical details of messaging)

You can obtain a dynamic reference to a method (referred to as a SELECTOR) at runtime using various commands (use the SEL type to store a reference to a Selector)

Objective-C classes support Introspection using various methods e.g. isKindOfClass, isMemberOfClass, respondsToSelector etc. The “class” method mentioned earlier is handy here.

if ([obj isKindOfClass:[NSString class]]) {
    NSString *s = [(NSString *)obj stringByAppendingString:@"xyz"];
}

Introspection

The same NSArray can hold references to different object types. You cannot store nil in an NSArray though – use NSNull instead. NSNull acts as a placeholder indicating “no value”.

Contrary to what you’d assume, NSMutableString is rarely used. It doesn’t really save much heap thrashing compared to the immutable NSString class which is highly optimized for most operations.

NSStrings are mostly passed around as immutable copies.

Many objects support copy: and mutableCopy: to convert between mutable and immutable types.

NSValue can be used as a generic object wrapper even for C structures such as CGPoint.

CGPoint point = CGPointMake(25.0, 15.0);
NSValue *pointObject = [NSValue valueWithCGPoint:point];

This would let you store a bunch of points as objects in an NSArray.

NSData is just a “bag of bits” (similar to a “Blob” in other languages). Its up to the app to interpret what the bits mean (e.g. a jpeg image). NSData is commonly used to save/restore and transmit data of many kinds throughout iOS.

Tip: NSArray containsObject: can be slow. Think about using an NSOrderedSet instead. NSOrderedSet is an immutable, ordered (indexed) collection of distinct objects.
NSSet is similiar to NSOrderedSet but is unordered – i.e. has no index for referencing.
One of the most important features of NSSet and NSOrderedSet is that they are geared up for highly efficient searching using “contains”. Also, they will only store “distinct” objects. If you attempt to add an identical object (where isEqual == YES) the attempt will simply be ignored. These two features make them ideal for looking up a match for any object.

Enumerating through collections
Using for…in is highly efficient see slides below from the lecture for example syntax.

Enumeration - Slide 1

Enumeration - Slide 1

Enumeration - Slide 2

Enumeration - Slide 2

Property Lists (aka “plist”)

These seem to be just collections of collections where the collection members are “simple” types – i.e. not your own, custom classes.

Property List

Property List (Slide from Lecture 3)

NSUserDefaults makes use of a plist for persisting data such as a user’s preferences.

Things wot I learnt from Stanford – iPad & iPhone App Development – Fall 2011 – Lecture 2

We usually make an outlet @property weak since the view will already have claimed a strong reference to it, and, if the view exists, it can usually be assumed the view object exists e.g. a UILabel outlet.

Most “non-outlet” @properties are declared as strong for the opposite reason – i.e. only we are referencing them. Practically all controllers will have a strong reference to their model.

NSNumber acts as a handy, object wrapper around primitive number types (e.g. double) that we can pass to framework methods that usually require an object and for storage in NSArray, NSMutableArray, NSDictionary etc. e.g. [NSMutableArray addObject:];

Like NSNumber, you can pass NSString messages such as doubleValue, floatValueintegerValue etc. to convert string values to primitive, numeric types.

A view controller can have IBOutlets from more than one Storyboard e.g. you could have one Storyboard for the iPad and one for the iPhone in a universal application.

id does not mean “object of any class”, it means “pointer to an object of any class”. This is why we use (id) rather than (id *) when passing an id to a method etc. The “*” is implicit.

If an object needs allocating and/or initializing upon its first access its a neat idea to allocate and initialize it in its “getter”. This is refereed to as “lazy initialization”.

Remember: @synthesize NEVER allocates anything, it just sets aside a pointer to an object that can be instantiated.

All properties start out with a value of zero (0), or, if an object, nil.

If you send a message to a nil object the object will just do nothing and return zero (or nil) if the message expects a return value. This is allowed, your app will not crash! The only exception is if the method returns a C struct (e.g. CGPoint) in which case the return value will be undefined.

Use an isEqual method to compare objects, not == since == only compares the object addresses.

Things wot I learnt from Stanford – iPad & iPhone App Development – Fall 2011 – Lecture 1

A @property setter’s name is “set” plus the capitalized @property name e.g. the setter for a @property named myValue would be setMyValue. The “getter” is simply: myValue.

It is considered best practice to always name properties starting with a lowercase letter e.g. myProperty not MyProperty.

You can still create a getter and setter even if you use @synthesize in your implementation file. If you do your getter or setter will be called instead of the synthesized one. This is common practice e.g. to implement “lazy initialization” in the getter.

Property and method declarations are considered public if declared in your header (.h) file and private if declared in your implementation (.m) file.

To declare private properties and methods in your implementation file, wrap them in the @interface … @end compiler directives as in your header file but put a parenthesis after the @interface() opener:


@interface CalculatorViewController()

// Private declarations...

@property (nonatomic, strong) CalculatorBrain *brain;

@end

To help the compiler and yourself, always specify the name of the hidden member for your @properties e.g. @synthesize myValue = _myValue; The compiler will then warn you if you omit the “self” keyword when referencing a member property.