Interface File Comments

When I create an interface file, here is the basic layout of my comments:

/*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*  AboutViewController.h
*
*  Created by John on 6/10/11.
*  Copyright 2011 iOSDeveloperTips.com. All rights reserved.
*
*  Long comments describing this object would go here...
*  ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*/
 
@interface AboutViewController : UIViewController
{
  UIButton          *backButton;  // Comment here
  NSMutableArray    *queueArray;  // Comment here
  NSMutableArray    *bucketArray;  // Comment here
 
  //-------------------------------------------------------
  // To describe something in more detail, it would go here
  // searchResultsCount varaible will hold ....
  // questionsResultsCount is calculated by ...
  //-------------------------------------------------------
  int               searchResultsCount;     // Comment here
  int		    questionsResultsCount;  // Comment here
 
}
 
@end

I’m not sure when it happened, somewhere on the way I moved away from the traditional comment block shown below, I don’t use this for the header or inside the primary code sections. I must of tired of the look and made a small tweak to us ~ and – characters.

/**********************************************************
* To describe something in more detail, it would go here
* searchResultsCount varaible will hold ....
*  questionsResultsCount is calculated by ...
**********************************************************/

Implementation File Comments

At the top of the implementation file, my header looks the same as the interface file. If there is a private interface (see the post Private Methods for more information), I follow the same layout:

/*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*  AboutViewController.m
*
*  Created by John on 6/10/11.
*  Copyright 2011 iOSDeveloperTips.com. All rights reserved.
*
*  Long comments describing this class would go here...
*  ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*/
 
#import "AboutViewController.h"
 
/*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Private interface definitions
*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*/
@interface AboutViewController(private)
- (BOOL) processSearch:(NSString *)string;
@end

For methods in the class, my comment format looks as follows:

/*---------------------------------------------------------------------------
* Manage button precess events
*--------------------------------------------------------------------------*/
- (void)buttonPressed:(UIButton *)button
{
  // For one line comment
  if (button == backButton)
  {
  }
 
  //-------------------------------------------------------
  // If more than one line of comments is needed, 
  // I use this format...
  //-------------------------------------------------------
  ...
 
}

Here is a template of what my code looks like with #pragma marks included:

/*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*  AboutViewController.m
*
*  Created by John on 6/10/11.
*  Copyright 2011 iOSDeveloperTips.com. All rights reserved.
*
*  Long comments describing this object would go here...
*  ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*/
 
#import "AboutViewController.h"
 
/*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Private interface definitions
*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*/
@interface AboutViewController(private)
- (BOOL) processSearch:(NSString *)string;
@end
 
@implementation AboutViewController
 
#pragma mark - Private Methods
 
/*---------------------------------------------------------------------------
* This method....
*--------------------------------------------------------------------------*/
- (BOOL) processSearch:(NSString *)string
{
  ...  
}
 
#pragma mark - Initialization
 
/*---------------------------------------------------------------------------
* Initialization of ...
* More comments here...
*--------------------------------------------------------------------------*/
- (id) init
{
 
}
 
#pragma mark - Event Management
 
/*---------------------------------------------------------------------------
* Manage button precess events
*--------------------------------------------------------------------------*/
- (void)buttonPressed:(UIButton *)button
{
  // For one line comment
  if (button == backButton)
  {
  }
 
  //-------------------------------------------------------
  // If more than one line of comments is needed, 
  // I use this format...
  //-------------------------------------------------------
  ...
 
}  
 
#pragma mark - Cleanup
 
/*---------------------------------------------------------------------------
* Cleanup code
*--------------------------------------------------------------------------*/
- (void)dealloc 
{
  ...
 
  [super dealloc];
}
 
@end

The beauty of using #pragma mark is that within Xcode you can get a nice breakdown of the organization of your code:

You can view this dialog from within Xcode by clicking on the class status bar in the boxed area shown below:

Posting a Comment with Code

Please feel free to post code examples of your comment style. If you would like have your code color highlighted as shown above, using the following format:

<pre lang=”objc”>
your code here
</pre>

This post isn’t as much a tip or trick, as it is an opportunity for developers to share their variations and preferences when it comes to indenting code. Let me give you a quick run-down of how my Objective-C code typically looks. As you’ll see, if nothing else, I am consistent…

Functions/Methods

I like my braces on a line by themselves:

- (void) loginAttemptComplete:(id)results
{
  ...
}

This is consistent across all of my code, for example, here is how an interface definitions may look:

@interface LoginViewController : UIViewController
{
  ...
}

As far as parameters, I like to keep them on the same line:

int main(int argc, char *argv[])
{
  ...
}

Versus this:

int main(argc, argv)
         int   argc;
         char  *argv[];
{
  ...
}

If the list gets lengthy, I will wrap and indent:

- (void)searchBar:(UISearchBar *)searchBar selectedScope:(NSInteger)selectedScope didChange:(BOOL)didChange
                  top:(BOOL)top                  
                  color:(UIColor)color
{
  ...
}

Calling Functions/Methods

Again, I like to keep everything on one line when possible, this includes calling a function or method. I am generally okay if my lines extend past 80 characters given the expansive screen resolutions available on most machines:

[someObj: searchPrefs:(UISearchPrefs *)searchPrefs selectedScope:(NSInteger)selectedScope didChange:(BOOL)didChange];

However, I do have my limits on what is reasonable to squeeze onto one line;

[self showQuestionAndAnswer:[[[SharedData sharedModel] attributes] answerID]
                               questionID:[[[SharedData sharedModel] attributes] questionID]
                               filterID: [[[SharedData sharedModel] attributes] filerID]];

If else/if, while, for

Here is how I like to setup my if/else statements:

if (!returnData)
{
  ...
}
else
{
  ...
}

Also, I don’t include braces if the code does not require them:

if ([searchObj noSearchData])
  searchFlag = RESET;
else
  searchFlag = UPDATE;

My if/else statements look as follows, where the else if are on the same line:

if (!returnData)
{
  ...
}
else if ([httpResponse statusCode] != HTTP_OK)
{
  ...
}

As with the above, when I write while and for loops, braces stand alone:

while ([obj currentCharacter] != '?')
{
  ...
}

for (NSDictionary *dict in dataList)
{
  ...
}

Tab Stops

I prefer to indent two spaces, and always opt for space characters over tabs. For those who use tabs, is there a primary benefit of tabs that makes you choose one over the other?

Posting a Comment with Code

Please feel free to post code examples of your style. If you would like to post a comment and have your code color highlighted as shown above, using the following format:

<pre lang=”objc”>
your code here
</pre>

Passing Blocks as Parameters

Within a number of iOS frameworks, methods are provided that accept a block as a parameter. As it relates to working with blocks, this is one area where things start to get interesting and you get a perspective on a few unique features offered through blocks.

For example, in the code below, I create an array of string objects, nothing new there. However, in iOS 4+NSArray now includes a method to create a set (NSSet) object from the array by passing in a block into the indexesOfObjectsPassingTest method. The block that I’ve written checks the length of each object in the array (each is object is string in this example), and return YES, only for those objects where the string is greater than 5 in length.

// Create an array
NSArray *array = [NSArray arrayWithObjects: @"12345", @"12345678", @"abcd", @"123abc", nil];
 
// Create a set (an unordered collection of objects) with the indexes of the objects
// in the array where the length of the object in the array is > 5.
// Notice the parameter is a block.
NSIndexSet *set = [array indexesOfObjectsPassingTest: ^(id obj, NSUInteger idx, BOOL *stop)  
{                   
  if ([obj length] > 5)
    return YES;
  else
    return NO;
}];

Now that we have a set that tells us which objects are of a specified length (or greater), let’s call a method in the NSSet object that will enumerate the values in the set and print the values of the relevant array entries – the method enumerateIndexesUsingBlock in NSSet will also accept a block as a parameter:

// Enumerate the set, printing the     
[set enumerateIndexesUsingBlock:^(NSUInteger idx, BOOL *stop)
{
  NSLog(@"Array entry %d contains: %@", idx, [array objectAtIndex:idx]);
}];

The output from the above is:

Array entry 1 contains: 12345678
Array entry 3 contains: 123abc

Using Stop to End Processing

Let’s take a closer look at the definition of indexOfObjectPassingTest method in the NSSArray object:

- (NSUInteger)indexOfObjectPassingTest:
     (BOOL (^)(id obj, NSUInteger idx, BOOL *stop))predicate

In the first example shown above, the only parameter in the block referenced was obj, where the length was compared to see if it was > 5. When you need to stop processing a block based on some condition check, you can use the stop parameter.

Let’s say we have an array of dictionary objects that contain an account number and a boolean flag that indicates if the account is active:

NSArray *arrayOfDictionaryObjects = [NSArray arrayWithObjects:
    [NSDictionary dictionaryWithObjectsAndKeys:@"1234", @"accountID", [NSNumber numberWithBool:NO],  @"isActive", nil],
    [NSDictionary dictionaryWithObjectsAndKeys:@"2345", @"accountID", [NSNumber numberWithBool:NO],  @"isActive", nil],
    [NSDictionary dictionaryWithObjectsAndKeys:@"3456", @"accountID", [NSNumber numberWithBool:YES], @"isActive", nil],
    [NSDictionary dictionaryWithObjectsAndKeys:@"4567", @"accountID", [NSNumber numberWithBool:NO],  @"isActive", nil], nil];

If we had a need to process the array and find the first account which was flagged as active, we could once again use the indexOfObjectPassingTest method of the NSArray object, passing in a block, and looking at the value of the isActive key to find the first active account:

NSUInteger activeAccount = [arrayOfDictionaryObjects indexOfObjectPassingTest: ^(id obj, NSUInteger idx, BOOL *stop)                                                                        
{            
  NSNumber *num = [obj valueForKey:@"isActive"];
  if ([num boolValue] == YES)
  {
    // Stop processing the block
    *stop = YES;
 
    return YES;
  }
  else
    return NO;
}];

Notice how once the condition is met, we set the stop value to YES, this will stop any further processing of the block (after the ‘return YES’ statement or course).

Blocks and Enumeration

Enumeration is a common operation on objects, and there are numerous variations of block operations to help. In the code below I create a dictionary of timezone abbreviations and their names:

// Create dictionary of timezone abbreviations and names
NSDictionary *dict = [NSTimeZone abbreviationDictionary];
NSLog(@"Abbreviations: %@", dict);

The output from the above looks like this:

Abbreviations: {
ADT = “America/Halifax”;
AKDT = “America/Juneau”;
AKST = “America/Juneau”;
ART = “America/Argentina/Buenos_Aires”;
AST = “America/Halifax”;
…
}

We can now enumerate over the dictionary keys and objects, using a block, to print out the abbreviations that have the prefix “America”:

[dict enumerateKeysAndObjectsUsingBlock:^(id key, id obj, BOOL *stop)
{
  if ([obj hasPrefix:@"America"])
    NSLog(@"America Timezone: %@", key);
 
  // To view all key/value pairs
//  NSLog(@"Key: %@ Value: %@",key, obj);
}];

The American timezones are shown as:

America Timezone: EDT
America Timezone: AST
America Timezone: PET
America Timezone: CLST
America Timezone: PST
…

Let’s look at one more example using the same dictionary that was defined above, where one value in the dictionary is the account number and one indicates if the account is active:

NSArray *arrayOfDictionaryObjects = [NSArray arrayWithObjects:
    [NSDictionary dictionaryWithObjectsAndKeys:@"1234", @"accountID", [NSNumber numberWithBool:YES],  @"isActive", nil],
    [NSDictionary dictionaryWithObjectsAndKeys:@"2345", @"accountID", [NSNumber numberWithBool:NO],  @"isActive", nil],
    [NSDictionary dictionaryWithObjectsAndKeys:@"3456", @"accountID", [NSNumber numberWithBool:YES], @"isActive", nil],
    [NSDictionary dictionaryWithObjectsAndKeys:@"4567", @"accountID", [NSNumber numberWithBool:NO],  @"isActive", nil], nil];

To print the active accounts from the array of dictionaries, (notice for this example both the 1st and 3rd entries are set as active), we can enumerate the array using a block and check the value of the “isActive” key in the dictionary:

[arrayOfDictionaryObjects enumerateObjectsUsingBlock:^(id object, NSUInteger index, BOOL *stop) 
{
  // Print the active accounts:
  if ([object valueForKey:@"isActive"] == [NSNumber numberWithBool:YES])
    NSLog(@"Active account: %@", [object valueForKey:@"accountID"]);
}];

The output is shown as:

Active account: 1234
Active account: 3456

Recursion and Blocks

Writing a recursive block is pretty straight-forward. Let’s look at a few examples.

Calculating factorials is a common example when speaking recursion. 4 factorial is expressed as 4!, which evaluates to the sum of 4 * 3 * 2 * 1. A block variable below is defined to calculate factorials:

__block int (^factorial)(int);
 
factorial = ^(int x)
{
  if (x <= 1)
    return 1;
 
  return x * factorial(x - 1);
};  
 
int y = 4;
NSLog(@"%d factorial is: %d", y, factorial(y));

There is really nothing special about recursion and blocks, with the one important exception, the __block modifier is required in the definition of the block.

A discussion on recursion wouldn’t be complete without visiting the Fibonacci sequence. If it’s been a while, the Fibonacci sequence goes as follows:

0 1 1 2 3 5 8 13 21 34 21…

where the next number in the series is the sum of the previous two values: 0 + 1 = 1; 1 + 1 = 2; 1 + 2 = 3 etc.

The sequence is written as:

A partial series follows:

Below is block that will generate a value in the Fibonacci sequence:

__block int (^fibonacci)(int);
 
fibonacci = ^(int y) 
{
  if (y == 0)
    return 0;
  else if (y == 1)
    return 1;
  else
    return fibonacci(y - 1) + fibonacci(y - 2);
};

To get the value for F7:

int x = 7;
NSLog(@”Fibonacci: %d”, fibonacci(x));

The output is: Fibonacci: 13

What's Next...

Honestly, I'm not quite sure where this will go next - callbacks and view animations/transitions might be a good direction...

A block is really nothing more than a chunk of code. What makes them unique is that a block can be executed inline as well as passed as an argument into a method/function. Blocks can also be assigned to a variable and called as you would a C function – this, along with a few other topics will be covered in this post.

Block Variable

To define a block variable, the ^ operator is used. Let’s look at a simple block that will return YES/NO based on whether the passed in integer is an even or odd value:

// Defining a block variable
BOOL (^isInputEven)(int) = ^(int input) 
{
  if (input % 2 == 0) 
    return YES;
  else 
    return NO;
};

The diagram below describes each section of the block:

To call the block look similar to a C function call:

// Call similar to a C function call
int x = -101;
NSLog(@"%d %@ number", x, isInputEven(x) ? @"is an even" : @"is not an even");

The output for the log statement is:

-101 is not an even number

Blocks and Variable Scope

Notice in the block below that the code in the body references the variable ‘price’ which is defined outside the block.

float price = 1.99;
 
float (^finalPrice)(int) = ^(int quantity) 
{
  // Notice local variable price is 
  // accessible in the block
  return quantity * price;
};
 
int orderQuantity = 10;
NSLog(@"Ordering %d units, final price is: $%2.2f", orderQuantity, finalPrice(orderQuantity));

The output for the log statement is:

Ordering 10 units, final price is: $19.90

Let’s change the price and run the block again:

price = .99;
NSLog(@"Ordering %d units, final price is: $%2.2f", orderQuantity, finalPrice(orderQuantity));

Seems changing the price should update the return value from the block, however, during the block definition the price variable is set to a const, so the output remains the same as before:

The output for the block, with the price variable updated is:

Ordering 10 units, final price is: $19.90

Using __block Storage Modifier

To allow a variable defined outside a block to be mutable, apply the __block storage type modifier:

// Use the __block storage modifier to allow changes to 'price'
__block float price = 1.99;
 
float (^finalPrice)(int) = ^(int quantity) 
{
  return quantity * price;
};
 
int orderQuantity = 10;
price = .99;
 
NSLog(@"With block storage modifier - Ordering %d units, final price is: $%2.2f", orderQuantity, finalPrice(orderQuantity));

The output for the block, with the price variable updated is:

With block storage modifier – Ordering 10 units, final price is: $9.90

Typedef and Blocks

Before we get to typedef, let’s look at two different ways to define a block variable. In the examples above, the block, parameters and body are defined in one fell swoop:

BOOL (^isInputEven)(int) = ^(int input) 
{
  if (input % 2 == 0) 
    return YES;
  else 
    return NO;
};

This is equivalent to creating a block definition:

BOOL (^isInputEven)(int);

and at some point later, defining the body:

isInputEven = ^(int input) 
{
  if (input % 2 == 0) 
    return YES;
  else 
    return NO;
};

This above is important, as it may make sense at some point to have the same signature for two distinct blocks. This is where the typdef comes in – a best practice is to use typedef if the same block signature is used for two or more unique operations:

For example, below a typedef is defined for a block that accepts two objects and returns an NSComparisonResult:

typedef NSComparisonResult(^CompareObjects)(id, id);

NSComparisonResult is an enum that can be used to indicate the ordering of items (ascending, descending, same).

With the typedef in place you could now write two blocks, both accepting objects, however each performing a different comparison:

CompareObjects compareAccountBalance = ^(id objectA, id objectB) 
{
  // Do comparisons here...
 
  // return NSComparisonResult value (NSOrderedAscending, NSOrderedSame, NSOrderedDescending)
};

Here is another block with the same signature, however, there you could change up the logic for comparing the objects:

CompareObjects compareAccountActivity = ^(id objectA, id objectB) 
{
  // Do comparisons here...
 
  // return NSComparisonResult value (NSOrderedAscending, NSOrderedSame, NSOrderedDescending)
};

Summary

This post covered the basics of blocks, including block variables, the __block storage modifier and using typedef to define a block.

In an upcoming post we’ll look at a few more interesting aspects of blocks, such as passing a block as a parameter to a method, enumeration with blocks, as well as using recursion in a block.

The @class directive sets up a forward reference to another class. For example, in the code below the reference to @class HomeBrewRecipes informs the compiler that HomeBrewRecipes is indeed a class, so when the compiler gets to line 10 no additional information is needed, it assumes all is well and forges ahead.

1
2
3
4
5
6
7
8
9
10
11

//
//  HomeBrewBook.h
//
 
@class HomeBrewRecipes;
 
@interface HomeBrewBook : NSObject  
{  
  int  pageCount;
  HomeBrewRecipes  *recipes;  
}

When HomeBrewRecipes class is actually referenced, for example an instance of the class is created, the class interface will need to be imported – put another way, the class that creates an instance of HomeBrewRecipes will need to include HomeBrewRecipes.h, as is shown in the example below:

//
//  HomeBrewBook.m
//
 
#import "HomeBrewRecipes.h"
 
@implementation HomeBrewBook
 
- (void)someMethod
{ 
  recipes = [[HomeBrewRecipes alloc] init];
 
  ...
}
 
@end

What Not Just Always Import?

In many cases you can import the interface file and achieve the same end result.

 
#import "HomeBrewRecipes.h"
 
@interface HomeBrewBook : NSObject  
{  
  int  pageCount;
  HomeBrewRecipes  *recipes;  
}

So why bother with @class? The primary reason is to avoid circular references, and the problems of tracking down errors generated by the same. For example, if Class X imports Class Y, and Class Y imports class X, there’s a good chance you may run into a compile time error.

There are exceptions where you will need to import the relevant .h file(s) versus using @class – if in the example above we needed to reference a method in HomeBrewBook within HomeBrewBook.h, the compiler would need the specifics on the method call (its parameters, etc).

Best Practice

To keep things consistent in your code, I would recommend you use the @class directive to make a forward reference to classes within interface files (like the first code example) and only import the .h file if needed.

Introduction

Protocols can be helpful in a number of scenarios, a common usage is to define methods that are to be implemented by other classes. A familiar example is when using a tableview, your class implements the cellForRowAtIndexPath method which asks for cell content to insert into a table – the cellForRowAtIndexPath method is defined within the UITableViewDataSource protocol.

Let’s walk through a very simple example of defining and adopting a protocol.

Protocol Definition

Here is an example of a protocol which includes one method, notice the instance variable delegate is of type id, as it will be unknown at compile time the type of class that will adopt this protocol.

#import <Foundation/Foundation.h>
 
@protocol ProcessDataDelegate <NSObject>
@required
- (void) processSuccessful: (BOOL)success;
@end
 
@interface ClassWithProtocol : NSObject 
{
 id <ProcessDataDelegate> delegate;
}
 
@property (retain) id delegate;
 
-(void)startSomeProcess;
 
@end

Protocol Implementation

Inside the implementation section for the interface defined above we need to do two things at a minimum – first synthesize the delegate instance variable and second, call the method defined in the protocol as needed (more on that in a moment).

Let’s look at a bare bones implementation of the ClassWithProtocol.m:

#import "ClassWithProtocol.h"
 
@implementation ClassWithProtocol
 
@synthesize delegate;
 
- (void)processComplete
{
  [[self delegate] processSuccessful:YES];
}
 
-(void)startSomeProcess
{
  [NSTimer scheduledTimerWithTimeInterval:5.0 target:self 
    selector:@selector(processComplete) userInfo:nil repeats:YES];
}
 
@end

Understand this is a rather contrived example – the intention is to show how/where one might use a protocol. For the sake of discussion assume you have a class that is processing (or downloading) some type of data. Further, assume this class is called from another class to begin the processing. Chances are, at some point the caller will want to be notified that the class processing the data is done, this is where the protocol comes in.

In the calling class, the method defined in the protocol, processSuccessful, will be implemented and will be called from the object doing the processing, once it is complete.

For this example, inside the class where the protocol is defined, I have one method, startSomeProcess, which simply starts a timer and calls processComplete after 5 seconds. Inside processComplete the calling object will be notified through its delegate that the process is done.

Adopting the Protocol

To keep the example short, I am using the applicaton delegate as the class that adopts the protocol. Here is how the app delegate looks:

#import <UIKit/UIKit.h>
#import "ClassWithProtocol.h"
 
@interface TestAppDelegate : NSObject <UIApplicationDelegate, ProcessDataDelegate>
{
  UIWindow *window;
  ClassWithProtocol *protocolTest;
}
 
@property (nonatomic, retain) UIWindow *window;
 
@end

A few things to note – ProcessDataDelegate is defined as part of the interface, which signifies that this class will adhere to the protocol. Looking back to the code for defining the protocol, notice that I added @required to the definition, which means that any class that adopts the protocol must implement the processComplete method (you will receive a compile warning if you don’t).

Here is the implementation of the app delegate and the required method for the protocol:

#import "TestAppDelegate.h"
#import "ClassWithProtocol.h"
 
@implementation TestAppDelegate
 
@synthesize window;
 
 UITableViewDelegate
 
- (void)processSuccessful:(BOOL)success;
{
  NSLog(@"Process completed");
}
 
- (void)applicationDidFinishLaunching:(UIApplication *)application 
{   
  // Create and initialize the window
  window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];
 
  protocolTest = [[ClassWithProtocol alloc] init];
  [protocolTest setDelegate:self];
  [protocolTest startSomeProcess];
 
  [window makeKeyAndVisible];
}
 
- (void)dealloc 
{
  [window release];
  [super dealloc];
}
 
@end

How it all works

Things goes as follows: the app delegate will create a new instance of the ClassWithProtocol object. It sets itself as the delegate and then calls the startSomeProcess method. At some point in the future, when the protocolTest object has completed its work – after the 5 second timer has fired – it will call the processSuccessful method in the app delegate to let it know it is done processing.

Download Xcode Project

You can find a complete (albeit trivial) working example here: Protocol Xcode Project

This enumeration is both faster than using NSEnumerator and is also much more concise as it relates to the syntax, resulting in code that is easier on the eyes.

The basic syntax looks as follows:

for (classType variable in expression )
{ 
  statements 
}

Fast Enumeration Forward with Array

As an example, to iterate through an array, beginning to end, it’s as simple as shown here:

NSArray *array = [NSArray arrayWithObjects: 
   @"Hefeweizen", @"IPA", @"Pilsner", @"Stout", nil];
 
for (NSString *element in array) 
  NSLog(@"Beer: %@", element);

Fast Enumeration Backwards with Array

Fast Enumeration supports using NSEnumerator objects, so for example, if you want to output the same array shown above in reverse order, call the the reverseObjectEnumerator method on the array, which will return a NSEnumerator and use that within the Fast Enumeration loop:

for (NSString *element in [array reverseObjectEnumerator]) 
  NSLog(@"Beer: %@", element);

And if you are concerned about performance of the above, you can sleep well knowing that the call to [array reverseObjectEnumerator] is evaluated only the first time through the loop.

Fast Enumeration with Dictionary

Enumerating through a dictionary is equally as simple as looping through an array – access the key as an NSString object and use that value in the valueForKey method as shown here:

NSDictionary *dictionary = [NSDictionary dictionaryWithObjectsAndKeys:
    @"Stout", @"dark", @"Hefeweizen", @"wheat", @"IPA", @"hoppy", nil];
 
for (NSString *key in dictionary) 
   NSLog(@"%@ beer example: %@", key, [dictionary valueForKey:key]);

Documentation

You can read more about Fast Enumeration here.

As an example, I was recently working with an application that required the user to take a picture with their iPhone. Once the picture was taken the application was to show the image to the user, at which point they would measure the size of an object in the image using various controls (movable lines) and a reference object in the image. Problem is, the simulator does not have much for camera functionality (obviously, there is no lens) so any picture taken shows up as a black image.

To get around this problem, I used the compiler directive below and inside the simulator section I would load an image and use the same throughout the application as if it was created from the camera.

#if TARGET_IPHONE_SIMULATOR
  NSLog(@"Running on Simulator");
#else
  NSLog(@"Running on Device");
#endif

Working with a directive such as this is really handy as you can move between testing with the simulator and a real device without having to change any code.

typedef signed char        BOOL;

From this it is clear that BOOL is actually a signed char type. This has some implications when it comes to using the YES and NO values that are typically assigned to variables of "type" BOOL. If we look a little further down objc.h you will see the following:

1
2

#define YES             (BOOL)1
#define NO              (BOOL)0

So what is the problem with BOOL and YES? In a nutshell, the problem is that variables of type BOOL can contain values other than YES and NO. Comparing for NO is not an issue since NO == 0 == NO, but comparing for YES can be tricky, especially if you are relying on 3rd party code to play by the rules. Consider this:

1
2
3
4
5
6
7

BOOL b = 37;
if (b) {
    printf("b is YES!\n");
}
if (b != YES) {
    printf("b is not YES!\n");
}

The output from this would be as follows:

1
2

b is YES!
b is not YES!

The problem arises because direct comparison with YES will fail when the value of a BOOL type is a non-zero value other than 1.

Note that ObjC (assuming the default C99 setting is enabled) also supports the bool data type, which is an intrinsic boolean type and can only be set to true or false. A safe way to convert between BOOL and bool is as follows:

1
2
3
4

// from BOOL to bool
bool b = myBOOL ? true : false;
// and back
myBOOL = b ? YES : NO;

The moral of the story is to avoid direct comparisons between BOOL types and the YES constant.

The reason for this discussion is that I recently had a need to track a few values that were tied to a specific class, not instances of the class. Given that using class variables was not an option, here’s what I did instead. First, I defined static variables for each value I needed to track. Next, I wrote methods that are private to the implementation to work with those values (think getter/setter). Caveat: there really is no such thing as a private method in Objective-C, however, you can arrive at a similar result as shown here: private methods.

The reason for choosing static variables is that the scope of these variables is limited to the class file where they are defined. In addition, static variables are not inherited by subclasses.

What follows is a short example where I use a static integer to track how many instances of a specific class are created. The interface for the class follows:

TestClass Interface

1
2
3
4
5
6
7
8
9
10
11

//  TestClass.h
//
#import <UIKit/UIKit.h>
 
@interface TestClass : NSObject 
{
}
 
+ (NSUInteger)instanceCount;
 
@end

Note that the instanceCount method is a class method. The implementation file for TestClass has a few interesting things to explore, have a look:

TestClass Implementation

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

//  TestClass.m
 
#import "TestClass.h"
 
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// Static variables 
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// Count of objects allocated
static NSUInteger instanceCount;
 
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// Private methods defined
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@interface TestClass (private)
  +(void)bumpInstanceCount;
@end
 
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// Private methods implementation
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@implementation TestClass (private)
 
+(void)bumpInstanceCount
{
  instanceCount += 1;
}
 
@end
 
/*-------------------------------------
* TestClass implementation
*-------------------------------------*/
@implementation TestClass
 
- (id)init 
{
  if (self = [super init])
    [TestClass bumpInstanceCount];
 
  return self;
}
 
+ (NSUInteger)instanceCount;
{
  return instanceCount;
}
 
@end

On line 9 notice the definition of the static variable. This variable is only accessible from within this implementation file. On lines 14-16 I define a category as a means to create methods that are private to this implementation, that is, not directly exposed to the outside world as are the contents of TestClass.h. Inside the private implementation section I have written a class method to increment the static variable.

Beginning on line 33 is the code for the TestClass implementation. Worthy of noting is line 38 where upon initializing each new object of type TestClass I call the class method ‘bumpInstanceCount’ to update the count of TestClass objects created, that is, update our static (“class”) variable.

There is one more class method ‘instanceCount’ where I return the current value of the static variable (lines 43 – 46). Notice that this method is part of the TestClass implementation rather than the category for private methods. This is the only means of accessing the static variables from outside the class.

What follows is the App Delegate code for exercising TestClass:

AppDelegate Interface

1
2
3
4
5
6
7
8
9
10
11

//  UntitledAppDelegate.h
#import <UIKit/UIKit.h>
 
@interface UntitledAppDelegate : NSObject <UIApplicationDelegate> 
{
    UIWindow *window;
}
 
@property (nonatomic, retain) IBOutlet UIWindow *window;
 
@end

AppDelegate Implementation

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

//  UntitledAppDelegate.m
 
#import "UntitledAppDelegate.h"
#import "testClass.h"
 
@implementation UntitledAppDelegate
 
@synthesize window;
 
- (void)applicationDidFinishLaunching:(UIApplication *)application 
{    
  TestClass *tmp1, *tmp2;
 
  tmp1 = [[TestClass alloc] init];
  NSLog(@"instance count: %d", [TestClass instanceCount]);
  tmp2 = [[TestClass alloc] init];
  NSLog(@"instance count: %d", [TestClass instanceCount]);
 
  [tmp1 release];
  [tmp2 release];
}
 
- (void)dealloc 
{
  [window release];
  [super dealloc];
}
 
@end

The output looks as follows:

You can extend this concept to other data types as well, for example, give it a go by experimenting with a C structure or array.

If you are interested to learn more about using categories, look over here.