Things that were not immediately obvious to me

I’d previously presented some code that made deep copies of plists. I recently discovered that this code is superfluous, due to the CFPropertyListCreateDeepCopy method. You can invoke this function with a call such as this:

testData = CFPropertyListCreateDeepCopy(kCFAllocatorDefault, [NSDictionary dictionaryWithContentsOfFile:path], kCFPropertyListMutableContainersAndLeaves);

(This assumes that path has previously been set to something meaningful, and that testData will later be used for some good purpose.)

Better late than never, I suppose.

Today, I learned that a cool “new” C feature had snuck up on me. This was added in C99, and it has apparently been integrated into Objective-C (where I stumbled across it) as well. Briefly, this sort of thing is now legal:

void quux(int x)
{
    char someArray[x];    // Illegal in K&R or ANSI C, ok in C99

    ...other, less interesting code...
}

(Previously, “x” would have had to be a constant that could be determined at compile-time.)

I guess I should pay more attention to this sort of thing.

Today it’s just a quick note on using the iPhone’s camera to take pictures from within your app. They’ve made this really easy. Begin by reading the section in the iPhone Application Programming Guide that covers the UIImagePickerController class.

That documentation provides the following code snippet, which works pretty well (with two caveats):

-(BOOL)startCameraPickerFromViewController:(UIViewController*)controller usingDelegate:(id<UIImagePickerControllerDelegate>)delegateObject
{
    if ( (![UIImagePickerController isSourceTypeAvailable:UIImagePickerControllerSourceTypeCamera])
            || (delegateObject == nil) || (controller == nil))
        return NO;
 
    UIImagePickerController* picker = [[UIImagePickerController alloc] init];
    picker.sourceType = UIImagePickerControllerSourceTypeCamera;
    picker.delegate = delegateObject;
    picker.allowsImageEditing = YES;
 
    // Picker is displayed asynchronously.
    [controller presentModalViewController:picker animated:YES];
    return YES;
}

Two things to note:

1. This code allocs a UIImagePickerController, but never releases it. The release is assumed to happen in the same delegate code that dismisses the modal view. This seems an odd arrangement to me, and I think you could (auto)release the controller in this code just as well.
2. The delegate of a UIImagePickerController must actually adopt the UINavigationControllerDelegate protocol as well as the UIImagePickerControllerDelegate protocol. I don’t know much about the UINavigationControllerDelegate protocol, but its methods seem to be optional; at any rate, sticking it into the list of protocols adopted by the delegate, with no other changes to the code, seemed to work ok.

A while back I wrote about some Core Graphics code that gave rise to memory management errors when (a.) compiled for iPhone OS 3.0 and (b.) run on the iPhone Simulator; the core of the problematic code looked like this:

UIGraphicsBeginImageContext(CGSizeMake(300,44));
UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();

This code did not throw any errors on my device, but since I had already upgraded that device to the 3.1.2 OS, I wasn’t sure whether or not it would happen on a device running the 3.0 OS. Fortunately, Jeffrey Scofield was nice enough to test the code on his iPhone 2G, running OS 3.0.1, and report that no problems appeared.

So it looks like this is a Simulator-only problem, which means it can be largely ignored.