Accessorizer 2.0 Configuration Sets

The new version of Accessorizer is out! I’m still amazed at how many Cocoa (including iPhoneOS) developers I encounter who don’t know of this awesome utility. Here are just a few things this app does:

  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?

 

WWDC: Eat the Lunch

‘Tis the season for WWDC Survival Guides. I don’t really have anything to add from my post last year, but I want to state an opinion contrary to the prevailing common wisdom: Don’t be afraid to eat the lunches.

Digression: C4 is/was known for its excellent sit-down meals between sessions. At first, it seemed horribly inefficient to an engineer brain to get up after a session, move “all the way” to the banquet room next door, have to pick out a seat again, only to return to the session hall and have to find a new seat–why not just leave my stuff camped in the same seat all day?

But I quickly heeded Wolf’s advice-slash-admonition to find a different group of people to sit with at each change–and the world opened up. If you went to C4 just for the tech sessions, it was worth the cost but you only got the tip of the iceberg. I met well-knowns and unknowns and learned about their products, their consulting and business development experience, and got to know them without pressure. I may not even remember their names right now (I’m terrible with names) but every one of those conversations built community.

I’m not going to claim WWDC lunches will ever approach C4′s, but you can incorporate a bit of the C4 experience into WWDC: Instead of getting together with the same group for lunch every day, take at least two lunches in the cafeteria area. Find a seat at a table with other people you don’t know, and strike up a conversation to find out who they are, what they do, where they’re from. I somewhat unintentionally did this last year, and I promise you: It will open your eyes.

If you’re stuck for icebreakers, here are some old reliables:

  • “What did you think of the Keynote/’State of’ addresses?”
  • “Did you catch yesterday’s Brown Bag session?”
  • “What sessions are you looking forward to?” (earlier in the week)
  • “What was the best session you attended?” (I love this one later in the week)

Asking where someone’s from or how many WWDCs they’ve attended tend to be short answers that don’t lead to conversations. Asking about shipping software can be great–people love talking about their products–but make the interest genuine so it doesn’t feel like an interview or “I’m only asking about yours so I can tell you about mine.”

Bring your business cards. After or during an interesting discussion, ask for one of theirs and offer one of yours. Periodically review the cards you’ve received during the week to refresh your memory of names and topics–you’ll be surprised how often you’ll run into those same people later.

Keep your own badge visible as much as possible to make it easy to approach you and ask about your company or just say “your name sounds familiar, did you…?”

For more advice on networking, check out Brent Simmon’s “Advice to new developers on networking”.

For more tips on WWDC, Jeff LaMarche’s “First Time Guide” contains nothing but tips I completely agree with. (Except my serious personal aversion to sleeping in public, including on planes.) Wait, I have one extra note: Plan to stow your gear before attending the Thursday Bash. I had my laptop backpack one year, and was miserable.

[C4 dealloc]

There’s no way I’m going to fit into a tweet my feelings of Wolf Rentzsch’s announcement of the end of the C4 conference.

Last year was the first I’d managed to go to C4. I was glad I was attuned enough to the community to get into the short registration window; I was overloaded and overwhelmed by the conference itself and the people I met; I was desperately hoping to go again this year.

I guess I’m one of the silent apologists in regards to Section 3.3.1. I understand Apple not wanting to support backward compatibility going forward for a third-party dev environment, but I think it’s foolish of them to have called out something virtually unenforceable, and any claim of “crap apps” inherently generated from a Flash source only makes the current existence of crap apps on the App Store that much more ugly.

The speakers he brought in, the way he reacted to disrespect of a speaker, the statements he’s made in public and in person–Wolf’s decision seems perfectly self-consistent. He obviously feels Apple’s decision here affects him and the community more than I do. Even though our opinions differ, I respect his opinions and admire the strengths of his convictions.

Those same opinions and convictions gave C4 a unique character. In a time when there is a surfeit of excellent conferences to choose from, C4′s absence will leave a void.

I encourage all those who feel as strongly about Section 3.3.1 as Wolf does to start (or continue) to speak out about it. I may not be with you, but I’m not against you.

[super dealloc];

On the Zeroth Day of iPad…

I realize I’m not the typical iPhone and iPad consumer; I’m perfectly happy to pay a nominal amount for a piece of software. Being a developer, I guess that’s kind of the Golden Rule. But it’s something I’ve felt for a long time: Pay the band a decent price for the music you enjoy and they can make more; pay a developer a decent price and they can afford the time to keep improving it. (That said, I’m perfectly happy to accept promo codes for your apps, even though I don’t have an app of my own right now to return in kind.)

I attended WWDC08 (the First iPhone WWDC) with the intent of avoiding iPhone topics because I have desktop ideas. I still have those desktop ideas, but since then the iPhone work has been more available, and I’ve become more intrigued by the possibilities. I worked as a (small) part of a team on an iPad app that’s on the store today–if you aren’t averse to paying money for an app, there’s a good chance I may have a bit of code on your iPad. (The app is intentionally not in the list of apps that follow.) I am currently working on another contract for an updated iPhone version and and iPad adaptation. It’s been fascinating to watch what Apple has done with the software, as well as how others are interpreting the platform without having hardware to test. For me, apps aren’t just about whether they’re functional; they’re a way to see what the popular interface designs are, as well as how developers took things in a different direction.

I just bought a bunch of applications for my iPad, and I haven’t even touched the device yet. I held off a whole day after the iPad App Store opened–yesterday I only downloaded free apps (in case they started charging for them later) and added items to my Want List while browsing through the list. Then I realized I’m going to want to dive right into syncing and running them when I rip apart the packaging tomorrow. Then I thought it might be worthwhile to make note of why I bought them before even trying them out.

(Read the article)

Voices That Matter

I will be attending the Voices That Matter iPhone Developers Conference (attending, not speaking) here in Seattle on April 24th and 25th. If Gus Mueller and Brent Simmons can’t convince you to attend, I can’t imagine I’ll tip the balance by listing the reasons again, so I won’t try.

If for some reason you know who I am but we haven’t actually met yet, introduce yourself and let me buy you a drink. You should be able to stalk me best that weekend by following my personal Twitter account.

B9561B40-CAE0-4042-BE19-0EF8B3DCEB1B.jpg

Clean Up Your Actions

We all know how to define an IBAction:

- (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.

Practical XML Parsing

I presented “Practical XML Parsing” at the September 10, 2009 meeting of Seattle Xcoders. While there is still a touch of the initially intended distaste for parsing XML with DOM, it evolved into more of an overview and brief introduction of NSXMLDocument and NSXMLParser.

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

Software Illusionist

The only time I ever attended MacWorld Expo, I was working behind the booth for a Mac retailer in the Bay Area. It was a long and tiresome time, without the opportunity to explore the other booths. (I believe RAMDoubler might have been the show hit, to give you a Dark Ages reference point.)

Even behind the booth, I got to meet a lot of interesting people. There were plenty of independent developers even then, and many of them had whimsical titles on their business cards; I seem to recall a “Grand Poobah,” but the one title that made the biggest impression on me was “Software Illusionist.”

I remarked on the title and the gentlemen replied to the effect of, “really, that’s all it is I do–present an illusion that people find useful.” That simple statement (probably mutated somewhat through the years in my memory) was revelatory for me.

It may seem trite to say “it’s all ones and zeroes” but at some level that is all we do as developers: Find ways to organize and present data patterns to users in a manner which doesn’t require a Beautiful Mind to interpret, or make it look like a ball bouncing around an artificial rectangular constraint on screen, or make it sound like music, or convert physical stimuli to a data pattern to present later. When the user buys into the illusion and doesn’t have to hear the creaking of the mechanism, the Software Illusionist has succeeded.

To that Software Illusionist, whoever you were (or hopefully still are): Because of you, to this day I am still compelled to make my software feel like magic. Sometimes it feels like a curse, but I still consider it a blessing.

Thank you.

Happy Birthday

They say the best gifts are handmade. For my wife’s birthday last year, I came up with the idea to write a simple little “birthday card” application and slip it on her iPhone to surprise her. I scanned in some graphics from a real birthday card and digitally chopped it up and added some animation to give it that true “Made in Flash” feel, and stayed up until 1 AM working to get ad hoc provisioning working on her phone. I even had it register a protocol handler so I could send her an email while she was at work saying “click this link: <happy://birthday> from your iPhone email” and it would launch the application. It was a hit.

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.

(Read the article)

Prepping for WWDC

I’m packed for WWDC, and have mowed the lawn so it’s not a jungle when I return. Earlier this week, I began prepping my hardware to have (hopefully) everything I need. There are plenty of WWDC “survival guides” out there–most recently an excellent one from Brent Simmons–and I even tried adding some pointers of my own last year. This year, I’ve noticed some little tips and ideas which may not be obvious; they may be too close to the trip to help anybody else out, but they might help you (or me) next year. (Read the article)

« Previous PageNext Page »