// do something here

I was working with my app on the device, and had built up some data that I wanted to get over to the simulator. Being the lazy developer that I am, I thought for sure that there should be a way to do this, and lo and behold, there is indeed.

To get the file from your device, open the Organizer window in Xcode, select your device from the left hand panel under Devices, and then find your application in the main part of the Organizer window under Applications. If you click the arrow next to your application, there should be an Application Data item that appears, and there is a down pointing arrow to the right. Click this arrow, and it will ask you to save the files from the device to a folder somewhere on your Mac hard drive.

Inside of this folder, you will see a Documents folder, and you should see your SQLite file there. You can then copy this file to the appropriate area for your simulator, which for me is:

~/Library/Application Support/iPhone Simulator/4.2/Applications/Your_application_UUID_here/Documents

After I copied the SQLite file to this location, I fired up the simulator, and all my data was there. Nice!

I was looking around for a view that somebody had previously put together to show a modal view to allow the selection of a date and time, and found nothing.  This seemed like something reasonable to expect to find.  Apparently, none of the umpteen thousand fart application developers have ever had a need to create a date and time picker view, or if they did, they did not feel the need to share their creation with the world at large.

So here it is.  This is what it looks like when you use it in your application:

Here is the code that you would use to instantiate the view in your parent view controller, where selectedDate is the default date that you want the view to display when it opens up:

DateTimePicker *controller = [[DateTimePicker alloc] init];
controller.delegate = self;
controller.defaultDate = selectedDate;
[self presentModalViewController:controller animated:YES];
[controller release];

To receive messages back from this modal view, you just need your parent view to follow the DateTimePickerDelegate delegate, which means you would need to have the dateTimePickerOK and dateTimePickerOK methods in your parent view.  These methods are called when the user taps the Save or Cancel buttons respectively on the modal view.  Here is what those methods could look like:

- (void)dateTimePickerOK:(DateTimePicker *)controller didPickDate:(NSDate *)date
{
    self.selectedDate = date;
    [self redrawDate];
 
    [controller dismissModalViewControllerAnimated:YES];
}
 
- (void)dateTimePickerCancel:(DateTimePicker *)controller
{
    [controller dismissModalViewControllerAnimated:YES];
}

I have put together a sample application that demonstrates the use of the date and time picker view, which also of course includes the DateTimePicker header, implementation, and NIB files.  Please feel free to use these in our own code, and if you make any cool changes to it, please let me know so that I might include them in my example or ridicule you in the posting comments.

The sample code zip file is here:

DatePickerExample

Sorry about the delay between posts, readers. I have been fighting with getting as much coded as possible with our newest iPhone application, along with fighting with bugs and crashes in our existing iPhone applications. The App Store approval process continues to baffle me to no end.

From a development perspective, one thing I learned the hard way was to make sure that the dealloc methods in the classes that you roll in Objective C need to have the [super dealloc]; come last. If it does not come last, your code may or may not have memory problems and crashes.  If you are not sure if you are always doing this last, check your classes now.

Go ahead and check, I’ll be here when you get back.

I don’t like to get strange memory crashes in my applications. So imagine my surprise today when I changed over some CFUUIDRef ivars to NSString, and as a result, I started getting some weird EXC_BAD_ACCESS messages.

For your perusal, consider listing A, where my class is being initialized with a nonatomic and retained property:

@synthesize nameString;
 
- (id)initWithData:(NSString *)inNameString
{
    self = [super init];
 
    if (self)
    {
        nameString = inNameString;
    }
 
    return self;
}

After awhile of beating my head against the wall, I changed it to look more like listing B:

@synthesize nameString;
 
- (id)initWithData:(NSString *)inNameString
{
    self = [super init];
 
    if (self)
    {
        self.nameString = inNameString;
    }
 
    return self;
}

I leave it to the reader to investigate this phenomenon. It is not too complicated, but if the subtlety is lost on you, there is always a memory based crash lurking around the corner.

Needless to say, if you are having strange memory crashes in your application, and your class looks like listing A, change it to look more like listing B. And if your app looks like listing B, it is working fine and you want to see how bad bad can really get, change it to look more like listing A.

After using my latest iPhone application on a device for a while, I was getting the following crash:

Program received signal:  “EXC_BAD_ACCESS”.
(gdb) backtrace
#0  0x33369ebc in objc_msgSend ()
#1  0x320e5248 in -[UIScrollView(UIScrollViewInternal) _scrollViewAnimationEnded] ()
#2  0x338b4a14 in -[NSObject performSelector:withObject:] ()
#3  0x320e5098 in -[UIAnimator stopAnimation:] ()
#4  0x320e4b7c in -[UIAnimator(Static) _advance:] ()
#5  0x320e4a34 in LCDHeartbeatCallback ()
#6  0x34350e60 in HeartbeatVBLCallback ()
#7  0x332e91c0 in IOMobileFramebufferNotifyFunc ()
#8  0x316532f8 in ?? ()
#9  0x33866b50 in __CFMachPortPerform ()
#10 0x338ae52a in CFRunLoopRunSpecific ()
#11 0x338adc1e in CFRunLoopRunInMode ()
#12 0x3434e1c8 in GSEventRunModal ()
#13 0x32002c30 in -[UIApplication _run] ()
#14 0x32001230 in UIApplicationMain ()
#15 0x00002ff8 in main (argc=1, argv=0x2ffff550) at /Developer/svn/MyCompany/iPhone/MyApplication/Other Sources/main.m:14

As you can see from the trace, the only mention of my code in there is the call to main.

I ran Build and Analyze from Xcode, and also set it up to run the clang analyzer on my project from the Terminal, and both of these did not find any problems in the code.

After using the NSZombieEnabled flag in the application, it came up with this message in the console:

2010-09-11 17:10:33.970 MyApplication[9321:207] ***
-[MyViewController respondsToSelector:]: message sent to deallocated instance 0x7489480

I think we finally tracked down a way to keep the error from occurring. I am guessing that the view was being deallocated and released while it was still undergoing a scroll animation. I changed my code to be like this:

[myTableView selectRowAtIndexPath:[NSIndexPath indexPathForRow:idx inSection:mainSection]
        animated:NO scrollPosition:UITableViewScrollPositionMiddle];

The application has not crashed with the same error since I changed all of these selectRowAtIndexPath calls to use the NO flag for the animated property. True, this does not fix the problem, but at this point, hiding it was good enough for me and our complaining customers.

After 9 days, my company’s second iPhone app, Football Statware, was approved on Sunday, August 22, 2010, and is available for download from the App Store.

I have already pushed an update to the application with a few minor fixes, we will see how long this update takes.

This past Friday, I submitted my company’s second iPhone application to the App Store for approval. We did not do any profiling on this application for performance or memory leaks, but hopefully it will go through without incident. Stay tuned.

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