// do something here

Here’s a little nugget that I just learned about code signing your iPhone app that I probably was able to get around before by the  bumble-around-trying-everything-under-the-sun-before-stumbling-on-the-right-combination method.

Your build settings in the Target override your build settings in the project.

This is obvious to me now looking back at it, but I am very nearly 100% sure that this was tripping me up on the previous projects that I have tried to submit to the App Store.

It probably says this somewhere in the Apple documentation, but I am too tired to look for it to verify that it is in there.  Now if I can just get the UIAutomation tool in Instruments doing what I need it to do.  I used to remove the logElementTree function out of the js file after I figured out how deep something was buried in the hierarchy, but I got tired of retyping it so I just leave the line in there now and just move it down to the next block of new functionality I am trying to exercise.

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.