On October 9th, 2009 RogueSheep was approached to shoot a video by the production company Tipsy Pix and their partner Boston-based NKP Media. NKP Media is one of the top video suppliers to the big textbook publishers in the college market. The video was being shot for Cengage Learning’s best-selling textbook on marketing. The chapter in which we were asked to be a video component was Product Decisions, and we were chosen due to the fact that earlier in 2009 our iPhone application “Postage” had won the coveted Apple Design Award. Postage was a gift that just kept giving. We agreed to be a part of the video.

With our Seattle office under construction the morning of the shoot, the producers were creative and took it outside to use the scenic skyline as a backdrop. It was a perfect way to start the day. Chris Parrish and Brad Ellis were enthusiastic to talk about their product decisions, concepts and show off Postage to a few locals during the short clip. It was a gratifying experience to demonstrate the app in the wake of the huge splash it had made. The video was shot in HD and is slated to be shown all over the country at different universities in marketing classes during the 2010/2011 school year.

Tipsy Pix has produced hundreds of succinct educational documentaries and case studies of many well-known and upwardly-mobile companies. The condensed list includes: Vans, Kodak, Organic Valley, Method, Honda and Raleigh Bicycles. We were proud to join that list and enthusiastic to see the final footage.

It was a lot of fun for the company to get involved with this shoot. It is so rewarding to see something you did some of your best work on spread itself to unexpected venues. We will continue to make top-notch products with a design flair people seem to appreciate. We hope you will enjoy the video. Thank you for making Postage the success it has become!

Click here to watch the video about Postage!!!

Friend us on Facebook (Postage for iPhone) or on Twitter (@postageapp) to keep up with all the latest news, free giveaways and information on upcoming products.

I like objective-c protocols, and I am a fan of the interface oriented designs that it allows for. But, sometimes the indirection of using a selector with a defined signature just works better, and the problem is that UIAlertView does not take a selector. Instead, UIAlertView defines a protocol, UIAlertViewDelegate, that the alert’s delegate adopts to receive notification of the user intent. To be fair, UIAlertView communicates a bit more information back to it’s delegate than the target of an NSAlert, and the UIAlertViewDelegate protocol does a fine job achieving that goal. 99% of the time, however, I want to show an alert and have it call my named selector when it is done. To that end, I finally busted out the admittedly tiny class that does the job.

Now in my client code I show an alert like this:

RSAlert* alert =

    [[RSAlert alloc] initWithTitle: @"Title"

                           message: @"Message!" 

                            target: self 

                          selector: @selector(dismissedAlert:buttonIndex:)

                 cancelButtonTitle: @"OK" 

                 otherButtonTitles: nil];

and handle the result with a selector, similar to NSAlert:

- (void) dismissedAlert: (RSAlert*) alert buttonIndex: (NSInteger) buttonIndex

{

    NSLog(@"dismissedStartupAlert with buttonIndex: %d", buttonIndex);

    

    [alert autorelease];

}

I realize this is an infinitesimally small annoyance, but sometimes it’s the little things that keep us happy.

RSAlert.h

#import 



@interface RSAlert : NSObject 

{

    UIAlertView*    alertView_;

    id              target_;

    SEL             selector_;

}



- (id)initWithTitle: (NSString*) title 

            message: (NSString*) message 

             target: (id) target 

           selector: (SEL) selector

  cancelButtonTitle: (NSString*) cancelButtonTitle 

  otherButtonTitles: (NSString*) otherButtonTitles, ...;



- (void) show;



@end

RSAlert.m

#import "RSAlert.h"



@implementation RSAlert



- (id)initWithTitle: (NSString*) title 

            message: (NSString*) message 

             target: (id) target 

           selector: (SEL) selector

  cancelButtonTitle: (NSString*) cancelButtonTitle 

  otherButtonTitles: (NSString*) otherButtonTitles, ...;

{

    self = [super init];

    

    if ( self )

    {

        target_     = [target retain];

        selector_   = selector;

        alertView_  = [[UIAlertView alloc] initWithTitle: title

                                                 message: message

                                                delegate: self

                                       cancelButtonTitle: cancelButtonTitle

                                       otherButtonTitles: nil];

    

        if ( otherButtonTitles )

        {

            va_list argList;

            id anArg;

            

            [alertView_ addButtonWithTitle: otherButtonTitles];

            

            va_start(argList, otherButtonTitles);

            

            while ( anArg = va_arg(argList, id) )

            {

                [alertView_ addButtonWithTitle: anArg];

            }

            

            va_end(argList);

        }

    }

    

    return self;

}



- (void) dealloc

{

    [target_ release];

    [alertView_ release];

    [super dealloc];

}



- (void) show

{

    [alertView_ show];

}



- (void)       alertView: (UIAlertView*) alertView 

    clickedButtonAtIndex: (NSInteger) buttonIndex

{

    // Do nothing

}



- (void) alertViewCancel: (UIAlertView*) alertView

{   

    [target_ performSelector: selector_ 

                  withObject: self 

                  withObject: (id) 0];

}



- (void) willPresentAlertView: (UIAlertView*) alertView

{

    // Do nothing

}



- (void)didPresentAlertView: (UIAlertView*) alertView

{

    // Do nothing

}



- (void)             alertView: (UIAlertView*) alertView 

    willDismissWithButtonIndex: (NSInteger) buttonIndex

{

    // Do nothing

}



- (void)            alertView: (UIAlertView*) alertView 

    didDismissWithButtonIndex: (NSInteger) buttonIndex

{

    [target_ performSelector: selector_ 

                  withObject: self 

                  withObject: (id) buttonIndex];

}



@end

There has been some speculation that Apple might use the iTunes LP format for content in their “latest creation.” We don’t know what Apple intends to show off next week, let alone the content strategy for unsaid device. But let’s just assume for the moment that on Wednesday Apple reveals a tablet, and amongst the festivities they roll out support for electronic books and magazines packaged up into an iTunes LP? What does that mean?

To begin with, it probably won’t be called iTunes LP. The documentation released by Apple some time back shows that iTunes LP (.itlp extension) and iTunes Extras (.ite) are actually two specific incarnations of a general purpose package format. Apple hasn’t named the general format, so I’ll call it the iTunes Media Format. As others have pointed out, it is basically a self contained, mini-website, complete with images, videos, audio, fonts, and of course text content. Given all that, it seems possible that an eBook incarnation of the format might be called iTunes eBook (.iteb?), a magazine incarnation might be iTunes eMag (.item?), or maybe there’s a variant that does both. But will publishers really want to distribute their content in such a way? Why not PDF or EPUB format?

I think publishers will certainly entertain the idea. Although PDF represents an easy migration path right now, it is fundamentally a static page description. Adobe’s Adobe Reader Mobile SDK does support reflow, but the quality depends on the metadata within the document as well as the ability to infer page structure when none is available. EPUB is somewhat at the other end of the spectrum, it has a rich content model that intrinsically supports reflow, but layout is limited to a subset of CSS2. The iTunes media format, on the other hand, is a good compromise between both extremes — it supports HTML5 and CSS3 and can let a publisher decide where on the layout vs reflow line they’d like to be. But how will publishers author content?

That’s a great question for another day.

Our pal Brent Simmons, noted developer of the renowned NetNewsWire for the for the Mac and iPhone, has just released his latest NewsGator project into the wild : TapLynx.

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!

Some time back Adobe announced an interesting new technology for image processing on GPUs called Hydra. That technology has since been renamed to Pixel Bender and components of it are now available for the CS4 products and Flash Player 10.

Pixel Bender is very similar to Apple’s Core Image technology available on MacOS Tiger and later. Both Pixel Bender and Core Image allow developers to create image processing algorithms in a programming language that is abstracted from the hardware the filter will run on. A developer can create their image processing code in a domain-specific language and allow the runtime implementation in Core Image or Pixel Bender to implement the algorithm optimized for the hardware present in the system when the program actually runs. By leveraging the power of the modern Graphics Processing Unit on today’s common laptops and desktops these technologies offload the image processing tasks to specialized hardware, when present, and provide amazing image editing performance for the user. Often real time edits are possible for still images or video.

The two technologies are remarkably similar. Core Image of course requires the MacOS, but otherwise any application on the platform can be developed to incorporate Core Image. Its also possible for users to install Core Image filters so that all Core Image enabled applications can access the filters. Pixel Bender is currently only available in a few core Adobe applications : Photoshop, After Effects, Flash Pro and Flash Player. Having access to Pixel Bender effects in Flash Player does imply though that any application developed on the Flash platform (presumably including AIR and FLEX applications) can take advantage of the technology. The potential advantage here of course is that Flash, and therefore Pixel Bender, are cross-platform including web applications.

At the heart of each is is the concept of a ‘kernel’ which defines the core algorithm. The kernel describes how to produce a pixel of the output image given some portion of the input image. Both Core Image and Pixel Bender use a C-like language to create kernels. Both are based on the OpenGL Shading Language with the kernel an effective parallel to a fragment shader in GLSL. Adobe’s implementation seems on the surface to be a more complete implementation with less restrictions than Core Image. This can really help when trying to implement a particular image processing effect, but there is one potentially big gotcha : Pixel Bender kernels can only use a very restricted set of kernel language features when running in the Flash Player. If your target is a desktop Adobe application this should not be a problem, but if you are looking at a web application this could present problems.

Another interesting component to Pixel Bender is the idea of a processing graph that allows a developer to chain several kernels together into a single operation. This is quite useful because many interesting effects are only effectively realized as combinations of other effects. The chaining is smart in that the runtime performs analysis to make sure only the minimal amount of pixel processing is performed for a given chain. For instance if there is a crop at the end of your chain, none of the upstream filters will bother to compute output pixels that are outside the crop. Pixel Bender adds Graph language to describe and distribute these multi-pass filters (though once again this is not available in the Flash Player). Core Image includes the same concept of chaining filters with efficient execution, but only recently added the ability to persist these chains for reuse in Leopard.

I’m excited to learn more about Pixel Bender going forward. We have used Core Image extensively here at RogueSheep and have found it to be a great solution. Pixel Bender has the potential to open up some of our image processing solutions to the Windows platform or even web-based applications.

If you want to try out Pixel Bender yourself check out the Adobe Lab’s download here. They have a rudimentary IDE that lets you implement and edit a kernel and see the results live. There is also a plug-in for Photoshop CS4 that adds a Pixel Bender gallery filter which can host PB filters in Photoshop.

Also interesting is support for the visual graphics processing package Conduit from the fine minds at Lacquer. Conduit is a visual graphics processing package, similar to Quartz Composer, that can be hosted in a variety of applications. Their beta support for Pixel Bender allows you to create PB filters using their visual processing language, all without having to dirty your hands in the relatively low-level shader language. You can see some cool samples of it in action in your web browser (with the latest Flash Player).

Craig Hockenberry, developer of fine applications such as Twitterrific and other goodies over at the Icon Factory has called on developers to join his crusade to convince Apple to support virtualization on the desktop.

Currently, Apple’s licensing restrictions for the Mac OS prevent the desktop client from being used as the guest operating system in a virtual machine. Because of this limitation virtualization tools such as VMWare Fusion or Parallels Desktop prevent you from installing the MacOS into a virtual machine.

This limitation in purely for licensing compliance. With the release of Leopard, Apple has modified the software license so that virtualization is allowed for OS X Server. Both VMWare and Parallels have betas that allow installation of Leopard Server in a virtual machine. This relaxation of the restriction for servers is a step in the right direction. We may even put that to use on our intranet here at RogueSheep.

Still, I believe that nearly all developers can benefit from virtualization of the standard MacOS. Craig makes excellent points about testing in various versions of the OS and easily having parallel installs of your development environments such as Xcode. In our work, we run into even more situations on a regular basis that I wish we could use virtualization for.

We often have multiple projects in progress for several different clients or our own in house development. Frequently, work for a particular client will require all manner of supporting frameworks and libraries as well as specific configuration of InDesign, InCopy and the various Creative Suite applications to enable the proper operation of a workflow environment.

Many times as one project is winding down, a new project is beginning. Sometimes the components required for two projects that any one of us happen to be working on at one time will conflict. Other times the pain comes from just having to juggle the configuration of the development environment and supported applications when switching contexts between projects.

If we could virtualize the MacOS, each project could start with an image that was prepared with our needed development environments and configured properly for the system that is being developed. Only one person would have to do this configuration and the result could be shared with all members of our team. When any one of us was forced to switch projects for a quick bug fix or consultation, it would be as simple as launching the appropriate virtual machine. The benefits to our work and our clients, Apple’s customers, I think is clear!

I’m not going to claim I know the exact reasons for Apple’s restrictive licensing. I will suggest though that I would be absolutely fine with requiring Select or Premier membership in the developer program to gain this support. If Apple wants to work with VMWare so that the only desktop OS that will install virtually are those downloaded as assets from our ADC benefits, I’m game.

I chatted briefly with the VMWare folks at MacWorld this year. They said they would love to add support for virtualization of the standard Mac OS. They encouraged all of us that need virtualization to contact Apple and let them know about our needs. Personally, I’ve done just that.

If you are developer using a Mac, I urge you to read Craig’s blog posting and then file your own bug, referencing the bug he notes.