I just received word that the 2.0 update to ESPN Passport–the last fruits of my contracting with the fine folks of RogueSheep before joining Black Pixel–went live on the App Store today. What started out as “add Facebook Places functionality” became a much smoother, more efficient and focused application that I was proud to have a part in.

If you’re at all interested in adding a social network aspect to your sports watching, go check it out. It’s free, but you’ll need to sign up for a free ESPN Passport login to get the most out of it (Facebook and Twitter logins add even more).

(By the way, have you tried RogueSheep’s latest app, Easy Alarms? I played no part in it, but it rocks all the same.)

There seem to be some quirks (all videos and podcasts are marked as unplayed on the device) and other behaviors I’d like changed (watching/listening to a podcast on the device doesn’t report that to the shared library). These niggles are really just small issues compared to the big advance of having access to my full library.

Thank you, iOS team!

I was going along, minding my own business, implementing a typical -tableView:didSelectRowAtIndexPath: delegate method to create a view controller, push it onto the navigation stack, and then…nothing. The view didn’t appear, and the app interface became unresponsive. Numerous pauses in the debugger showed what would appear to be normal stacks in the running of the app–no infinite recursion going on, thankfully.

The view was actually in a strange nesting of UITableViewControllers, UINavigationControllers and UITabBarControllers, so I reworked that to the bare bones of a UITableViewController pushing a freshly made UITableViewController onto its navigationController. I verified that it was being initialized properly, and that I had a valid navigationController to push onto (and other view controllers did push with the same navigationController). Still no change.

Then I added breakpoints to every UITableViewDelegate and DataSource method I’d implemented, even the trivial hardcoded ones (“return 3;” for -numberOfSectionsInTableView:) at first to ensure they were being called (they were). Thus began the tedium of following the chain of 4 or 5 calls per table row until I found the offending code.

This new table view is composed of a number of sections each composed of only one cell. The cells are designed in Interface Builder as top-level objects, and are IBOutlets of the File’s Owner View Controller. Technically, it’s one big scroll view but I’m using this design to provide some layout flexibility if the client wants to reorganize sections, and I thought it would be cool to have the dynamic scrolling of section headers, too.

Since I want the IB objects to define the layout, I determine the height of each row based on the view’s frame:

	height = CGRectGetHeight( self.playerStatsCell.frame );

The value for height of this cell (the last on the list–the others were fine) was a “whopping” 6.30104785e-38. What was going on here?!

Well, self.playerStatsCell wasn’t actually connected yet because I was testing (trying to test) one row/section at a time. Calling the frame method on a nil object seems like a normal thing to do in messaging-nil-happy Objective-C. But it’s not. The call is effectively short-circuited, and the temporary CGRect variable the return value was supposed to fill is left uninitialized, which is the bizarre height value returned by CGRectGetHeight.

This call is equivalent to:

	CGRect frame; // uninitialized struct
	frame = self.playerStatsCell.frame;
	height = CGRectGetHeight( frame );

A simple change to the following would fix it:

	CGRect frame = CGRectZero; // initialized struct
	frame = self.playerStatsCell.frame;
	height = CGRectGetHeight( frame );

(In my case, I resolved it by connecting a temporary cell object in IB.)

What did I learn from this?

1. Messaging to nil is normally fine, but definitely not for struct-returning methods.
2. Returning a cell height that is very, very tiny from -tableView:heightForRowAtIndexPath: results in “strange behavior.”

I still don’t know exactly what the app was doing while it wasn’t displaying the new table view, but now I know what to quickly look for when I can’t push a UITableViewController in the future.

Download the Corporation Unknown configuration for Accessorizer.

At a previous employer, we ran into issues where newcomers were confused by Objective-C’s memory management, especially the differences between using properties (and dot notation) and directly accessing the ivar. As you might expect, this led to many memory-related problems. I’ve long been a proponent of only using accessors to access a member unless you have a darn good reason. (And Cocoa’s ? automatic key-value observing makes it even more difficult to have a good reason not to.) In order to visibly identify accessor-vs-direct access, we instituted a naming convention to make direct access look wrong: ivars are named with an underscore prefix (“_ivar”) and properties are not. To make this even more obvious that ivars are implementation details, we declared them @private.

You may disagree with this methodology; that’s fine. But without this context, you might have a hard time understanding my configuration decisions–and why Accessorizer especially rocks in this setup.

When I first started using Accessorizer, I thought of it as a code generator, and it’s hard not to chafe at your disagreements with how code generators generate code. I’ve found that thinking of it as a code template generator makes it easier: Generate the majority of stuff you use, omit the stuff you don’t normally use, and be comfortable with the knowledge that you will regularly have to tweak its output–it’s still better than writing it from scratch every time.

Accessor Style

• “ObjC 2.0 Properties” is always turned on. Period.
• I always use the Defaults Table (more about that later).
• “Detect IBOutlets” automatically inserts the “IBOutlet” declaration into recognized subclasses. Sometimes it doesn’t identify a class I want to be an IBOutlet, but I find this to be right much more often than it is wrong.
• “Append self.view=nil” is a somewhat strangely worded option. Checking it will generate code to nil those properties identified as IBOutlets. Combined with the “-(void)viewDidUnload” checkbox to its right, it will generate a full viewDidUnload method to release your IBOutlets.
• “Assign delegates” automatically overrides your assign/retain/copy property generation setting to be “assign” for any “id” property (or others identified as a delegate form; again, I find more often right than wrong).
• I uncheck “Omit assign for scalars”. True, the “assign” is not necessary, but I find it easier to scan for “assign” when I’m code reviewing than have to think about each type and whether it is handled appropriately. (According to Apple’s documentation, “assign” is also required for garbage collection but I haven’t written any GC code yet.)
• “Assign IBOutlets” is unchecked. I guess I’m still in the “retain outlets” camp, until I bother to change my mind.
• “BOOL getter=isValue” automatically identifies a “BOOL running” property and defines the getter as “isRunning”, just as Apple recommends.

• Since I’ve primarily been coding for iOS lately, I declare my properties “nonatomic”. If/when you’re working on the desktop, you probably want “omit this”–change it or create a “desktop” configuration.
• I omit readonly/readwrite. Most of the readonly properties I create are not backed by ivars, so I find I don’t need to override this behavior often.
• I haven’t been much concerned about __weak or __strong, so I omit it. You may decide otherwise.
• “@synthesize” will create appropriate @synthesize statements when generation the Implementation. (Be sure to check “generate getter/setter”, even though it applies to @dynamic–I’ll explain later when talking about Defaults Table.)

Getter/Setter settings

Not much to say about these settings other than “Use Defaults Table”. They don’t come into play very often, since I mainly use @synthesized properties but these settings work for me when I don’t. To see the effects on generated code, temporarily switch your properties generation to @dynamic with “generate getter/setter” checked and Implementation being generated–changes will be reflected as you make them.

Dealloc

• I default to “self.property = nil” behavior; I know others disagree. If you’re one of them, simply change the option to “release” in your configuration. If you do agree, or simply want to give this way a try, make a point of removing any related KVO or NSNotification observers before these generated lines or you will receive notifications of the nil settings and you most likely don’t want that.
• “dealloc full block” is the primary reason I am not just making my configuration available without comment. If you were to just take my configuration and copy the generated code, it would break your build because I leave this deselected so it’s not in a code block. As I develop my classes, I add ivars and use Accessorizer to generate the related code. Most of the code is pretty easy to wholesale copy-n-paste, but I tend to have more logic in dealloc than Accessorizer can know about (KVO and NSNotification removal, setting delegates to nil, etc.) and I find it easier to copy this generated dealloc code into an existing method than to use this as a dealloc method and move existing behaviors into it. If you want a full dealloc method, just check the box.

Init and Undo

I’m not sure why, but I still tend to write my own init methods. Someday I’ll explore using Accessorizer for this and Undo registration more fully; until then, you’re on your own.

Defaults Table

The defaults table is used to override the “one size fits all” property generation based on the ivar’s type. I have configured every superclass of “NSMutable<Something>” to default to “copy” instead of the default “retain” in order to avoid holding reference to a mutable object when I’m expecting immutable. (This is explained in Apple’s documentation.) I don’t even use some of these classes, but when I do I don’t want to be surprised. I’m always free to edit the declaration on a case-by-case basis, but this is the behavior I want ninety-some percent of the time.

Another fun feature of the Defaults Table is the “generation” setting. If you have a class type whose behavior you tend to override often, define its generation as “dynamic”. Every time you use that class type, Accessorizer will generate an @dynamic declaration–and the accessor methods for you to use as a starting template. (This is why I check the “generate getter/setter” in the Accessor tab even though it normally won’t do anything.)

Custom Table

I don’t really use this tab, and I don’t believe any of it gets saved into a configuration set since it’s primarily for point-and-click tweaking of behavior on an ivar-by-ivar basis.

Coding Style

As I mentioned, I prefix my ivars with an underscore, so here is where I define that. By defining my ivar Prefix as “_” and Suffix as “none”, Accessorizer automatically recognizes that underscore and strips it when declaring the property. It also properly declares the backing ivar in the @synthesize directive.

• The Argument Prefix is used when generating methods like -initWith{…}. I vacillate between “a” and “none”.
• Formatting Properties: new to 2.0 is the ability to tweak whitespace in declarations more than you could in previous versions. I’m happy because now I can use my preferred “NSString* title” form; I know many others still hew to the “asterisk must bind the the variable, not type” but you’re free to change it for yourself.
• Formatting Methods: Configure the display to generate some accessor methods and experiment with these settings to see which layout you prefer. The “Tight” spacing option is actually more compressed than I like, but I find the “Spaced” option way too spread out (and I’m someone who loves whitespace). Therefore, I default to “Tight” because it’s easier to insert the few spaces I prefer than delete all the ones I don’t.
• Formatting Pragma Marks: I love me some pragma marks, but try not to go overboard with them. Feel free to experiment.
• Init Style: Apparently, “self = [super init]” is the current Apple-approved format. I’m ambivalent.

Collection Accessors, Keyed Archiving, KVO, Locking, Singleton, General and Sort

Most of these tabs are more hands-on generation of code. You need to enter a class name, and it will generate code right there–I don’t use these as frequently as accessor generation, and you can tweak the layout more directly when you do need it. At some point, I may have changed my settings from the defaults you would encounter in a new install, but I don’t really have strong suggestions for you here.

1. As its name suggests, it will generate the getters and setters for ivars you point it at. It will do this using Objective-C 2.0 @property syntax if you specify it. (I use the 2.0 syntax and revert when I want to customize a getter or setter so i can start with a “standard” usage style.)
2. Automatically recognize UIKit and AppKit classes and mark the properties as IBOutlets.
3. Recognize non-object ivars and set their properties as “assign” instead of “retain”.
4. You can configure defaults for ivar classes (all my NSString and NSData properties default to “copy” instead of “retain”).
5. Generate all the methods for collections to be nicely Key-Value Observing compliant.
6. Generate Keyed Archiving and Unarchiving methods for your ivars.
7. Generate template code for a Singleton class.

That’s really just scratching the surface, but it’s the main functionality I use. As a Cocoa developer, you truly do owe it to yourself to check it out.

What makes me (rather selfishly) consider 2.0 an awesome update, though, is a feature I requested: Configuration Sets. The request grew partly out of encountering co-workers at contracting gigs who didn’t use Accessorizer. There are so many items to customize in the application, a first use could be daunting. If I can say, “Here’s my configuration to get you started,” and pass along my exported Configuration, they’re more likely to use it. (It also helps that they can now feel confident that they can revert after experimenting with settings.)

If I’m working on multiple projects with multiple clients, I can save their specific formatting requirements and switch between Configuration Sets when I change between projects.

If your company has defined formatting standards for the aspects Accessorizer can generate, standardizing with a Configuration Set allows you to quickly bring a new team member up to speed and into compliance.

There are more aspects to Configuration Sets I’d like to see, but they fall on the “magical” end of the spectrum; Kevin has done a great job of implementing the (more than) 80% part of it.

Seriously: Why aren’t you using Accessorizer?

- (IBAction) sliderChanged:(id)sender;

For the iPhone, you can even define it without the sender if the method won’t use it:

- (IBAction) sliderChanged;

The annoyance comes when implementing the method–that generic id parameter needs to be cast to the class you usually already know it to be, resulting in either casts all over:

- (IBAction) sliderChanged:(id)sender {
   int progressAsInt = (int)([(UISlider*)sender value] + 0.5f);
   float minValue = [(UISlider*)sender minimumValue];
   float maxValue = [(UISlider*)sender maximumValue];
}

or the use of a local variable whose sole purpose is to hold the pre-cast parameter:

- (IBAction) sliderChanged:(id)sender {
   UISlider* slider = (UISlider*)sender;
   int progressAsInt = (int)([slider value] + 0.5f);
   float minValue = [slider minimumValue];
   float maxValue = [slider maximumValue];
}

Clean it up

The key to cleaning up your IBActions lies in Objective-C’s behavior of treating all objects as id at heart: Declaring a type for an object is really only beneficial to you at compilation time, warning you of possible mistyping. (It also enables autocompletion.) But that’s not a limitation, it’s something to leverage!

When you know the single class (or superclass of the family of classes), declare it in the method signature:

- (IBAction) sliderChanged:(UISlider*)slider {
   int progressAsInt = (int)([slider value] + 0.5f);
   float minValue = [slider minimumValue];
   float maxValue = [slider maximumValue];
}

If you’re one of those (crazy) people who call the action method in code, you will now be warned when trying to pass an unexpected control (e.g. a UISwitch instead of UISlider).

Added bonus: By declaring the action with a specific parameter type in the header, Interface Builder will use that information to filter available connections. Not only will you have a shorter list of actions to choose from when connecting, you won’t even be allowed to accidentally connect a UISwitch to an action expecting a UISlider.

Note: If you do clean up actions in this way for existing projects, verify your nibs afterward. Interface Builder will display a warning icon in the lower right corner of the nib window, but the CompileXIB build phase is not configured to generate these warnings by default.

After cleaning out large copyrighted material (part of a Justin Timberlake song on the title screen and a Star Wars snippet on the XQuery screen) and removing many of the Keynote build animations I like to use but which translate poorly to static images, I have made the presentation available. I didn’t record the audio, so the text may seem more terse than it really was.

• HTML export with most of the animations still intact
• Zipped archive containing:
  • Keynote 09 file
  • PDF export
  • XMLDemo source serving as the examples I showed

The one thing I had planned but couldn’t get working was for the appliction to play a song. Core Animation took enough of my brainpower at the time, and the idea of learning AudioUnit in such a short time was quickly dismissed–I would have to “ship” without that feature. But a recent post by Mobile Orchard’s Dan Grigsby showing the simplicity of AVAudioPlayer prompted me to pull the code off the shelf and give it an update.

What a dusty shelf that was. The project was configured for SDK 2.1(!) and some of the code was indicative of “tweaking until it works.” As I was updating the project for 3.0, moving code to Interface Builder and swapping lots of Core Animation code for UIView animations, it dawned on me that this has surprisingly many little tidbits of code and would be good to share.

Before even providing the download link, I will warn that this version is somewhat “build your own.” My personal version looks like this:

But since I don’t have distribution rights for the song or art, this version will get “art” (disabusing you of any notion of hiring me as a Graphic Artist) created by me, and not have a song to play. A fresh build will look like this:

When you replace the graphics with your own, and add a song named “Happy Birthday.mp3″ you will have your own customized version.

Features this little application demonstrates:

• Animate view fade in and out transitions.
• Add repeating animations to views so they “wobble”.
• Launch in full screen without status bar.
• Register a protocol handler so any “happy://” url will launch it.
• Play a bundled mp3 (taken directly from the Mobile Orchard post).
• Autorotate view using autoresizing properties.

(Ad Hoc installation before 1 AM is left as an exercise for the reader.)

Download Happy.zip

The code is BSD Licensed. Feel free to explore it, enjoy it a bit and maybe even pleasantly surprise your own significant other.

Joe has a very solid grip on the topic, and a seemingly boundless desire to both share what he’s learned and learn from others. Writing for the iPhone can be a bit disorienting at first, especially if you’re not already familiar with Cocoa; Joe is an ideal sounding board for questions you may worry might mark you as a “rookie.”

We got a preview of the course at last month’s Xcoders meeting, and I highly recommend it for anyone wanting to get up to speed on iPhone development. (Especially if you can get the discount he mentions in his post.)

Warning: If you are not an iPhone developer and don’t plan to be, you should consider skipping this post. It’s minutia you will never use, and I don’t offer a refund for your time or brain cells spent reading this.

Profile Fun

The session started off with the client stating that he couldn’t get the code running with his Developer and Ad Hoc profile on his phone (I had been giving him milestone releases signed with my Ad Hoc profile which (mostly) worked just fine). I’m still not convinced that the combination of both Developer and Ad Hoc is desirable, let alone valid, but that’s beside the point–in the absence of being able to convince myself it was invalid such that I could convince him it was, I would do my best to make it happen.

I got it working with the Developer profile pretty easily, but Ad Hoc was elusive. I installed clean copies of the mobileprovision files a few times, with and without restarting Xcode to “be sure,” but still no joy.

The real problem? The profile was for App Store Distribution, not Ad Hoc. Both kinds of profile say “iPhone Distribution” in Xcode, so no information gained there. I found it suspicious that his profile didn’t list any devices, but didn’t feel I could assume that just because he hadn’t added a device to the provision implied that it was for the App Store. As it turns out, that assumption is correct: App Store profiles can’t have devices specified, and the Program Portal won’t let you create an Ad Hoc profile without at least one device specified.

At this point, some of you may be rolling your eyes at my client–please stop. I don’t know anyone who has felt that this process and the Dev-vs-AdHoc-vs-AppStore distinction were clear when they first encountered it. Working with profiles isn’t an everyday thing; once you get it working you tend to just use it the way it is and as a result that knowledge doesn’t necessarily stay in long-term memory. Creating your own profiles also allows you to name the profile descriptively, whereas trying to determine whether someone else did it “right” is not immediately obvious. This was an interesting challenge for me, but I don’t fault him at all.

Submitting the App to iTunes Connect

So, we’ve determined that we’re working with an App Store profile not Ad Hoc, and at this point have decided to skip attempting the Ad Hoc and move on to submitting for review. The first task is to find iTunes Connect; the Program Portal User Guide says you “will find a link to iTunes Connect in the ‘Distribution’ section of the Program Portal”…but it’s a bit more hidden than that.

Fill out the overview form. Liberally click the circled question marks for descriptive help.

When I uploaded the application zip, I would be told that the application was invalid, so I clicked the “Check here to upload your binary later” checkbox to allow me to upload all the (corrected) images and continue setting information about the application. Most of that was self-explanatory, or at least answerable by my client (“How much do you want to charge?”). That checkbox is pretty magical–you can fill out everything about your app but the app itself and leave that to the last step. I plan on making that my modus operandi for every future app.

Fix the App Signing

There were still two more layers of the app submission onion I needed to peel away. The first was to figure out why my app archive was “invalid.” Once again, I did numerous clean-and-build cycles to check that the Build Output window looked like it was signing correctly and generating the files as expected. I downloaded “fresh” copies of the mobileprovision files and reinstalled them in Xcode in case all the twiddling I’d done earlier had corrupted something.

Then I finally slapped my forehead when I realized that the signing had continued to use “iPhone Developer” not “iPhone Distribution”. In the mass of build output text, I’d mentally reduced to “iPhone D” and called it a match. I went to the target’s build settings in Xcode, changed the Code Signing Entity to the “iPhone Distribution” entry, cleaned all targets, rebuilt and…it was still signing with “Developer”. No matter how many times I toggled the build setting, it refused to use a different profile.

Searching the web, I mostly found suggestions to delete lines in the pbxproj file where PROVISIONING_PROFILE and CODE_SIGN_IDENTITY were defined. After making a backup of the file, I went for the nuclear option and stripped the lines. I started Xcode back up and reconfigured the now-empty Code Signing Entity setting, cleaned targets, rebuilt and…it signed with “Distribution” finally!

As I said, I consider this a nuclear option. Future releases and projects will probably follow Craig Hockenberry’s advice for sharing projects once I get my brain wrapped around it better. Until then, “grep -v PROVISIONING_PROFILE MyApp.pbxproj | grev -v CODE_SIGN_IDENTITY > MyAppStripped.pbxproj” will help me out.

Zip the application, camelCase the zip file, upload to iTunes Connect…and the app is valid! But one more hurdle: I am told that the bundle identifier contains disallowed characters. This is relatively easy to troubleshoot: The project template of “com.yourcompany.${PRODUCT_NAME:identifier}” translates spaces in multi-word product names to an underscore (“My App” becomes “My_App”) which is not allowed. Simple troubleshoot, simple fix: As much as I would like to figure a correct way of using the variable substitution (this app changed names a few times during development), at this point I’m willing to just hardcode that last piece of the identifier to a camelCased version of the product name.

Cleaned targets, rebuilt, zipped the application, camelCased the zip file, uploaded to iTunes Connect…

SUCCESS!

So there the app sits, with a little yellow “In Review” globe in the status field. I plan to do a post discussing what I learned during the development of the app, but will wait until it’s actually approved by Apple since numerous changes and learning opportunities may still be in store.