In working with the SimpledDrillDown example in the iPhone SDK, I was walking through the code in the RootViewController class. The interface definition is shown below:

@interface RootViewController:UITableViewController
{
DataController *dataController;
}

There is a method inside the class that looks as follows:

- (void)tableView:(UITableView *)tableView
  didSelectRowAtIndexPath:(NSIndexPath *)indexPath
{
...
detailViewController.detailItem = [dataController objectInListAtIndex:indexPath.row];
...
}

The last parameter to this method ‘indexPath’ is of type NSIndexPath . Now if you look at the class reference for NSIndexPath , you won’t find the ‘row’ method shown above? What’s up with that?

This is actually a great example of Objective-C categories in use (here is a link to a previous post on categories) The UIKit has extended the NSIndexPath class (without subclassing) through use of a category. The reason for this addition is to add support for identifying rows and sections in UITableView objects.

The addition consists of a class factory method indexPathForRow:inSection: which creates an NSIndexPath object when passed in row and section values. There are also two properties available to return the row index number and the section index number.

You can find all the specifics in NSIndexPath UIKit Additions .

While scanning a few code examples inside the iPhone SDK, I bumped into something interesting. I wrote a short example to mimic what I found…take a look at the following interface declaration:

@interface SomeClass : NSObject
{
  NSString *str;
  NSDate *date;
} 
 
@property (nonatomic, retain) NSString *str;
@property (nonatomic, retain) NSDate *date;
@property (readonly) NSString *testSomething;

The only aspect that should standout is the property declaration for testSomething . Notice there is no instance instance variable tied to this declaration. This is different if for no reason other than the typical use for properties is as a shorthand for declaring accessor methods for instance variables.

So what happens if we now add an instance method, such as shown below, inside the implementation file for SomeClass (and don’t include either a @synthesize or @dynamic declaration)?

- (NSString *) testSomething
{
  return @"Foo";
}

Well, for one thing, we can now access the testSomething method using dot syntax.

SomeClass *ptr = [[SomeClass alloc] initWithStrAndDate:@"Fubar"];
...
NSLog(@"test: %@", ptr.testSomething);

This is intriguing. I couldn’t find any specific references to using properties in this manner. Is this simply a side-effect of how properties are implemented?

If you can shed any light on this, including whether this is a common/good practice, please post a comment.

I’ve been ramping up on iPhone development, and with the NDA still in place (as far as I know), I haven’t been able to blog about what I’ve written/learned. And with that, it’s been quiet in here. Too get back into this, let’s continue to spend some more time on Objective-C…

The properties feature in Objective-C is your friend. Once you’ve written a few classes and manually wrote the accessors (getters and setters), you’ll quickly understand why properties are a good thing.

In addition to automatic creation of getters/setters, there is an option to use dot syntax in place of the traditional [receiver message] format.

I want to point out one little nuance when working with properties, setters and dot syntax , that I didn’t find to be particularly intuitive.

Let’s say you have a class with an interface definition such as this:

@interface SomeClass : NSObject
{
  NSString *str;
  NSDate *date;
} 

@property (nonatomic, retain) NSString *str;
@property (nonatomic, retain) NSDate *date;
...

The implementation file might look like this:

@implementation SomeClass

@synthesize str;
@synthesize date;

...

Using this approach, with the combination of @property and @synthesize, we now have getters/setters that are automagically created for you. You can call them as expected

// Call the getter
NSLog(@"The value is: %s", [ptr str]);

// Call the setter
[ptr setStr:@"fubar"];

Using dot syntax, here is what a call to the getter would look like:

// Call the getter
NSLog(@"The value is: %@", ptr.str);

This syntactic sugar is quite handy and easy to grasp, for the most part (even more so if you come from languages such as Java).

Everything is pretty much as expected up to this point. The whole reason for this tip is to callout the syntax for the setter when using dot syntax. Logic tells me, it should look as follows:

// Call the setter, well on second thought, maybe not
ptr.setStr = @"Testing this";

Seems reasonable doesn’t it? It effectively matches the setter method of the [receiver message] approach. However, the correct syntax is:

// Call the setter
ptr.str = @"Testing this";

The first time I ran across a setter used this way I stopped, scratched my head a few times, scrunched up my face and probably mumbled something along the lines of "what the…"

As you dig deeper into Objective-C, and even more so, as you look into the examples that are included with the iPhone SDK, you’ll want to make note of this, as properties are used extensively throughout the code.

The format (for the setter) when using dot syntax takes some getting used to. However, hopefully this little tip will clear up the confusion until you are used to seeing this style of setter.

Looks as though the final release of the iPhone SDK is now available. Although there seems to be little fanfare with the transition from beta, this is a milestone none the less.

I’ve downloaded and installed the SDK and have noticed a few minor changes, from fixes in Xcode to some updated documentation and examples.

Up to this point, anything that I’ve written in regards to the iPhone has been around laying the foundation for learning to build iPhone applications, that is, information that is not specific to the iPhone SDK. Unfortunately, from comments to my original post here (to other resources on the net) even though the iPhone SDK is no longer in beta, the NDA still applies. Put another way, looks like the wait continues until I can post code examples, tips and tricks as it applies specifically to iPhone development.

On a related note, I will have to say that I am impressed with the developer related documentation that Apple has published for Cocoa to MVC to Xcode. In all my years of development, often times my experience has been that this is one areas that lacks, fortunately, not this time around.

I was having a discussion recently with a friend whom I am collaborating with to ramp up on iPhone programming. He made an interesting comment that the barrier of entry to iPhone development is pretty high. It’s not that Objective-C is difficult to learn, or that the SDK or tools are lacking, it’s really more about the transition to Cocoa development in general. For example, with Google and Android, the potential developer audience is huge (there is no Java support on the iPhone).

Honestly, I think this is a good thing for those who take on this challenge. Assuming the iPhone continues to gain market share, and businesses and consumers begin migrate to custom applications created for the device (think Apple’s App Store), this can only be a good thing for those of us who are focused on building iPhone applications.

Lastnight was the second meeting for CocoaHeads in Minnesota .

The meeting was all about Objective-C. Bob McCune , the organizer of the event, gave a talk that covered Objective-C from beginning to end. One of the most intriguing aspects (at least from my perspective) was how the group would segue into a discussion on a topic. What was quite helpful was insight from those in the group who had significant experience working with Cocoa and Objective-C.

Bob did an excellent job, covering a great deal of ground, and wrapped up with an demo of a calculator application that tied together many of the concepts. If you are new to working with protocols, I highly recommend you download and give the application a look. The example shows how you can define and implement a protocol – no better way to learn a concept than to see it in code (I’ll add a link to the code once it is posted on the MN CocoaHeads site).

Many thanks to Bob McCune for starting MN CocoaHeads , Synergy Information Systems for making the space available, and Vladan Pulec (Synergy) for adding a link to this blog from the CocoaHeads MN website.

If you live in Minnesota, are within reasonable driving distance to Bloomington (or even if not) and are interested in developing applications for the Mac/iPhone, join us on August 14th (the second Thursday of every month) for our next meeting.

Note: What follows is another post in an on-going series for developers who are interested in learning to write applications for the iPhone. The entire series can be found here: iPhone Developer .

One common complaint for many new to Objective-C is that the language lacks support for private methods within a class. There are compiler directives for instance variables: @private, @protected (the default) and @public. However, if you want to hide methods, there is no specific directives to help. The example here builds on the previous post on working with categories.

Ultimately, there is no means to make a method private in Objective-C. However, one can hide methods in a class as I show here. It’s important to understand, this still does not make the methods private, it just makes them “harder to find” if you will.

To implement hidden methods (instance and/or class) you can use categories . Let’s begin with a file called SomeClass.h, the interface definition for SomeClass.

// ===========================
// = File: SomeClass.h
// = Interface for SomeClass
// ===========================
 
@interface SomeClass : Object
 
-(void) msg;
+(void) classMsg; 
 
@end

Nothing too interesting here, simply an interface declaration for a class with two methods: msg and classMsg . By definition (of the language) both methods are publicly accessible. Now, let’s look at the corresponding implementation file shown below. Begin at the bottom where I write the implementation for the two methods above. Again, nothing new, so far. Now, if you start at the top of this file, notice how I’ve added an interface for SomeClass (similar to the interface definition above), however, I added (hidden) to the definition, which now makes the interface definition a category. Just below the definition, I write the code for the two methods in the category.

// ===========================
// = File: SomeClass.m
// ===========================
#import "SomeClass.h"
 
// =================================
// = Interface for hidden methods
// =================================
@interface SomeClass (hidden)
 
+(void) hiddenClassMethod;
-(void) hiddenInstanceMethod; 
 
@end
 
// =====================================
// = Implementation of hidden methods
// =====================================
@implementation SomeClass (hidden)
 
+(void) hiddenClassMethod
{
  printf( "Hidden class method.\n" );
}
 
-(void) hiddenInstanceMethod
{
  printf( "Hidden instance method\n" );
}
 
@end
 
// ================================
// = Implementation for SomeClass
// ================================
@implementation SomeClass
 
-(void) msg
{
  printf("Inside msg()...\n");
 
  [self hiddenInstanceMethod];
  [SomeClass hiddenClassMethod];
}
 
+(void) classMsg
{
  printf("Inside classMsg()...\n");
}
 
@end

To see what this does for us, look at the code below, followed by the screenshot:

// ===========================
// = File: Main.m
// ===========================
#import "SomeClass.h"
 
int main (int argc, char *argv[])
{
  SomeClass *ptr = [[SomeClass alloc] init];
 
  // Display message (including messages from hidden methods)
  [ptr msg];
 
  // Call a class method
  [SomeClass classMsg];
 
  // Compile warning (can't access hidden instance method)
//  [ptr hiddenInstanceMethod];
 
  // Compile warning (can't access hidden class method)
//  [SomeClass hiddenClassMethod];  
 
  return 0;
}

Notice how I can access the hidden instance and class methods from within the class. However, if I remove the comments from lines 17 and 20, to attempt access to the hidden methods, the compiler generates the following warnings:

I’m not sure if this is the only means to hide methods. If you know of another way (and have a code example), please post a comment.

The output of the application is shown here:

Download the code and give this a try within Xcode.

As an alternative to subclassing, Objective-C categories provide a means to add methods to a class. What’s intriguing, is that any methods that you add through a category become part of the class definition, so to speak. In other words, if you add a method to the NSString class, any instance, or subclass, of NSString will have access to that method.

Defining a category is identical to defining the interface for a class, with one small exception: you add a category name inside a set of parenthesis after the interface declaration. The format is shown below:

@interface ClassToAddMethodsTo (category)
  ...methods go here
@end

For example, below I’ve defined a category that adds a method to the NSString class. The method reverseString adds the capability to all NSString objects to reverse the characters in the string.

@interface NSString (reverse)
-(NSString *) reverseString;
@end

As with the @interface declaration, the @implementation section changes only in that the category name is added to the definition. Below is the implementation of the interface defined above. Notice how in both cases I added (reverse) , which is the category name I assigned.

@implementation NSString (reverse)
 
-(NSString *) reverseString
{
  NSMutableString *reversedStr;
  int len = [self length];
 
  // Auto released string
  reversedStr = [NSMutableString stringWithCapacity:len];     
 
  // Probably woefully inefficient...
  while (len > 0)
    [reversedStr appendString:
         [NSString stringWithFormat:@"%C", [self characterAtIndex:--len]]];   
 
  return reversedStr;
}
 
@end

What follows is a short example to showing how one might use the above category.

#import <Foundation/Foundation.h>
#import "NSString+Reverse.h"
 
int main (int argc, const char * argv[])
{
  NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
  NSString *str  = [NSString stringWithString:@"Fubar"];
  NSString *rev;
 
  NSLog(@"String: %@", str);
  rev = [str reverseString];
  NSLog(@"Reversed: %@",rev); 
 
  [pool drain];
  return 0;
}

The output of the above example is shown here:

Overriding Methods

Categories can also be used to override methods the class inherits, again, providing an alternative to subclassing. You can always access the overridden method using super . I would assume from an internal (compiler/code generation) perspective, this could lead to less code/overhead as compared to creating a subclass solely to override a method (caveat: I have no proof that is true).

Dividing Source Code into Separate File

Although I haven’t given this a go, categories provide an interesting opportunity to disperse the implementation of a class across one or more files. The Objective-C Programming Guide lists several benefits of this including:

  • Opportunity to group together methods that perform similar tasks.
  • Configuring classes differently for various applications, yet maintaining one set of code.

Naming Conventions

The recommended naming convention for a category is “ClassToAddMethodsTo+CatgoryName” for instance, I used the following filenames for the interface and implementation of the above category code:

  • NSString+Reverse.h
  • NSString+Reverse.m

Caveats

You cannot add instance variables to a class through a category. Also, category names must be unique across an application.

Source Code

I’ve attached the Xcode project for the above example if you’d like to give it a try.

In the next post I’ll show another example of using categories – the example will show one approach for hiding methods within in a class, as Objective-C does not offer support for private methods.