Posts

Carolyn Helen Watson Gorby, 65, of Darien passed away on Saturday, Sept. 15 2012 at home surrounded by her family and caretakers. A memorial service will be held on Saturday, Sept. 22 at 11 a.m. at Atwood Cemetery in Valona with the Rev. Ted Clarkson officiating. A reception will follow at the family home in Valona.

She is survived by her sons, Jason Hunter Gorby of Atlanta and Brian Michael Gorby of San Francisco, CA; three sisters, Catherine (Paul) Glenn, Virginia Baisden, and Margaret (Craig) Toussaint; and a brother, Cliff (Sonja Rasmussen) Watson of Atlanta.

She is predeceased by her father, Hunter Atwood Watson, and her mother, Vivian Watson O’Kelley.

She worked as a school guidance counselor in Atlanta before returning to McIntosh County ten years ago. She was an avid quilter, a member of McIntosh Art Association and Dorcas.

The iOS app I’ve been working on at Eventbrite recently shipped: Easy Entry 3.0, a complete rewrite from the previous version. We shot a tutorial video starring yours truly. I also got to brush up on my GarageBand skills and put together the background music.

Here’s an unfortunately not-so-great recording of the talk I gave at Cocoa Camp last month, “Clients, Creatives, and Code: Mastering the Art of Building Someone Else’s App”.

I’ve been asked by a couple of attendees if I would make the recording available, so hopefully it will be useful to someone. I did my best to clean up the background noise, but it didn’t make much of a difference.

Code-signing during iOS app building is an integral part of the development process. Apps can only run on your iOS device if it has a provisioning profile which contains its UDID, and the app’s bundle identifier matches the profile’s app ID. The app must also be digitally signed with a certificate tied to that profile.

This signing process is used to maintain the integrity of the app during distribution. If you make an app build and modify anything in the app’s bundle, the app won’t install / run on an iOS device. iOS will see that the digital code signatures are no longer valid for that bundle. A potentially good thing to ensure the end-user isn’t getting a tampered app, but the process can be somewhat of a headache if you’ve got a compiled app you just want to run on devices not associated with the original provisioning profile / certificate combination.

It’s actually pretty easy to re-sign an app with a different signing identity / certificate using the codesign command-line tool. You give it the name of the signing identity and point it at an app, and it will regenerate the code signatures based on the certificate (assuming a valid one is found in your keychain). This is basically what Xcode does during the build process.

Since I do this pretty often, I decided to cobble together some AppleScript and make a droplet app that will automate the process even more. It’s called AppResigner.

Download it and stick it in your Dock. Then all you need to do is drag your built app onto the AppResigner icon, enter the destination signing-identity you want the app to be resigned with, and you’re done. You can also launch the app manually and select the app from there.

Where can you find the name of your destination signing identity? Open up Keychain Access and search for the certificate you want to resign with. The name of that certificate is the identity, e.g. “iPhone Developer: Brian Gorby (3EYPQ8N3KM)”. You can also just enter part of the name rather than the whole thing, so long as there’s only one certificate that matches that pattern.

If your destination certificate is in a locked Keychain, Keychain Services will intercept the process and prompt you for a password to unlock it.

I’m pretty sure you can’t (and shouldn’t) use this tool to resign an app with an App Store distribution certificate. However it works fine converting to-and-from Ad-Hoc distribution, In-House distribution, and developer certificates.

Hope you find it useful. Let me know if you run into any issues with it.

UPDATE: Nov 2, 2010 – Uploaded a new version that adds support for file-paths with spaces.UPDATE 2: Feb 15, 2011 – Source now available on GitHub.

Our team consisted of a small group of rockstars who all contributed to the highly successful delivery. On the dev side of things, all the bits were pushed and honed by fellow co-worker Brad Dillon and yours truly.

Check out the app’s landing page for more information and the iTunes download link.

iPhone OS 3.1 brought several customization options to the UIImagePickerController. With 3.1, you have the ability to customize the behavior of how the camera viewfinder appears to the user, without having to hack around the UIImagePickerController’s cameraView hierarchy. This has given rise to several augmented reality applications, such as the Monocle feature in the Yelp iPhone app.

I’ve been experimenting with a similar augmented reality prototype for a client recently, and was trying to mimic the full-screen viewfinder you see in Yelp’s Monocle. It was easy enough to set up the UIImagePickerController to display the viewfinder and remove the camera controls:
UIImagePickerController *imagePicker = [[UIImagePickerController alloc] init];
imagePicker.delegate = self;
imagePicker.sourceType = UIImagePickerControllerSourceTypeCamera;
imagePicker.showsCameraControls = NO;

However, this gives you a black bar with a height of 56px in the space the camera controls once occupied. To remove the black bar, you actually have to apply a scale transformation to the camera view using the cameraViewTransform property. The scale I’m using is 1.132, which is just enough to cover the 56px gap:
CGAffineTransform cameraTransform = CGAffineTransformMakeScale(1.0, 1.132);
imagePicker.cameraViewTransform = cameraTransform;

It’s a 13% scale, which is only slightly noticeable if you’re comparing the same scene through a non-scaled viewfinder. This transformation will apply to any pictures you might try to take programmatically with -takePicture.

From here, just display / release your UIImagePickerController as you normally would, and you should have a full-screen viewfinder. This only works on iPhone devices, as neither the iPhone Simulator nor the iPod Touch will support the UIImagePickerControllerSourceTypeCamera sourceType.

If you’re looking to build an app that can selectively enable this functionality at run-time, you can test for the sourceType compatibility of the device with +isSourceTypeAvailable:.

One of the neat features of Objective-C programming is categories. Categories give the ability to add discrete bits of functionality on existing classes. Think of them as lightweight inheritance; I can add one or more methods to an existing class without having to create a custom subclass. There’s a bunch more you can do with categories as described in the Mac Dev Center.

In a current project I’m working on, I’m dealing with many arrays whose objects need to be in a random order. There are many ways of accomplishing the randomization of array order, but having implemented the Fisher-Yates shuffling algorithm in other languages and projects, I decided to implement an Objective-C version of it. It’s a deceivingly simple algorithm, and there’s a great post on why the Fisher-Yates method beats the pants off a naive shuffling algorithm over at Coding Horror.

I decided the easiest implementation would be add the category directly into NSArray and NSMutableArray. This way all the shuffling logic is fully encapsulated within those classes. Another article got me started on how to do this with the shuffling algorithm I wanted to use. This got me 90% the way there.

Basically all you do is create a new header and implementation file. For the interface, you define the new category and methods for both NSArray and NSMutableArray:

Or automatically shuffling a collection of songs a user has picked using the MPMediaPickerController (you can also shuffle songs using the shuffleMode property of the MPMusicPlayerController, but they don’t get shuffled until they are played):

// mediaItemCollection.items is an NSArray,
// so we create a new MPMediaItemCollection using -shuffledArray.
MPMediaItemCollection *shuffledCollection = [MPMediaItemCollection collectionWithItems:[mediaItemCollection.items shuffledArray]];

// Now we've got a new collection of shuffled items.
[self playMediaCollection:shuffledCollection];
}

I’ve glossed over many details here here in an attempt to show a practical use for categories and shuffling. If you’re interested in learning more, I’d recommend checking out the links in this post. They are excellent references.

One of the more interesting features that was announced during the preview of iPhone OS 3.0 was the GameKit framework.

The video above is just a simple demo I wrote a few months ago with a beta version of GameKit and the cocos2d-iPhone framework. The two devices discover one another over Bluetooth, coordinate the client / server relationship, and begin play. There’s currently no scoring, and my protocol implementation is highly inefficient.

While the framework provides many neat features, I was most attracted to the zero-configuration P2P over Bluetooth. Multiplayer applications were previously only possible using Bonjour over WiFi, or some roll-your-own solution over the cell network. These methods provide a significant barrier of entry when you consider that the most popular games on this platform are the pick-up-and-play / get-in-get-out kind, with a typical play session lasting five minutes or less. If I have to fiddle with my network options in order to play an ultra-casual game with you, I most likely won’t.

The bad news? Bluetooth P2P is only available on iPhone 3G and 3Gs, and iPod Touch 2G.

It has been ten whole months since I decided I wanted to make video games for a living. Since that time I’ve purchased well over $1,000 worth of books, games and consoles in an attempt to immerse myself in an arena I’ve been away from for many years.

By leveraging my existing skills, I was able to get my foot into the door as a developer for a upcoming kids-oriented MMO by day. I am also designing and programming games for the iPhone on my own. I took a little break from iPhone programming during the last quarter of 2008, but the innovation I’ve seen in other apps has brought me back to the land of Objective-C. And yes, I am planning an update for Tiny Violin.

All this is to say that I will be attending this year’s Game Developers Conference next week, and couldn’t be more excited! I’m really looking forward to meeting fellow game-makers, especially on the iPhone-front.

The folks over at Mac|Life contacted me back in early November for a short interview. They were writing an article showcasing a handful of iPhone developers and were interested in including Tiny Violin. The online version of the article was published a few weeks ago, and the print version can be found in the January 2009 issue of Mac|Life.

Many thanks to Leslie and everyone else over at Mac|Life for giving Tiny Violin all the press. And if you haven’t checked out Mac|Life before, know that you are missing out on probably the best all-things-Mac-related publication out there.