In the previous post (on the iPhone Developer Tips blog) I demonstrated a simple debug class that I wrote to wrap some additional code around NSLog. The code allows for displaying additional information beyond the date/time stamp and process ID that NSLog outputs, specifically, the filename which calls the debug routine, and the line number where the call was invoked. I also added a few additional configuration options including an option to disable all debug messages.

You can read the rest of the tip on the iPhone Developer Tips blog.

Coming from a C development background, long before the days of integrated debuggers, printf() was the primary tool for tracking down bugs. Building on that, NSLog is no doubt helpful. However, as the amount of code in a project grows, I often find that another reference point in the output would be helpful, namely, the filename and line number where the NSLog calls originate.

This is a two part series on creating a new class that wraps NSLog to add several additional debugging features including output of the filename/path, line number information and the option to turn debug messages off/on.

You can read the rest of the tip on the iPhone Developer Tips blog.

In building a recent project I encountered an error during the linking process. I want to point out the error message and show you how this simple error can be resolved. The reason for pointing out this error is that I have no idea why this error came about…more on that in a moment.

Read the rest of this tip on the iPhone Developer Tips blog…

I want to share another debugging tip, this something that applies to the final step of building an iPhone project, linking.

I was able to successfully compile a project that I’ve been working on, however, the build process generated an error that two symbols could not be found, CGRectZero and CGRectOffset.

The figure below shows the specific error messages (ignore the first error about .objc_class_name_BirdView for now).

Read the rest of this tip on the iPhone Developer Tips blog…

I recently ran into this error message within Xcode while writing an iPhone application. I was surprised how long it took to track this down. One of the reasons this is tricky is that message implies that the error occurred in the file referenced in the error message.

Read the rest of this tip on the iPhone Developer Tips blog…

If you’ve been reading the iPhone related tips on this site, you’ll want to point your browser to my new iPhoneDeveloperTips.com blog!

I’ll continue to write tips here as well, however, the primary focus of my career is now iPhone centric, so the bulk of my writing will focus on the iPhone.

To get things rolling on the iPhone blog, I have migrated the iPhone tips shown here to the new blog. If you are the author of any comments on iPhone tips that started on this site, and have a few minutes to spare, I would encourage you to copy/paste your comments onto the new blog.

For the iPhone developers in the crowd, I hope you find the new site a valuable resource.

John

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.