I’ve been getting a great deal of interest in the iPhone developer tips section of this blog. So much that I’ve decided to move all iPhone centric tips to another blog, you guessed it, iPhoneDeveloperTips.com.

If you have ideas, suggestions or questions that might make for good iPhone tips, pass along your thoughts by commenting here or dropping me an email.

This blog won’t vaporize, however, I am in the midst of a transition after nearly 8 years in mobile development with J2ME to move the iPhone, so the pace may slow a bit.

If you are involved in working with the iPhone or Xcode as a developer, author of a book, trainer/courseware development or otherwise working on the iPhone, send me an email if you are interested in exploring the possibility of a partnership or other opportunities for working together. It’s been a good run with J2ME, where I’ve had the opportunity to work with many of world’s most prominent names in the mobile device business. I’m ready for what’s next, and this time around it’s all about the iPhone!

Apologies for the gap since my last post. It’s been a long week as my wife and I were in a serious car accident a week ago today. I’ll spare the details, however, let it suffice to say that our vacation plans didn’t include all the drama that unfolded that day. We are both on the mend and have plans for a full recovery. Let’s get back into it…

For those new to Objective-C and iPhone development, I want to point out something that might save you some time. Look at the code below:

@interface SomeClass : UIViewController
{
  ..
	UIView *containerView;
  ...
}

@implementation SomeClass
...
- (void)loadView
{
  ...
  UIView *uiView = [[UIView alloc] initWithFrame:
     [[UIScreen mainScreen] applicationFrame]];
  self.containerView = uiView;
  [uiView release];
  ...
}
...
@end

In this block of code, I am setting up a container view, that will hold several subviews. Once the assignment is complete on line 8, I release the local object uiView. Question is, how I can I get away with releasing the variable and still have access to the view in the SomeClass object? In other words, where is the retain?

First thing to notice is that the dot syntax is shorthand for accessing class instance variables using Objective-C properties. If one were to write the code without using properties (and thus, no dot syntax) the answer is obvious.

For example, the equivalent code directly calling the accessor (setter) method would look as follows:

[self setContainerView:uiView];
[uiView release];

At this point, if one was curious about where the object was retained (before the release), the obvious place to look is inside the setter, which might look as follows:

- (void) setContainerView:(UIView *) view
{
  [view retain];
  [containerView release];
  containerView = view;
}

Easy enough, the object is retained as part of the setter. What we have here is a good example of pro’s/con’s when working with properties. On one hand, properties allow for simplification and consistency in our code. On the other hand, if using properties and we request the compiler to implement the getter/setter methods (through use of the @synthesize directive) there is code created for us to implement these methods, which we never see.

Although properties are no doubt handy, as this example illustrates, it’s important to understand what is happening behind the scenes. A clear picture of the little nuances can go a long ways when it comes to debugging a thorny problem.

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.