// do something here

I just got the inspiration to add the following line of code to the app delegate header of my latest iPhone application:

#define  VERY_YES  YES

If you are wondering about the etymology of this, please check out the following informational message:

Where does the term “very yes” originate from?

I leave it to the imagination and creativity of my fellow developers to adapt this code to run in other flavors of C.  Please make sure to credit me if you decide to use it.

Geoffrey Goetz gave a presentation on iPhone application development at the Columbus iPhone Developer User Group on July 27, 2010. His topic was mainly a recap of some of the application approval and performance issues that were covered at the 2010 WWDC.

The most interesting part of his presentation for me was his presentation on using the Zombies feature of Instruments. We had some random crashes going on in our Basketball Statware application, and this might have helped to chase down the problem. As it was, I believe we fixed the problem by moving like named variables just sitting by themselves in the implementation files inside the class as class variables.

Are you tired of seeing the date, time (with seconds and even milliseconds), application name and other stuffs appearing at the beginning of each and every line of the debugging console? You know, the NSLog lines that you use for debugging purposes that look like this:

2010-07-22 20:42:46.998 MyApplicationName[246:207] Setting up reachability notifier
2010-07-22 20:42:47.006 MyApplicationName[246:207] Version: 0.6
2010-07-22 20:42:47.007 MyApplicationName[246:207] Checking for database
2010-07-22 20:42:47.007 MyApplicationName[246:207] Database exists

This information can be helpful, but for the purposes of my utility class that outputs the contents of a SQLite3 database table (see my blog post entitled Nicely formatted data to debugger console for iPhone SDK), this is very annoying as it takes up a lot of the debugging console window.

Well, I decided to look to see if I could output to the debugging and remove the date, time, and application name from the beginning of each line. As it turns out, I found that you cannot do this with NSLog, but luckily I found the following web page that contained the answer:

A Different NSLog() (link redacted, no longer available)

Even though the web page is for Cocoa development, there is nothing Mac OS X specific looking in there, so I copied the QuietLog function and pasted it into my NSLogTable implementation file, and now I can see much more of my nicely formatted tables since the left 33% of my screen is not filled up with useless dates, times, application names, and thread identifiers.

Here is now what my NSLogTable.m file looks like. (The NSLogTable.h file is unchanged.)

//
//  NSLogTable.m
//
 
#import "NSLogTable.h"
 
@implementation NSLogTable
 
void QuietLog (NSString *format, ...) 
{
    if (format == nil) {
        printf("nil\n");
        return;
    }
 
    // Get a reference to the arguments that follow the format parameter
    va_list argList;
    va_start(argList, format);
 
    // Perform format string argument substitution, reinstate %% escapes, then print
    NSString *s = [[NSString alloc] initWithFormat:format arguments:argList];
    printf("%s\n", [[s stringByReplacingOccurrencesOfString:@"%%" withString:@"%%%%"] UTF8String]);
 
    [s release];
    va_end(argList);
}
 
+ (void)dumpTable:(NSMutableArray *)rows
{
	int idx = 0;
	NSMutableArray *rowData;
	int colWidths[100];
	NSString *s;
	NSMutableString *ms = [[NSMutableString alloc] init];
	BOOL firstRow = YES;
 
	for (int i = 0; i < 100; i++) colWidths[i] = 0;
 
	// get the maximum column widths
	for (id row in rows)
	{
		rowData = (NSMutableArray *)row;
		for (int i = 0; i < [rowData count]; i++)
		{
			s = [rowData objectAtIndex:i];
			if ([s length] > colWidths[i])
			{
				colWidths[i] = [s length];
			}
		}
	}
 
	for (id row in rows)
	{
		[ms setString:@""];
		if (firstRow)
		{
			[ms appendString:@"     "];
			firstRow = NO;
		} else {
			[ms appendFormat:@"%4d ", idx];
		}		
 
		rowData = (NSMutableArray *)row;
		for (int i = 0; i < [rowData count]; i++)
		{
			s = [rowData objectAtIndex:i];
			[ms appendString:[s stringByPaddingToLength:colWidths[i] withString:@" " startingAtIndex:0]];
			[ms appendString:@" "];
		}
 
		QuietLog(@"%@", ms);
		idx++;
	}
 
	[ms release];
	QuietLog(@"");
}
 
@end

Here are two other fun facts I discovered about the iPhone SDK:

1. You can present a modal view controller on top of another modal view controller

This would appear to contradict fact #2 from my posting of July 13th, but I have learned some new information. In my previous attempts to stack up modal view controllers, I was sending the presentModalViewController method call to the navigation controller defined in my app delegate. For the second modal view controller, if I just send the presentModalViewController method call in the first view controller to self, all works as it should.

2. Watch your colons on delegate selectors

I was trying to wire up a cancel delegate call that passed no parameters back to the caller, since none are necessary. However, the cancel delegate that I copied and changed from the working accept delegate was never firing in the following code:

if (delegate && [delegate respondsToSelector:@selector(myDelegateCancelPressed:)]) {
    [delegate myDelegateCancelPressed];
}

After I removed the colon from inside the @selector, it worked right as rain.

I discovered (quite by accident) two things today about iPhone software development. These are things that are probably documented and discussed elsewhere, so here is yet another documenting/mentioning of them.

1. The order of stuff in Interface Builder is actually pretty important

So I am in Interface Builder, copying and pasting some repetitive stuff. I usually like to have the document window open on the left of the screen, the view open middle left, the inspector middle right, and the library on the right. And every once in a while, the stuff I pasted that showed up at the bottom of the list of controls in my view disappeared.

As it turns out, this was happening when I was subconsciously sending the newly pasted controls to the back, and as you may not know, the order of the controls as shown in a view pertains exactly to the z-order of the controls. The control that I was sending to the back going to the top of the list of controls under the view in the document window.

2. Don’t try to present a modal view controller on top of another modal view controller

The subject above says it all. If you create a view controller and use the presentModalViewController method, nothing really happens. The new view is created, but just sort of fizzles out before reaching the screen. (Or in other words, the init is called, but viewDidLoad is never reached.)

This will present a bit of a challenge, as just about every other environment I have worked in allows you to lay modals on top of other modals.

If you are trying to remove the shine effect from the icon on your iPhone application, and it is not working, check the order of items in your info.plist file.

I had the “Icon already includes gloss effects” item at the bottom of my plist file with a value of checked, but it would not get rid of the shiny icon on the simulator or on a device. I found that, after I moved the entry up to the top of the plist file, it now gave me an unshiny icon on the simulator and on a new device that I tried the software on.

My main iPod touch that I use for development still has the shiny icon even after deleting the application from the device and powering it off and back on. Anyone have any ideas why this would be?

Good news for those of you who tried to use the first revision of our Basketball Statware iPhone app and found yourself looking at a silently failing crash when you sync.

Version 1.0.1 of Basketball Statware is now available for download in the App Store. Also, a little bug was fixed up concerning visiting the event list view when you do not have any events in your game.

Here is the URL for the product:

Basketball Statware (link redacted, no longer available)

The next revision of the application is going to have more minor bug fixes and memory leak fixes, as well as a neat feature that switches between a box score summary and an extended box score summary by rotating the device from portrait to landscape mode. This is almost ready to be submitted to Apple for approval, and should be ready by the middle of July.