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.

I can’t imagine anyone will be hearing that news from this blog first, but I do want to acknowledge and take advantage of it. My last post felt a bit vague, even to me, about my definition of “iPhone black” and that was partly due to dancing around the NDA. While it was really tempting to be provocative, I felt it would be irresponsible for my current contract work to risk getting smacked with an NDA violation (even though I have yet to hear of an instance) and have the client’s product suffer as a result. I considered screenshots, but felt they were either singling out someone else’s application, or a simplistic straw man if I just used an Interface Builder mockup.

The definition I had in mind of “iPhone black UI” is not simply “any view whose background is black”; it is a UINavigationController whose UINavigationBar's barStyle is UIBarStyleBlackOpaque (instead of UIBarStyleDefault) and is controlling a UITableViewController whose controlled UITableView's rows have either a white or black background. If a UIToolbar is present, its barStyle is also UIBarStyleBlackOpaque. I think most people understood that, but I still prefer to be explicit.

Wow, that feels great to type all those UI* prefixes in public–I encourage everyone to do so!

Brushed Metal

When Apple introduced brushed metal, I was fine with it. I was fine with it for the QuickTime Player (partly because I rarely use it on its own); I was fine with it for iTunes and Calculator.

When other apps started using brushed metal (it was as simple as a checked setting in Interface Builder) and didn’t follow the guideline of “re-creat[ing] a familiar physical device,” I would actually try to find another app. I think many of these developers tried to use brushed metal to make their app stand out, but I agreed with Apple’s HIG that it made many apps look “too heavy” and, while I can’t recall specific examples, I remember it just not behaving as well for visual cues of backgrounded windows.

When brushed metal bled into Safari and iChat, I started hacking their nibs to disable the brushed metal; when it infected the Finder I discovered UNO and disabled it across the board (UNO also had the advantage of enabling the then-nascent “unified toolbar” interface look, which I really liked).

I rather like the idea of a “look” or “mode” which adds contextual information about the app itself, but when people use it with abandon, it loses its contextual purpose. In interior design, there is the concept of an accent wall: A wall (usually) painted a bolder color than the other walls to draw attention and break up the uniformity of the room without domination of the bold color. More than one accent wall in a room, and the room is split-color; all of the walls the accent color, and it’s no longer the accent color–it is the room color. This is what I feel happened with brushed metal.

iPhone Black

If you can remember back that far, think about a stock iPhone devoid of App Store purchases. Phone, Mail, Text, Calendar, Maps, Safari, Settings, and half the tabs in Clock–gray status bar, blue navigation and toolbars. Black is used in the tab bars, and indicates that the icons here behave differently from a toolbar (again, modes). Yes, there are a few “variants”–the Stopwatch and Timer tabs of Clock, Photos, and iPod while playing. These are all fullscreen uses, with the apparent intent to blend the controls into an unobtrusive background.

But notice how even the iPod application uses blue navigation bars when in table/list mode. I don’t believe there is a single Apple application with a black navigation or toolbar displaying a table view. Yet, that is exactly what many third-party applications are doing.

I must confess that when the App Store finally opened, I hadn’t really dived into the SDK very deeply. When I saw the first “black UI” app, I was amused at the work the developer must have done to override the standard color just to make it “sexy black.” Obviously, I didn’t know at the time that black was just another option in Interface Builder. Now I know, and it’s apparent by the large number of applications with the black UI.

WWAD?

As an iPhone user, I appreciate the consistency of interface among the applications. Gratuitous use of a black UI only serves to distance an application from this smooth interface flow–maybe not as bad as a yellow, green or pale blue background, or an application that doesn’t even use standard navigation, tool and tab bars–but distanced nonetheless. Ironically, as more applications use the black UI, any one app using it is no longer differentiated–it’s now just noticeably “not Apple.”

Maybe I’m just not good enough about developing bleeding edge user interface; I consider myself to be more in line with “WWAD?” than “WWPD?” I’m not going to call out any specific apps as looking bad because of this, but I will give one positive comment: I think Twitterrific is one app that has a really good all-black look although I appreciate and prefer the “light background” preference (which I’d still like to see go all the way to standard colors).

I certainly wish Apple’s HIG had more guidance on this topic, but until then whenever I see a black UI app that doesn’t exhibit a need to take the user into a different mental mode, I consider it just as gratuitous as brushed metal.