Moo’s MiniCards were very affordable and sized just right for our purposes:

They are sized small enough that its not a burden to carry around the conference. Not everyone at Macworld wants to load up a bag full of chotskies, schwag and product materials! We found the MiniCard’s appearance and quality really attracted the attention of attendees. Also, critical to our needs each card can have one side that con be printed with a separate image. Perfect for making individual cards each have a unique promo code.

Apple allots developers 50 promotional codes per version of their application. In total we had four versions of Postage plus, SnoGlobe and RoseGlobe that we wanted to make a full set of 50 moo cards with a promo code on the back for. That was 300 unique images we needed to make and upload! Certainly a tedious process at best.

Lucky for us, we had some automation magic in our toolchest thanks to Flying Meat’s image editor Acorn and Gus’s excellent new technology project JSTalk. While there are plenty of Mac OS graphics tools that support AppleScript for automation, I have to be completely honest here. Every time I try to use AppleScript I find myself struggling with the syntax and terminology. Frequently I just give up and do whatever I was trying to accomplish manually after banging my head on the keyboard for a few hours.

JSTalk exposes Cocoa frameworks and applications for scripting and automation using JavaScript. It also performs some preprocessor shenanigans so you can write JavaScript that looks a lot like Objective-C. Being an Objective-C programmer for a good number of years now, I find this absolutely charming. I don’t have to bootstrap myself into learning a new language, especially not some crazy english-language hybrid that demoralizes me for weeks at time after it beats me over the head with my apparent lack of basic English language literacy.

While Acorn has built-in support for JSTalk, Gus has made it easy for other applications to add support as well. JSTalk also allows other applications without support to be automated using the Script Bridge.

To create the backs for our MiniCards, we started with a the image of the layout of the back of the card. Brad left an empty spot for the text :

Then I created a JSTalk script to drive Acorn. First the script reads in the promo codes from the file that iTunes Connect creates for you when you generate promo codes. Then for each of the codes, the script opens our layout image, creates a new text layer with the promo code and styles it properly. Finally, it saves the newly created image with a proper name.

Here is what the script looks like :

Now, I got a little bi-polar there going back and forth between Objective-C style brackets and plain ol’ JavaScript style function calls. You can use whatever syntax makes the most sense to you personally though.

And here is a sample of one of the generated images:

Using this technique we generated all 300 images in something like 10 minutes. Add a little time to that to create the script and it added up to a whole lot of time saved. Plus, it was way more fun than the copy/paste dance it would have taken to do this by hand.

Count me in as a fan of JSTalk. Its such a cool technology and Gus has been kind enough to develop and distribute it completely free of charge! If you develop Mac apps you should think about dropping in support for JSTalk. If you have the need to do some automated image manipulation or creation, Acorn + JSTalk may be the perfect tool to tackle your problem.

User Desire

As a user, my hope for iPhone OS 4.0 is a way for third party developers to provide background media playing applications. I understand why Apple wants to be careful with allowing any ol’ process to be granted the ability to run in the background. Sure… power users will be able to manage background processes by hand, no problem. As we have seen on the desktop though, ordinary people just don’t want to be bothered with that level of device tweaking. We have been playing with a few Android devices here at the labs and its clear its pretty easy to start installing apps that quietly add background processes that start to suck down the battery without realizing what you have done.

On the other hand, applications like Pandora on the Android phones are so much better than their iPhone equivalents. Being able to tune in that Pandora radio station and having it play in the background just like the built-in iPod application when you launch another app would change the value of these applications immensely.

My suggestion for how Apple can do this without opening Pandora’s box (zing!) is to create a media service API that allows third party apps to hand media streams off to the iPod player. So the flow would work something like this:

You launch Pandora and use their UI to navigate their music offerings. You tune in the station that suits your current mood and give a bit of a listen. Under the hood Pandora is playing their stream via this new service API that is using the iPod application to serve up the audio. Now, you get the urge to catch-up on your news and launch NetNewsWire for some tasty RSS. When Pandora’s process is terminated the music keeps on playing, because it is the iPod application that is playing the audio. Its all Apple code running in the background, managing how much power is consumed just the way Apple wants, certified to the level of quality Apple is comfortable with, but we get audio from other providers.

There are of course some wrinkles to work out. If I launch the iPod app while a background stream is running, what is ‘Now Playing’? Perhaps the iPod application shows an appropriate image indicating the Pandora app is the current offering and allows you to quickly switch to it. One can even imagine a more sophisticated approach where the Pandora app could provide a plugin bundle that hosts its UI inside the iPod app, though I doubt this is appealing to Apple. There also needs to be some interesting mechanism for the iPod application to ask the originating service for the next or previous media file so that mini-controls that can be used to control the iPod in the background work as expected. Perhaps this is solved through a call-back into a simple code-bundle provided by the third party application? I’ m confident though there is some low impact way to achieve Apple’s goals and still enrich the media-playing experience on the device.

Developer Desire

So that’s my biggest desire as an iPhone user, but what about as an iPhone developer? What I would love to see next is a basic suite of video editing APIs. The problem with the iPhone OS and video right now is that if you want to do anything to process frames of video you need to have your own code to decode the video and re-encode after you have done your processing. This is not exactly trivial code to do well and open source starting points are potentially fraught with licensing and patent peril.

Even if you roll your own codec, perhaps even getting down and dirty with some ARM assembly, you still can’t get access to the built-in hardware assist that allows Apple’s software to capture and encode video at decent performance. The last thing we want to do as an iPhone developer is invest a lot of time in developing a codec for the iPhone and find that the best we can do is H.263 at a miserable frame rate. We also don’t want to force the user to wait around in our application for an encode to finish. Once again we need some way to hand this off and allow the OS to encode in the background for us so our users are not trapped in our application waiting for their edit to finish.

A basic QuickTime derived API that would allow us to take a video file, access individual frames and provide our own sequence of frames to encode into a new movie would be just the ticket. I realize that the advanced encoders typically have licensing requirements and perhaps Apple’s current license for their iPhone software doesn’t allow for this to be opened up. Hopefully it is something that can be addressed in the next version of the OS anyway?

Surely we are in for a interesting ride with the big announcement tomorrow. No doubt the next 6 months will be an interesting one for those of playing with Apple technologies. I suspect WWDC will be chock full of new content this year!

In our chapter we cover much of the process our team went through to create Postage. Along the way we discuss some of the core concepts and models we employed while designing the user experience. There are also plenty of useful tips, tricks and small details that go into any great iPhone application.

Here is a sample of one of the figures from the book showing some of the early mock-ups of Postage :

If you are developing iPhone applications you might want to give the book a browse. Several of the other chapters are very interesting as well. My favorite is Jürgen Siebert’s treatise on fonts. He covers all kinds of great info on type, including a detailed anatomy of letterforms. If you ever wanted to start yourself down the path to claim the title of Font Nerd, his chapter would be a great place to start.

You can grab the book at Amazon or find it on the shelves of any book retailer with a decent selection of software development books.

Old Way

- (void) doMoveFromView1ToView2Animation

{

    [app beginIgnoringInteractionEvents];



    [UIView beginAnimations: @"HideView1Animation" context: foo]; 

    [UIView setAnimationDuration: kDuration]; 

    [UIView setAnimationDelegate: self]; 

    [UIView setAnimationDidStopSelector: 

        @selector(hideView1AnimationDidStop:finished:context:)];



    [self hideView1Code];



    [UIView commitAnimations];

}



- (void)hideView1AnimationDidStop:(NSString*)animationID 

                         finished:(NSNumber*)finished 

                          context:(void*)context

{

    [UIView beginAnimations: @"SwapView1AndView2Animation" context: foo]; 

    [UIView setAnimationDuration: kDuration]; 

    [UIView setAnimationDelegate: self]; 

    [UIView setAnimationDidStopSelector: 

        @selector(swapView1AndView2AnimationDidStop:finished:context:)];



    [self swapView1AndView2Code];



    [UIView commitAnimations];

}



- (void)swapView1AndView2AnimationDidStop:(NSString*)animationID 

                                 finished:(NSNumber*)finished 

                                  context:(void*)context

{

    [UIView beginAnimations: @"ShowView2Animation" context: foo]; 

    [UIView setAnimationDuration: kDuration]; 

    [UIView setAnimationDelegate: self]; 

    [UIView setAnimationDidStopSelector: 

        @selector(showView2AnimationDidStop:finished:context:)];



    [self showView2Code];



    [UIView commitAnimations];

}



- (void)showView2AnimationDidStop:(NSString*)animationID

                         finished:(NSNumber*)finished 

                          context:(void*)context

{

    [app endIgnoringInteractionEvents];

    

    [self doStuff];

}

When we embarked on WORD SPIN it was time to build something to help tackle this problem. I settled on the concept of sequences, where each individual animation is a step in the overall animation sequence. For the user example of moving from one page to the next in Postage, the new code looks like this:

New Way

- (void) doMoveFromView1ToView2Animation

{

    NSMutableArray* steps = [NSMutableArray array];



    [steps addObject: [RSViewAnimationSequenceStep stepWithTarget: self 

                                                         selector: @selector(hideView1Code) 

                                                         duration: kDuration]];

    [steps addObject: [RSViewAnimationSequenceStep stepWithTarget: self 

                                                         selector: @selector(swapView1AndView2Code) 

                                                         duration: kDuration]];

    [steps addObject: [RSViewAnimationSequenceStep stepWithTarget: self 

                                                         selector: @selector(showView2Code) 

                                                         duration: kDuration]];

    

    [[RSSequenceManager sharedManager] invokeSequence: steps];

}

What I really like about this approach is that the entire animation sequence is specified in the same location and it’s clear how many independent steps there are up front, rather than jumping from one place in the code to the next to see what the whole animation will do. Granted, you could almost achieve the same visual effect by refactoring all the “beginAnimation” code into a reusable piece. In fact, that’s how I started.

The fundamental piece of this paradigm is the sequence step. RSViewAnimationSequenceStep inherits from RSSequenceStep, a base class to define the invocation and delegation of the step. RSViewAnimationSequenceStep is primarily a refactoring of the beginAnimation and commitAnimation boiler plate (I’ve removed the definition of the helper, init, and dealloc selectors for brevity):

RSViewAnimationSequenceStep

@interface RSViewAnimationSequenceStep : RSSequenceStep 

{

    id      target_;

    SEL     selector_;

    float   duration_;

}



+ (id) stepWithTarget: (id) target selector: (SEL) selector duration: (float) duration;



- (void) invoke;



@end



@implementation RSViewAnimationSequenceStep



// helper, init, and dealloc removed for brevity



- (void) invoke

{

    [UIView beginAnimations: @"RSViewAnimationSequenceStep" context: nil];

    [UIView setAnimationDuration: duration_];

    [UIView setAnimationDelegate: self];

    [UIView setAnimationDidStopSelector: 

        @selector(animationDidStop:finished:context:)];



    [target_ performSelector: selector_];



    [UIView commitAnimations];

}



- (void) animationDidStop:(NSString *)animationID 

                 finished:(NSNumber *)finished 

                  context:(void *)context 

{

    // delegate is defined in the base class RSSequenceStep (see below)

    [delegate_ stepCompleted: self];

}



@end

The RSSequenceStep is a simple base class to define the general interface:

RSSequenceStep

@interface RSSequenceStep : NSObject 

{

    id  delegate_;

}



@property (nonatomic, assign)   id  delegate;       

    // The object that implements stepCompleted.

        

- (void) invoke;

    // Called to invoke the code necessary for the step. 

    

@end



@interface NSObject (RSSequenceStepDelegate)



- (void) stepCompleted: (RSSequenceStep*) step;



@end

RSViewAnimationSequenceStep encapsulates handling the beginning and ending of an animation, and then calls back to a delegate when complete. It is a self contained item that can be used independently. If so desired, we could stop here and have client code declare the RSViewAnimationSequenceStep, set the delegate to self, and achieve a large part of the refactoring. But the steps would still be spread apart in the code. That’s where the RSSequenceManager, and it’s implementation detail class RSSequence, comes into play, as those two handle chaining the steps together to encapsulate the entire animation.

RSSequenceManager

@implementation RSSequenceManager



// things removed for brevity



- (void) invokeSequence: (NSArray*) steps

{

    RSSequence* sequence = [RSSequence sequenceWithSteps: steps delegate: self];



    [sequences_ addObject: sequence];

    

    if ( [sequences_ count] == 1 )

    {

        [sequence invoke];

    }

}



- (void) sequenceCompleted: (RSSequence*) sequence

{

    [sequences_ removeObject: sequence];

    

    if ( [sequences_ count] > 0 )

    {

        [[sequences_ objectAtIndex: 0] invoke];

    }

}

@end

The bulk of the work, however, happens inside the RSSequence class:

RSSequence

@interface RSSequence : NSObject 

{

    int         currentStepIndex_;

    NSArray*    steps_;

    id          delegate_;

}



- (id) initWithSteps: (NSArray*) steps delegate: (id) delegate;



- (void) invoke;

    // Called to initiate the sequence. 

    

@end



@interface NSObject (RSSequenceDelegate)



- (void) sequenceCompleted: (RSSequence*) sequence;



@end





@implementation RSSequence



- (id) initWithSteps: (NSArray*) steps delegate: (id) delegate;

{

    self = [super init];



    if ( self )

    {

        steps_ = [steps retain];

        

        for ( RSSequenceStep* step in steps_ )

        {

            step.delegate = self;

        }

    }



    return self;

}



- (void) dealloc

{

    [steps_ release];

    [super dealloc];

}



- (void) invoke

{

    [[UIApplication sharedApplication] beginIgnoringInteractionEvents];

    

    currentStepIndex_ = 0;

    

    [self invokeNextStep];

}



- (void) invokeNextStep

{

    if ( currentStepIndex_ < [steps_ count] )

    {

        RSSequenceStep* step = [steps_ objectAtIndex: currentStepIndex_++];

        

        [step invoke];

    }

    else

    {

        [[UIApplication sharedApplication] endIgnoringInteractionEvents];

        

        [delegate_ sequenceCompleted: self];

    }

}



- (void) stepCompleted: (RSSequenceStep*) step

{

    [self invokeNextStep];

}



@end

The sequence manager doesn’t know or care that a sequence is an animation, and a sequence also doesn’t know or care what an individual sequence step does. Those classes only assume that a sequence step’s ending can, but doesn’t have to, come later than its beginning. Given that, we’ve also implemented other sequence step subclasses: one that is a simple selector call, one that encapsulates multiple simultaneous steps, and one that handles openGL animations. I’ve pared the code down a fair bit for this posting, and left out detail — for example, our view animation step handles delays, custom timing functions, and transitions. But the basic idea is all there.

Lastly, Joe Conway over at the Big Nerd Ranch posted a blog about this problem, and described a solution using a subclass of CALayer that calls completion targets for a given animation key. I like his approach because it theoretically handles all the different kinds of animations, and I’ll be thinking about how to work his idea into our sequences.

One of our applications was just rejected about halfway through the review process and it seemed like a unique enough situation that it was worth sharing as a warning to our comrades in the trenches.

Over the past couple of weeks, there have been several reports of iPhone Apps being rejected for use of private APIs. Many of the rejections are from developers that have used the extremely popular Three20 library from ex-iPhone developer Joe Hewitt. The developing consensus is that recently Apple has started using a static code analyzer to flag applications that have used private API calls.

We use a bit of the code from the Three20 library in Postage and caught wind of the issues people had while getting through the review process right before we submitted a new edition of Postage and a couple of related updates. We discovered that even though we didn’t explicitly use the offending code from the library, it was still being linked into our executable because it was in an Objective-C category that added functionality to existing classes. We quickly removed the private API calls from our copy of the library and submitted our new application and updates to Apple.

Nonetheless, we found out earlier this week that our new application was rejected for private API use. The notice from Apple indicated that we had used a private method of

Once again none of our code or the portions of the Three20 library we used actually exercised this method, but it would appear that the act of compiling and statically linking brings in all the category methods contained in the included headers. I believe that in this case, the category method overrides the built in method, so I’m left with the impression that even if we had been exercising the method in question it would have not been actually using the private API.

While this namespace collision problem is often a topic of debate and pain already among Cocoa developers, those of us developing on the iPhone apparently need to take some extra care now because simply choosing the name of a private API method for your own category method name could result in App Store rejection. Even if you are careful to prefix your own category methods, be sure to take extra caution when incorporating foreign code into your project.

Hopefully this and other possible false positive problems with the new code analysis portion of App Store submissions will be addressed soon. Personally, I’d love to see Apple give us access to the analysis tool to run against our own builds before submission. Or if that’s not possible, perhaps a modification to the review process so this automated analysis happens sooner in the process so we don’t lose so much ground in the now 14-day wait for the review process to complete.

UPDATE :

After looking at a class-dump of the 3.0 frameworks It looks like

(Thanks to Andrew Wooster)

TapLynx lets you create an iPhone media application without a lick of Objective-C or Cocoa code. Using the SDK you can link against the TapLynx library, configure a plist, edit a few HTML files and in an amazingly short amount of time you’ll have a custom application presenting content from a variety of sources. The framework is adept at displaying, text, image and video content. The user interface is highly configurable and offers a variety hooks to customize the appearance.

I took it for a spin this morning and was able to produce this RogueSheep vanity application that featured content from this blog as well as the @postageapp twitter feed in something like 15 or 20 minutes :

Two nifty features :

• You can add custom tabs running your own code if you have Cocoa expertise.
• The application configuration can come from a URL, allowing the content and style to update dynamically without submitting a new application instance to the App Store. You can even add new tabs this way!

This is a great addition to any iPhone developer’s toolbox. We are already looking at ways this can help us with several of our clients. Thanks Brent!

This program is offered in 3 parts, with the first class that introduces objective-C and Cocoa starting this fall. Our good friend Hal Mueller is teaching the first course. The advisory board for this program is comprised of many of the best and well-known Mac and iPhone developers in the region, so you know the content is going to be great.

If you are in the Seattle area and looking to become a master of Cocoa and Objective-C, you don’t want to miss out on this opportunity. I know that the classes will fill up quick, so apply soon.

Should be an exciting time for Apple fans with a new MacOS, likely new iPhone hardware and the fresh iPhone OS 3.0. Who knows, maybe even Steve Jobs will descend from the heavens in a divine return to the the helm of the big fruit? I hope to see many of you reading this there.