Kickingbear

2,000,000 Strong

Over the week covering this past Christmas Day a piece of software I had contributed to was downloaded two million times.

I’ve been writing Pop Software for my entire professional career. I may be the first to coin the term Pop Software but it’s with the presumption that we all know what I’m talking about – I’ve worked on games and applications targeted at the larger audience rather than businesses or niche products. Admittedly many of these projects had smaller scopes than others but the general principal holds – work with a team to create a piece of software that will be enjoyed by the general public. I have contributed code to hits, misses and to the forgettable wasteland in-between. Granting myself a very generous margin of error the results have laregely been within my expectations.

This particular piece of software continues to defy my expectations – and not just by a little bit but by orders of magnitude. That’s not to say I don’t think it’s worthy of being popular but the sheer scale of its success has been staggering. Before this past December it had already been downloaded over ten million times and has enjoyed an enviable retention rate. Subsequent derivative products have also enjoyed tremendous success. However, my mind finally bent after hearing that it had been downloaded two million times in the space of one week.

I was forced to ask myself a question.

“Who the fuck are these people?”

How the hell does one App get downloaded two million times in the space of one week? To do so it’d have to catch the eye of people you’ve never heard of – like your brother or your girlfriend’s best friend or the dude who made that really cute but slightly awkward heart in your latte the other day. Two million people in the space of a week means we’re talking about exactly that – people. Real honest to God people are downloading software and, importantly, it’s not a big thing for them. It’s what they do when they unwrap their iPod Touch on Christmas Morning. They stick in the headphones, maybe they sync their music to it, and then hit the App Store for some Pop Software to get some amusement out of their new toy.

The people who are consuming software now are a vast superset of the people who used to do so. At one time, especially on the Mac, we’d see people chose software based upon how well it suited their requirements to get a job done. This new generation of software consumers isn’t like that – they’re less likely to shop around for something rather they shop around for anything. These are people who want to be entertained as much as they want to have their requirements met. They’ve not bought into a tool they’ve bought, either financially or emotionally, into The Future. The Future is never about the most practical and useful outcome, it’s about flying cars and cute robots who shit talk but will still mix you up a killer G’n'T when you need it. The Future isn’t a service that’ll send you a text message when you’ve been out too late on a work night, The Future will get you laid on a Tuesday and make excuses to the boss the next morning.

How did applications that make farting noises or make you sound like T-Pain do so well on the App Store? The answer is simple – they made people laugh.

That should have been the first sign that the software market was changing. It’s obvious in retrospect; people were buying software that would make them laugh. This runs counter to the common understanding of an Application. An Application represents the developer’s best effort at creating software that applies the capabilities of the device to solving a specific problem. Making people laugh is not a problem an Application can solve; it’s not about the device it’s about the person using it.

App Store

The thing is these people don’t buy Applications, they download Apps. “Software” is dead, don’t bother putting that word on a sell sheet. Have you written “a program” recently? That’s nice, find a place in line behind all the other nerds but try not to step on the Coke-bottle glasses they tend to drop. “Oh … you’ve developed an application … is it something my doctor would know about”? People, lots and lots of people, people who have no idea what software even is, will download Apps like they’re snacking on potatoe chips. What’s my proof? Well, two million downloads of an App in a week supports that and I’d argue that a total of three billion Apps downloaded backs up my argument too. Also, I spell potatoe with an ‘e’, as God intended, so you know I’m right about this.

“Apps” is fun. It’s fun to say, it sounds unthreatening, it’s a word sufficiently abbreviated that it takes on a life of its own without dragging to the forefront of peoples minds the more sterile and technical sounding “application”. Apps are not Applications – they are their own things. They are smaller. They are more fun. Apps are treats atop your technological sundae. They are not potential time sinks. They are neither burden nor investment. They each represent a nugget of fun, of fleeting amusement. Apps are gobbled up in the millions by people who would never rush so willy nilly to buy desktop software. Apps are Pop Software writ large in blinking neon lights.

Are Apps good business? No, they’re not. From a small developer’s perspective the App Store is a total disaster. If you’re reading this I’ll assume you’re familiar with the complaints developers have with the iPhone OS marketplace. Suffice to say that between a review process that seems arbitrary and a store front that seems insufficiently nuanced quality oriented smaller developers have, by and large, given up on the App Store as a market worth competing in.

Apps, by their very nature, are a hit driven industry. Making hits requires taking risks. Risks cost money. Despite the fact that developing a quality application for iPhone OS is less of an investment than developing an equivalent application for Macintosh there are far more factors out of your control when dealing with the App Store than there are with (what has become traditional) web based downloadable software delivery. As we’ve seen time and again designing a quality application is no guarantee of success on the App Store. That’s not to say that quality isn’t a factor, only that quality alone isn’t going to lead to success.

“Well … that sounds really fucking unfair. Why is that”?

Desktop Publishing Syndrome

The mid to late 80’s saw an abomination arise. An abomination so large that no matter where you hid eventually you would be splattered in its shit. Wave upon wave of fucked up tastelessness washed up upon our shores. It clung to our telephone poles screaming, “Missing dog!!!” in three different fonts, each bolded, at least one with its innards hollowed out. Our dot-matrix printers cried out in pain as pages upon pages were rendered in agonizing pixelated detail, noisily vomiting out reams of daisy-wheel paper destined to adorn the hallway leading to the cafeteria – “School Dance Friday 7PM”!

Publishing had been democratized. It was loud, it was ugly, it was popular and we feared it would never improve.

But it did.

The mid to late 90’s saw an abomination arise. An abomination so large that no matter where you hid eventually you would be splattered in its shit. Wave upon wave of fucked up tastelessness washed up upon our shores. It clung to our Navigator windows screaming, “Under Construction!!!” in three different colours, each bolded, with at least one blinking. Our browsers cried out in pain as pages upon pages were rendered in agonizing animated gif detail, virtually vomiting out reams of star-field backed text – “AltaVista Indexed”!

The Internet had been democratized. It was loud, it was ugly, it was popular and we feared it would never improve.

But it did.

The mid to late 00’s saw an abomination arise. An abomination so large that no matter where you hid eventually you would be splattered in its shit. Wave upon wave of fucked up tastelessness washed up upon our phones. It clung to our oleophobic touch screens screaming, “Tap to Fart!!!” in only one font but with three different gradients, at least one being yellow. Our devices cried out in pain as pages upon pages were rendered in agonizing ineptitude inducing developers to vomit out the question, “how the fuck did this get past review”?!

Software has been democratized. It is loud, it is ugly, it is popular and we fear it will never improve.

But.

Well, we’ll have to wait and see.

Time And Tide Wait For No Man

The Web Dreamtime was only ten years ago. Context. History. A thing is born and it is as dumb as fuck. Give it time and it will grow. Give it more time and it will learn things you never knew. Give it all that you are and it will become even more. Does that mean it will develop into what we want it to be? Probably not – it will be what it will be.

Over the span of one week two million people downloaded one application to their iPhone or iPod Touch devices.

Something has changed. It has changed for good. Has it changed for the better? I’m not yet sure – but I am sure there’s no going back.

best of luck in the new year, Guy

Appeal to Authority

I post here infrequently. My intent with each post has been to show some “clever” abuse of Cocoa or the Objective-C runtime APIs. I don’t want to portray what is presented here as the canonical or “best” way to approach problems – my goal has been to offer readers who are amply qualified to disagree with what’s written something that I feel is worth their time to think about. I hold the Cocoa developer community, and particularly those I associate closely with, in high regard. Coming up with novel ideas and finding the time to adequately document them is, by virtue of the caliber of the audience I hope to address, a difficult task which doesn’t fit into a regular publishing schedule. If you’d like to read something smart at least once a week please consider reading my friend mikeash. Don’t bother clicking that because if you’re here and not already reading everything Mike has to say then there’s something wrong with you that one hyperlink will never solve.

With that preamble out of the way I’d like to assert that I am an avowed fan of the Cocoa frameworks and a believer in the language middle-ground that is Objective-C. The argument that follows is a novel addition to this infrequent spamming of ideas I call a Web-Log in that it is not a tightly focused technical piece. Rather, it is an opinion piece – an appeal to authority.

And to whose authority do I appeal? Mine. Because I know what the fuck I’m talking about.

Non-Native Toolchains vs iPhone OS

May the best man win.

Beyond the well known issues with Flash letting arbitrary interpreted code run on the iPhone is problematic. Primarily it precludes Apple from vetting the code executed on the device after they’ve approved the product for sale on the AppStore. One could argue, and it’s a decent argument, that they should not exert this level of control over the apps that run on the device they sell you but, given that they’ve decided to do so, permitting interpreted code to be executed would be a loophole in this policy. What Adobe announced today, however, is not a Flash runtime – it is a compiler for Flash code that produces first class iPhone (ARM specifically) native code.

Jeff LaMarche has examined the Adobe generated .ipa files and you can learn a little more by reading his Tweets starting here. In full disclosure Jeff has bought me more beers at WWDC than I feel I deserve but I trust his analysis of these files nonetheless. Jeff is a smart fellow and uncovers a few clever things in his dissection of these Flash based iPhone apps.

My take is this: if you produce a binary that honours the iPhone Developer contract (uses only public APIs, is not a Flash interpreter, applies the appropriate code signing, etc) then you have exactly as much right to be on the AppStore as I do. If you compiled some Flash code or even used Mono (.NET) to write your app then so be it. If the final product is playing by the same rules I am then that’s good. Perhaps your tool is better for the job you selected it for.

“Be Thou Not Afraid”

(During my favourite x-files episode an “alien” says, “Be thou not afraid, Rocky”. I tried finding a link to that but this link came up first. Dig the horizontally scrolling text and take time to read the poem too. It won’t hurt, even though it does mention God. And the MIDI. I just noticed the MIDI. Click that link just for the time warp effect).

Let’s be frank here – fuck the tools. If you’re as deep a fan of the Cocoa tool-chain as I am then you likely came to them as I did – after years of dealing with the drastically inferior. Do I believe Cocoa is still the best tool? Yes, I do. But let’s not pretend that it’s the only tool. Some crazy people may prefer other tools, and we may well think they’re insane for doing so. The proof, however, is in the pudding. And it’s the pudding that our customers buy. I’m in love with my oven and at this point I doubt I’ll ever change it but I have no illusions that fashion won’t pass me by. If Adobe, or anyone else, can produce tools that provide a more compelling application on the iPhone then good for them.

Ridiculing their or others efforts is ultimately self defeating. If you love software as I love software you should think twice about being so dismissive of alternative approaches.

Do I think the “Ahead Of Time” compiled Adobe Flash will take over the AppStore? No, I don’t. And I know that because I can write better software than that.

But one day I’ll be wrong. And if there’s one thing I hate more than being wrong it is having dismissed as trivial that which has defeated me.

“I’ve Been Wrong Before”

($0.99. Go buy Dusty Springfield’s I’ve Been Wrong Before. And if you don’t after having heard the 30 second demo then quit bitching about Alyssa. She is carrying my child after all…)

I like to believe I’m a clever fella and here’s my secret to being clever – I am always wrong. Always.

Programming is an exercise in overcoming how wrong you’ve been in the past. At first you’ll overcome the syntax errors, then you’ll overcome the structural errors, and then you’ll come to align your code with the standards of a greater community and you’ll feel safe and like you’ve made it. You haven’t – you’re still wrong because you’re always wrong. You are playing a game you cannot win. And let’s face it – if it was a game you could win you’d not be playing at all.

If you’ve written code then you’ve looked back at your work and known it could have been done better. Think bigger. Think beyond the micro improvements that could be made within the domain we understand best and consider the scope of our experience. If you’ve been around this clock as I have then you’ll recognize a good idea comes every five minutes and one that sticks every fifteen. Let’s not pretend that we know what time it is because we know what we saw last time we checked our watches.

At the top I claimed to be an authority and that I knew what the fuck I was talking about. That’s still very true – If you think you’re an authority you’re wrong. Take it from me, I’m the authority on authority and if you think you know better then eventually you’ll be in for a really big shock.

Be wrong as often as possible – It’s the only way you’ll ever be right.

Love, Guy

ouch

Well, I’m not sure what happened here yet but whatever it was I’m not planning to give a round of high-fives over it. The comments are missing in action currently which is a real shame because a lot of them were helpful and added a lot of value to the posts.

So, sorry if your news reader got spammed, your comments deleted and your dreams of making it to stardom via these hallowed pages are dashed against the cold hard rocks of some weird-assed technical crap.

Object Scope and Lifetime

In Objective-C the lifetime of an object is not governed by the scope in which it appears – it is managed manually by the programmer. – (id) retain, -(void) release, and – (id) autorelease are the methods we use to let the runtime know if we’re still interested in an object or not.

Other variables in Objective-C don’t have to be managed in this way. Structures can be declared and will cease to exist once they leave the lexical scope in which they’re defined. Other languages, such as C++, can have instances that do the same thing – when the scope of a C++ stack allocated object is exited it’s destructor is called. That behaviour can be quite handy in that it allows the programmer to see the lifetime of the object simply by looking at the brackets in which it’s defined. It also means the programmer is less likely to accidentally leak an object since the scope will clean it up anyway. But we can’t do that in Objective-C.

How To Do That In Objective-C

{
    NSObject *myObject KBScopeReleased = [[NSObject alloc] init];
    NSLog( @"%@", myObject );
} // myObject is sent a release message here.

How does it work? Well first we notice that there’s something special in the declaration of myObject. KBScopeReleased lets the compiler know that we want this instance to be sent a release message as it leaves the scope it is defined in. Which seems like magic but here’s all that is involved:

#define KBScopeReleased __attribute__((cleanup($kb_scopeReleaseObject)))

We use the __attribute__ feature of the GCC compiler to define a cleanup function. This cleanup function will be called when a variable leaves scope and will be passed a pointer to the variable. I’ve defined the cleanup function to be $kb_scopeReleaseObject and here’s what it looks like:

void $kb_scopeReleaseObject( id *scopeReleasedObject )
{
    [*scopeReleasedObject release];
    *scopeReleasedObject = nil;
}

You don’t even really need to set the object to nil at the end there but I do because I’m crazy that way.

“I’ve Already Got Autorelease So I Don’t Care”

Good point. Using scope released objects will keep your peak memory usage down – the objects are released immediately rather than waiting for the autorelease pool to be drained – but, in general, autorelease pools are perfectly fine and are a pattern that Cocoa developers are accustomed to. So let’s put two good things together and see what we come up with.

KBScopeAutoreleased();

Drop that at the top of your scope and anything autoreleased between it and the closing of the scope will be automaticaly autoreleased. That’s handy if you’ve got a loop and want to keep your memory overhead down. As my friend and Rogue Amoeba colleague points out – Autorelease Is Fast. So just dropping a KBScopeAutoreleased() at the top of a loop will keep your memory overhead down at a very tiny speed cost.

Here’s what KBScopeAutoreleased() looks like:

#define KBScopeAutoreleased()\
       NSAutoreleasePool *$kb_autoreleasePool##__LINE__             KBScopeReleased =\
         [[NSAutoreleasePool alloc] init]

There’s a bit of C Macro Voodoo in there to make sure the variable name is unique but otherwise all it does is allocate a new NSAutoreleasePool and fix it up so it’ll be released when it exists scope.

Garbage Collection

Under Garbage Collection this becomes less useful but you can still use this trick to keep peak memory consumption down by changing the definition of KBScopeAutoreleased to be:

#define KBScopeAutoreleased()\
  NSAutoreleasePool *$kb_autoreleasePool##__LINE__\
        __attribute__((cleanup($kb_scopeDrainAutoreleasePool))) =\
        [[NSAutoreleasePool alloc] init]

void $kb_scopeDrainAutoreleasePool( NSAutoreleasePool *pool )
{
    [*pool drain];
}

With that in place the NSAutoreleasePool will be drained when exiting scope which will trigger a garbage collection cycle.

That’s It

Really, not much to it but it’s kind of cool. For fun sprinkle KBScopeAutoreleased() around your code and your peak memory usage will drop.

Visual Cues

If your application presents data to the user then there are some valuable tools you’ve been leaving on the table because they have traditionally been difficult to achieve with computer graphical interfaces. Mac OS X has some great graphics technology that changes the game – and I don’t mean Core Animation.

Core Image – Not Just For Images Anymore

Core Image is incredible. The amount of complexity that it abstracts and offers in a straight forward interface is staggering. I may be a little more appreciative of it since I’ve had occasion to do a lot of low level graphics programming against OpenGL or DirectX or whatever directly – Core Image exposes, with a minimum of fuss, all the best parts of playing with a modern pixel pipeline.

The basics of Core Image are dead simple – you provide a recipe for how you’d like your image cooked and it’ll give you a result. The recipes are in the form of a few simple objects strung together with some settings tweaked. If you’ve played with a modern Mac OS X image editor like Acorn (from Flying Meat) what you see in the filters window (developed by Rogue Sheep) is pretty much how the underlying implementation works. (Yes, I did just pimp friends.) So if you’ve got a basic grasp of stringing filters together in a graphics program then you’re in good shape to do so in your own application.

“But I don’t write a graphics app!”

Well, yes, in fact, you do. A Mac OS X desktop application uses a graphical interface to communicate information to the user. One of the wonderful things about graphics is that you can communicate lots of information very quickly. Even better than that is that the information doesn’t need to be accurate. That sounds preposterous – why on Earth would you want to show the user inaccurate information. Well, clearly, you don’t – but you don’t need to show exact information either – your job is to provide an environment with enough graphical cues so that the user can interact quickly and effectively with whatever data you’re presenting to them. If you’re not sold let’s look at scroll bars – they shrink in proportion with the size of the displayed information versus the size of the total amount of information. They’re pretty close to being accurate but not really – there’s a minimum size on that scroll bar thumb so it breaks down for huge amounts of data – and the other thing is, really, you don’t care – you get the idea but a pixel here or there doesn’t matter to you. It’s the same for Dock icons bouncing on load or even the classic lying progress meter – none of these are precise but they allow you, the human, to infer information quickly.

Humans are damn good at picking out important visual information rapidly. We’re good at it because otherwise 6,000 years ago we’d all have been eaten by Dinosaurs. We have some built in clues that can help us distinguish relevance – objects outside our focus are more blurry and those brightly colored draw our attention more than those which are muted and subdued. These cues are used daily by every sighted person to make sense of the vast amount of visual clutter we’re bombarded with.

“Where are you going with this?”

Core Image can be leveraged to provide your users with richer visual cues to help them more quickly grasp the information you are displaying. The graphics architecture of Mac OS X allows us to draw into different contexts – once we’ve got our data in a graphics context we can operate on it graphically as if it were an image. We’re going to use this ability to do some fancy post-process effects to our views that will add visual cues to the data represented. I’ll use an NSTableView subclass to demonstrate but it’s important to recognize that this technique is applicable to any view – and may even work better with your own custom views.

Post Processed Table Views

The idea is simple – we’ll present a typical table view to the user but allow for various ‘focusing’ effects to be applied to it. For each item in the table we’ll provide a degree indicating how much of the effect to apply. For a search results table, for example, we can blur results more the less relevant they are. Or if we’re looking at time based data we could apply a sepia tone to older entries – a common visual cue indicating that an item has aged.

Implementation

We need three things to make this work: the table as it would have appeared without any post processing, a set of floats indicating how much we’d like the effect applied, and a mask image we’ll use to graphically represent those floats. A good way to go about this on Mac OS X is to use CGLayers – they’re fast, efficient, and will be cached on the graphics card when possible. The process is reasonably simple: if we’re applying a post process effect then allocate the viewLayer which we’ll render the base NSTableView into; then allocate the viewMaskLayer in which we’ll draw the various shades of gray representing how much to apply the effect. Since the effect is multiplicative 1 (or White) represents a full application of the effect while 0 (or Black) represents not applying the effect at all.

So far, so simple. The next step isn’t much harder either. First – set the current graphics context to the viewLayer and ask our superclass to draw. That way we’ll capture what it would have drawn in our layer context rather than having it sent to the screen. Next we’ll need our table view data source to be able to provide us with per-item blending information. To achieve this we set our mask layer as the current graphics context then call -(CGFloat)tableView:(NSTableView*) tv postProcessFactorForRow:(NSInteger)row on our data source. We take the result, turn it into a shade of gray and fill the row rect with the color. Once we’ve iterated over the visible rows we now have a mask image which contains bands of gray each indicating how much to apply our filter.

Finally we apply the post process effect – we’ve got our source view and our mask and we just use a CIBlendWithMask filter to combine the two. The effect is up to you really – and it’s irrelevant to this approach. The code provided shows a sepia tone, a blur, a contrast and provides for a way to set custom effects. You can download the source code here, play around and see what works for you. Remember – we happen to be using a table view here but this technique is generally applicable – if your view presents a set of data then you can use this technique. This technique also works on Tiger – in fact the code just recently got Objective-C 2.0-ized but this was originally all written against Tiger without Core Animation in mind. If you want to use this on Tiger, go wild – you’ll just need to reverse the ObjC2.0 @properties and data source @protocol a bit but it’s dead easy.

Also – I’m not sure if I’ve made this explicit: if there’s code I’ve put up on my blog then it’s yours to use as you wish. That said, if you’re making an awesome UI for your Nuclear Armageddon machine I’d prefer you look elsewhere – Nuclear is so passé.

Update

Shamed by Gus for not having any visuals here’s a screen shot of a test app I just built. It shows a listing of the files on the Desktop – files of the same type as the selection are not blurred, files of a similar type (as determined by a UTI check) are blurred a little and totally dissimilar files are blurred even more. The effect is overstated for the sake of the example, it’s the technique which is really of interest.

And here’s a movie of it in action: KBPostProcessTableView.mov

I also updated the code and included the test app and a project. Download it here.

Brown is Ugly

Well it’s been a long, long time since I posted anything here. If you’re reading this it’s either because we knock back drinks together at Mac events or you’re someone I should be buying a drink for at a Mac event. The basic idea I initially had for this blog was that I’d post a series of Weird & Wonderful Cocoa tricks. There’s tons of great Cocoa content out there ranging from introductory to pretty advanced but it seemed like there was a hole in the Semi-Abusive segment. I’ve had a number of ideas I’ve wanted to put up but with the pressures of the oppressive corporate world (I work at a subsidiary of an umbrella company held by a Rogue Amoeba interest. We’re hiring.) and various other things on my plate nothing ever gets written. The thing about the Weird & Wonderful is that while it’s easy to know if something is weird it’s something else to know if it is indeed Wonderful and it’s something even more else to be able to explain why it’s Wonderful. So in the interest of trying to keep my feed from turning brown in NetNewsWire I think I’ll start to mix it up a little. That said, let’s get Weird & Wonderful.

Loopy Problems

You’re too smart to be writing yet another loop. Nine times out of ten it’s mostly boiler plate – the operation you’re doing can be easily explained in a couple of words but expressing it in code is cumbersome. Even with Objective-C 2.0’s new for in iteration loops are still basically boring beasts. Let’s see what we can do to avoid them.

At the mega-giant corporation where I slave under the ever watchful eye of a hawkish manager we often need to iterate over Employees to create the endless reports required by our strict oversight committee. We’d like to be able to say, “Give me the names of all Employees who’s computers are idle for more than 5 minutes”. Here’s how we’d do it in Cocoa:

NSMutableArray *namesOfIdleEmployees = [NSMutableArray array];
for ( Employee *employee in allEmployees )
{
    if ( employee.idleTime > 5 )
    {
        [namesOfIdleEmployees addObject: employee.name];
    }
}

Now, sure, that doesn’t look like much code and it’s not really arduous to write but you’ve got better things to do with your time than crank out code like that. Like make more money for your overlords. They love that.

So what are we actually doing in that loop? How would we express it in words? Maybe “collect the names of employees who are idle for more than five minutes”. That sounds like a nice concise order, one you could pretty easily turn into a method on the collection. But if you did that in this case there’s a billion other cases you’d have to do too. And that gets more tiring that just doing the loops when you need them. It would be nice if we could just ask the collection though. Kind of like how we can ask for a @distinctUnionOfObjects. However, to do that we’d need to add our own array operators or override valueForKeyPath: or something weird.

Weird & Wonderful

NSArray *names = [allEmployees valueForKeyPath: @"[collect].{idleTime>5}.name"];

Kind of nifty, isn’t it? What we’re doing here is saying we want to filter based on idle time and any objects that pass the filter we collect their name. Easy as pie.

To do this you do indeed have to override valueForKeyPath: – there’s no way to add your own @style array operators. That’s ok though because once we’ve overridden valueForKeyPath: we can get fancy with how we handle things and add some pretty powerful functionality.

• method calls

  NSArray *results = [myCollection valueForKeyPath: @"[collect].name"];
  

  Method calls go between []’s. In this case since there’s no parameter given an implicit parameter is assumed. The result of this expression is basically: [myCollection collect: @"name"] – the collect method iterates over the objects in the collection and gathers all the values for the key ‘name’.

  You can have more complicated method calls:

  NSArray *results = 
  [myCollection valueForKeyPath: @"[collect].name.[componentsSeparatedByString: ' ']"];
  

  The result of this expression is that componentsSeparatedByString: @" " will be called for the value of ‘name’ in each object in the collection. The resulting array of components will then be gathered by the ‘collect’ call. The end result is an array of subarrays containing the words of the name.

• inline predicates

  NSArray *results = 
  [myCollection valueForKeyPath: @"[collect].{salary>100}.jobTitle"];
  

  Predicates can be specified between {}’s. The predicate string is used to create an NSPredicate which is then used to evaluate the object. If the object matches the predicate then it returns the value of the remainder of the keypath otherwise it returns nil. In this case we use the predicate to filter the collection based on a salary. Each object is checked if it’s salary property is greater than 100. If it is then the value of it’s jobTitle property is returned. If it’s not nil is returned. Collect gathers the results ignoring any that are nil. The end effect of this is that you’ll get an array of all the job titles where salary is more than 100.

• inline value transformers

   NSArray *results =
   [myCollection valueForKeyPath:
      @"[collect].<NSUnarchiveFromDataTransformerName>.imageData"];
  

  You may specify the name of a value transformer between <>’s. The value transformer is handed the value of the remainder of the keypath. In this case we use the unarchive from data value transformer and hand it some imageData. The result of the transformer is then collected by ‘collect’. The resulting array would contain unarchived NSImage instances. You may specify any of the build in value transformers by their constants or you can use your own value transformers names.

Some Examples

NSArray *waitsAlbumCovers =
[myRecordCollection valueForKeyPath:
@"[collect].{artist like 'Tom Waits'}.<NSUnarchiveFromDataTransformerName>.albumCoverImageData"];

waitsAlbumCovers now contains NSImage instances for each of the albums in my collection where ‘Tom Waits’ is the artist.

NSString *albumsTitles =
[myRecordCollection valueForKeyPath:
@"[concatenate: * withSeparator: ', '].{artist=='Tom Waits'}.albumTitle"];

albumTitles contains a string of all Tom Wait’s album titles separated with ‘, ‘. This example shows the use of a special place holder symbol. The ‘*’ expands during evaluation to the remainder of the keypath. In this case the resulting call on the collection would look like: [myRecordCollection concatentate: @"{artist=='Tom Waits'}.albumTitle" withSeparator: @", "]; The concatenate:withSeparator: method would then iterate over the contents of the collection and concatenate the value of {artist like 'Tom Waits'}.albumTitle placing the separator in between.

Implementation

The code for all this is actually surprisingly small. It’s one file, one class which isn’t actually really used and a couple of categories. Objective-C & Cocoa are just ridiculously awesome at times.

First up we need to override valueForKeyPath:. That’s totally possible to do – we make our own NSObject subclass then inherit everything from that and we’re good to go. Except that’s a lame solution because then we’d not be able to use these calls on stock Cocoa collections. What we want is to replace NSObject’s implementation with our own. On Leopard there’s a new way of doing that: class_replaceMethod. We use that early in the life time of the process (in main.m before you actually kick off the AppKit) and we’re good to go.

The code for our version of valueForKeyPath: is also pretty basic. We’re given a “key path” which is a string with components separated by ‘.’ characters. We just use componentsSeparatedByString: to grab each component then iterate over each one. If we detect that the component starts with one of our special characters ( [, { or < ) then we handle it. Otherwise we just recurse down the component list.

collect:, concatenate: and other methods need to be implemented by each of the collection classes you'd want to call them on. Rather than code them for each kind of collection I hung them off NSObject in a category and, better, I also made NSObject be able to act as a collection by implementing NSFastEnumeration for it. So now this is valid code:

    NSString *exampleString = @"Example string";
    for ( NSString *string in exampleString ) NSLog( @"%@", string );

That'll print out "Example string". As far as I'm concerned single instances should behave as collections of 1 item. Adding this to NSObject doesn't effect NSArray, NSSet, or NSDictionary enumerations at all. The real benefit of NSObject being a collection is that this, sort of contrived example, works:

    NSString *jobTitle =
        [person valueForKeyPath: @"[collect].{hasNotBeedFiredYet==YES}.jobTitle”];

You'll get nil or the jobTitle depending on the person not being canned yet.

The best way to check out the implementation though is to grab the source code. It should be pointed out that this code should really be taken as a proof of concept. There's so much room for optimization and general clean up it's not even funny. It does, however, work, which is always nice, and it shows off what you can do with this kind of approach. Also as a word of warning: I've yet to use this in any sizable project. It may also be a terribly bad idea for some reason that's escaped me but will no doubt be pointed out in the first comment.

All the warnings out of the way I think what you can do with this stuff is pretty powerful and will save a ton of boring loop iteration code. It lets you more easily express what you want rather than the iterative steps needed to get it done. And that's always a good thing.

When the user takes an action in a Cocoa app the framework looks for the first object in the responder chain that can handle that action. Basically each object in the responder chain is asked if it implements the given action selector and if not passes the buck on to the next object in the chain. This works great since you can put code to handle user actions in the higher levels of your applications controller classes without having to worry about calling into them yourself from button handlers. The trade off here is that the further removed from the action you put the code the less contextual information you may have with which to make your decisions.

Generally this isn’t a problem. Your NSWindowController will handle an action for the relevant document or you handle it higher up for the application in general. Things become a little more complicated though when you have view controllers. These are very much like window controllers except they are responsible for only a sub-portion of the view hierarchy. As an example consider a view controller in charge of a date picker. The date picker may have several subviews, one for the day, month, year, maybe some more for the time. The idea of a view controller is that it can create a view hierarchy and manage it in a way thats opaque to the rest of the app. The date picker is a trivial example – you can imagine view controllers that manage a complex amount of state and touch their model area in a non-trivial way.

Often you’ll want to give the user the ability to report bugs in your software, sort of like what Safari does with it’s Bug Button. Ideally we’d click the bug button or chose an item from a menu and we’d get a nice bug report with contextual information as to what the user was looking at. There were a couple of ways to approach this. First is to add code in each controller that’ll handle a ‘reportBug:’ action, gather it’s information and send it to the centralized bug reporting class. This fails though because if I implement ‘reportBug:’ in my date picker then I lose the context in which I was trying to pick a date – and the bug report loses some of it’s usefulness. If I implement ‘reportBug:’ in my window controller then I can know the big picture but I don’t know what’s going on with the view controllers below me – they may have pertinent information that hasn’t been committed to the model layer yet. So it looks like we’re screwed either way.

My solution to the problem was to implement my ‘reportBug:’ action at the highest level in my application. It looks like this:

- (IBAction) reportBug: (id) sender
{
    KBBugReportController *bugReport = [KBBugReportController sharedBugReportController];
    [bugReport gatherBugReportInformation];
    [bugReport sendBugReport];
}

Nice and simple, isn’t it? Except how can ‘gatherBugReportInformation’ work? The trick is we walk the responder chain ourselves and ask each responder to contribute some context information. By the time we’ve walked the entire chain we’ll have travelled from the most specific information to the most general.

Here’s what that’d look like:

- (void) gatherBugReportInformation
{
    KBCoalescingDictionary *bugReportInformation = [KBCoalescingDictionary dictionary];
    NSResponder *responder = [[NSApp mainWindow] firstResponder];
    while ( responder != nil ) 
    {
        if ( [responder respondsToSelector: @selector( submitBugReportInformation: )] )
        {
            [(id)responder submitBugReportInformation: bugReportInformation];
        }
        responder = [responder nextResponder];
    }

    NSArray *titles = [bugReportInformation objectsForKey: kKBBugReportTitleKey];
    [self setTitle: [titles componentsJoinedByString: @" "]];

    NSArray *contents = [bugReportInformation objectsForKey: kKBBugReportContentKey];
    [self setContent: [contents componentsJoinedByString: @" "]];

    [bugReportInformation setObject: [NSDate date] forKey: kKBBugReportTimeStampKey];

    [self setBugReportInformation: bugReportInformation];
}

The method I use here is that responders implement an informal protocol or one method – ’submitBugReportInformation:’. The method takes one argument a special NSMutableDictionary into which they can write whatever bug report info they want. I’ve got a few special keys defined for the bug report title, contents and time stamp. If you send the bug report in an email the title and contents come in handy. There is one trick here and that’s using a coalescing dictionary. All that does is that when it gets asked to set and object for a key that already exists it instead makes and array and sticks both objects into the key slot. Asking it objectForKey will return the last object set and asking it for objectsForKey (note the ’s’) will return the array of all objects set for that key. This makes it easy to just write whatever you want into it without worrying about blowing away other objects data.

By the end of ‘gatherBugReportInformation’ we’ve travelled the chain and given each responder the opportunity to help us out with some context info. All we need to do now is send our dictionary off to our server somehow. We can either upload it with an HTTP POST request or send it off in an email. Either way I suggest letting the user have a look at what you’re going to send; you can get quite a backlash for not being polite about this kind of thing.

I’ve posted the source code to a basic implementation of the Cocoa Shaders I talked about here. There’s code for conditional shaders, shader lists, clip shaders, and affine transform shaders. As far as shaders that actually draw there’s a solid color shader and one for drawing an image. The image shader lets you tweak the compositing operation, source rect, and set a drawing scale.

Included is a sample app to show you how you could use this stuff in practice. The app has a custom view which draws using a shader. The demo shader will change its background from blue to red when the view is clicked. Its implemented using only the simple shaders provided.

Fancier gradient fill shaders, CoreImage based shaders and that kind of thing are left, for now, as an exercise for the reader. I mentioned it in the original post but if you’re looking to do gradients you’d do yourself a favour by looking at CTGradient.

Keeping up with the Joneses UI trends on Mac OS X can take a fair amount of programming and artistic effort. With the HIG becoming antiquated and new implicit design guidelines become more prevalent we find that Cocoa doesn’t provide us with au-currant controls right out of the box. So we’re left with either rolling our own or making do.

One of the first things I do when I download an app is poke around its resources. Often you’ll find all manner of bitmap images that lay out portions of the apps controls. Left sides, middles, right sides. Sometimes circles where the center pixel will be stretched for the length of the control. Apple’s applications are often stuffed full with these custom little images but it’s not just them, I’m sure that many of your favorite apps have similar resources.

“Well so what” you may ask, “We want nice looking controls, the cost of downloading a few extra images is next to nothing, and we can tweak the images at change the look of the controls, it’s no big deal”. And then Apple keeps talking about resolution independence and you curse as you have your artist (or yourself) laboriously pound out multi-rep tiffs containing all the DPIs you need. And your download bloats. But whatever, it’s the 21st Century and my binaries and tiffs are fat and it’s all good. Then a user complains that the left side of the “SomethingCool” button in your app is all distorted and you need to go and check the tiffs and see that one of the reps is screwy and fix it. These little pains are common to development but, often, we can avoid them.

Will Shipley wrote this in a post about implementing a gradient table view:

Which leads me to an important rule: In general, if I can replace an image with code, I do so. This is not something that’s intuitive, and it took me many years to decide that this is the best policy. Code is easier to change and understand than images are.

I read that and thought, “Shipley, my boy, you’re just so wrong”. A large chunk of my career has been spent writing video games. If you’ve ever looked around a video game there’s resources that control pretty much everything. One of the guiding design philosophies of modern game engine design is to push as many decisions out of the code and into the hands of the designer as possible. Given this approach the current resource heavy Mac app development makes perfect sense. Until you consider the context. On the games I worked on artists could outnumber the programmers 5 to 1. Apple, who’s apps are littered with resources, has the budget to employ however many the artists it needs. Indie Mac Shop, Inc does not. Indie Mac Shop has, likely, one maybe two programmers and some contact with a part time artist who may well be on contract. Perhaps they may do the artwork themselves, taking time away from their coding. Either way art, in the indie dev world, is harder to come by than code. Shipley, of course, is speaking from the perspective of a programmer who’s career has been spent at a relatively small shop and his advice is spot on for that environment. So turns out he’s onto something. Let’s see if I can save a little face by extending the concept he puts forward.

The Setup

Drawing involves two things: the resources used by graphical elements and the logic required to arrange these elements the right way. Resources include the colors, images and perhaps font information used in the element. The logic dictates in what order and where we employ these resources. If we call our resources “data” and our logic “code” it becomes clear that we can encapsulate our drawing away into a nice, reusable and, importantly, polymorphic class.

The Shader

In 3D graphics a “shader” is used to define and control how a surface is rendered. The basic principle is that for each point on a surface inputs are given to the shader and it returns the final color for that point. Typical shaders involve looking up a pixel from a texture map, modifing that pixels color based upon light intensity and direction, and perhaps adding a brighting color for a specular highlight (shiny!). This method has a valuable trait: the renderer doesn’t know or care what the shader is actually doing. All it does is offer the shader a ton of information (point on the surface, direction to the light, ambient light conditions, stuff like that) and the shader does its thing and spits out an answer. Internally the shader may be using a texture map or it may be doing some fancy math to fake a marble texture. It just doesn’t matter, the result is the same.

It’s a good idea; let’s steal it.

Thanks to the flexibility of Objective-C and Cocoa we can apply this approach to our drawing and build an elegant encapsulation. Our recipe involves Key Value Coding and NSPredicates.

A Cocoa Shader

Our first stab at a Cocoa shader might be as simple as:

@interface KBShader : NSObject
{
}

 - (void) drawInRect: (NSRect) rect;

@end

We can subclass that and add NSImages or whatever and when we need to draw we’ll just call drawInRect: on our instance. Simple, but it doesn’t quite meet the flexibility we’re aiming for. Ideally we want a way to pass information into the shader so it can make desicisions based on the environment its being used in. Like knowing the ambient light level in a room we’d like to know if our button is disabled or not. So we change our drawing method to look like this:

- (void) drawInRect: (NSRect) rect input: (id) input;

We pass input as an id rather than an NSDictionary. A dictionary would have been great and could easilly have encapsulated any state information we’d like to send to the shader. Its shortcoming, however, is that we’d need to maintain its state and make sure it matched the state of the element we’re trying to draw. That’s just error prone and boring code to write, so we won’t do it. Instead we leverage our nifty Cocooa Key Value Coding methods.

Using KVC we can treat any object as if it were a dictionary. Even better, by using key paths we can traverse the objects its accessors return and dig deep into its guts. So it’s a great fit for our shader – lot’s of environment information available to us in an easy to get to way. Using KVC we could write a shader implementation like this:

- (void) drawInRect: (NSRect) rect input: (id) input
{
    if ( [[input valueForKey: @"isEnabled"] boolValue] == YES )
    {
        [[NSColor redColor] set];
    }
    else
    {
        [[NSColor blueColor] set];
    }

    NSRectFill( rect );
}

Now that’s pretty decent. We can change the way we draw based upon the state of the object we’re supposed to be drawing. We can, of course, query a lot more attributes than just isEnabled.

Naming Shaders

I always liked how you could ask NSImage for an image just by calling imageNamed:. Shaders deserve the same treatment. It’s pretty easy – add a name ivar to the shader and some class methods to register and deregister a shader with a given name and you’re done. Then you can just say: [view setShader: [KBShader shaderNamed: @"CurrentEnVogueGlossEffect"]]; and you’re good.

Cocoa Shader Tree

There’s still room for improvement though. We don’t neccessarily want our shaders to be tied to one control. We’d like a ‘WhiteGloss’ shader, a ‘GrayGloss’ shader and maybe a ‘FlatWhite’ shader or something. And we’d really like to be able to say: “Button, when you’re enabled use the ‘WhiteGloss’ shader, when you’re pressed use ‘GrayGloss’”. We can do that by nesting some if’s and refering the call to other shaders but there’s a better way.

What we want is to have our shaders to be able to decide if they want to draw or not based on what’s been input. Cocoa has a nice way of giving us YES or NO answers based on a complex chain of tests – NSPredicate. Let’s use it for something better than some mabmy-pamby CoreData query – we’ll use it to draw something shiny.

(Just as a disclaimer don’t take this code literally – I’m not going to write the init’s and dealloc because it’s boiler plate and distracting).

@interface KBConditionalShader : KBShader
{
    NSPredicate *_predicate;
    KBShader *_yesShader;
    KBShader *_noShader;
}

- (id) initWithPredicate: (NSPredicate*) predicate
              ifShader: (KBShader*) yesShader
            elseShader: (KBShader*) noShader;

@end

@implementation KBConditionalShader

- (void) drawInRect: (NSRect) rect input: (id) input
{
    if ( [_predicate evaluateWithObject: input] == YES )
    {
        [_yesShader drawInRect: rect input: input];
    }   
    else
    {
        [_noShader drawInRect: rect input: input];
    }
}

@end

Now we’ve got a shader that doesn’t actually draw – it does control flow based on a test of the input. Thats kind of cool but so what? Let’s expand on that control flow idea.

@interface KBShaderList : KBShader
{
    NSMutableArray *_shaders;
}

- (id) initWithShaders: (NSArray*) shaders;

@end

@implementation KBShaderList

- (void) drawInRect: (NSRect) rect input: (id) input
{
    unsigned currentShaderIndex, numberOfShaders;
    numberOfShaders = [_shaders count];
    for ( currentShaderIndex = 0; currentShaderIndex < numberOfShaders; currentShaderIndex++ )
    {
        [[_shaders objectAtIndex: currentShaderIndex] drawInRect: rect input: input];
    }
}

@end

Now we can string shaders together. Why on earth would we want this? Well let’s say we want a nice gradient background with an image in the top left hand corner. We can reuse our gradient background shader and our draw an image shader and just chain them together. And we’ve got a conditional shader too…

KBConditionalShader *conditionalBackground =
    [KBConditionalShader shaderWithPredicate: [NSPredicate predicateWithFormat: @"(isEnabled==YES)"]
                                ifShader: [KBShader shaderNamed: kKBBlueGradientShader]
                              elseShader: [KBShader shaderNamed: kKBGrayGradientShader]];

KBShaderList *shader = [KBShaderList shaderWithShaders:
                            [NSArray arrayWithObjects: conditionalBackground, 
                                            [KBShader shaderNamed: kImageBadgeShader],
                                            nil]];

The resulting shader will conditionally change the background from blue to gray if the input object is enabled or not. Regardless of state it will draw an image badge. Conditional shaders and shader lists can be nested as much as you’d like so you can make some pretty rediculously complicated shaders if you really want.

Benefits

Shaders offer some real benefits over bundling up the drawing code with what ever element you’re drawing. First the obvious one – they consolodate the drawing code into one place and it can be shared easily between code that needs them.

Secondly is abstraction. The shader draws, that’s what it does. If you’re using CTGradient today and want to switch that to something else in the future you change it in your gradient shader and you’re done. You can even use different gradient shader implementations depending on platform if you want. Uh, you know, if that was something that’d make sense.

Thirdly they offer optimization and profiling opportunities. You can instrument your shader and discover that each time it’s asked to draw its in the same size rect. With a shader you can cache the results and just draw the cached bitmap instead.

And there’s an immense flexibility behind the shader model. Once you can set a shader for a view it’s realatively easy to write a shader picker that can dynamically change the shader. No, really, honest, I’m not talking about skinning even though it’s a natural fit, but it’s a valuable tool to have during development so you can quickly experiment with different looks. Or consider a ‘debug’ shader that when asked to draw dumps a bunch of control state to the console.

And, saving a big one for last, it’s a big step towards making Resolution Independence a far lesser burden. Some resources are inescapable (and for what it’s worth – multi res Tiff files are what the Apple boys recommend) but many of the images I see when I’m poking around could be replaced by shaders. When Apple changes some random UI element and you want to keep up it’s easier to pull out the color picker and change some RGB values in a shader than it is to ask an artist to whip something up in Photoshop. Your code will scale and the artist will be stuck doing x number of reps. Be kind to artists, they’ve got better things to do.