briankc.com

Using blocks as a flexible callback mechanism

2009-09-13T00:00:00-04:00

Among the many numerous developer improvements in Snow Leopard is the addition of blocks to the Objective-C language (now at version 2.1). While working on some networking code using NSURLConnection I discovered that blocks provide a beautiful and flexible mechanism for implementing callbacks.

As a quick example, let’s say you want to initiate two GET requests to different websites. Perhaps the first is to post some form data and the other is just to download the website content. No matter the particular specifics, the idea is that for different types of NSURLConnection requests you will want to respond differently upon completion. For the first you might want to update the UI to show that the form data was posted. For the second you may want to display the site in a web view. To accomplish this you would traditionally need to keep an array around to hold not only the NSURLConnection instances themselves, but some kind of associated identifier for each one. Otherwise, when your delegate methods fire you will have no idea which action initiated the request in the first place — and thusly you wouldn’t necessarily know what to do next after the connection is finished loading.

The following is a bit of untested pseudo-code (a rough approximation if you will) of one of the traditional methods of handling this:

- (void)performMyFirstRequest
{
  NSURLRequest *request = [NSURLRequest requestWithURL:myFirstURL];
  NSURLConnection *connection = [NSURLConnection connectionWithRequest:request 
                                         delegate:self];
 
  [_connections addObject:[NSDictionary dictionaryWithObject:connection, 
       @"NSURLConnection", @"myFirstRequestIdentifier", @"identifier", nil]];
}
 
- (void)performMySecondRequest
{
  NSURLRequest *request = [NSURLRequest requestWithURL:mySecondURL];
  NSURLConnection *connection = [NSURLConnection connectionWithRequest:request 
                                         delegate:self];  
  [_connections addObject:[NSDictionary dictionaryWithObject:connection, 
       @"NSURLConnection", @"someOtherIdentifierHere", @"identifier", nil]];
}
 
- (void)connection:(NSURLConnection *)connection 
           didReceiveResponse:(NSURLResponse *)response
{
  NSDictionary *connectionInfo = [self _infoForConnection:connection];
  NSString *identifier = [connectionInfo objectForKey:@"identifier"];
 
  if ([identifier isEqualToString:@"myFirstRequestIdentifier"])
    NSLog( @"The first request was successful!" ); // do something else
  else if ([identifier isEqualToString:@"someOtherIdentifierHere"])
    NSLog( @"The second request was successful!" );
 
  // Remember to remove the connectionInfo dictionary from our _connections 
  // ivar once the connection is finished loading
}
 
- (NSDictionary *)_infoForConnection:(NSURLConnection *)connection
{
  for (NSDictionary *connectionInfo in _connections)
  {
    if ([connectionInfo objectForKey:@"NSURLConnection"] == connection)
      return connectionInfo;
  }
 
  return nil;
}

In short, you will have to have a bunch of conditional if-else statements in order to properly respond to each different connection’s completion. The alternative approach is to write a URLConnectionManager class based on blocks:

// URLConnectionManager.h
 
@interface URLConnectionManager : NSObject 
 
- (void)performRequest:(NSURLRequest *)request 
         responseBlock:(void (^)(NSURLResponse *response))responseBlock;
 
@end
 
// URLConnectionManager.m
 
- (void)performRequest:(NSURLRequest *)request 
         responseBlock:(void (^)(NSURLResponse *response))responseBlock
{
  NSURLConnection *connection = [NSURLConnection connectionWithRequest:request 
                                          delegate:self];
  [connection associateValue:(id)responseBlock withKey:@"responseBlock"];
}
 
- (void)connection:(NSURLConnection *)connection 
           didReceiveResponse:(NSURLResponse *)response
{
  void (^responseBlock)(NSURLResponse *) = [connection associatedValueForKey:
                                                   @"responseBlock"];
  responseBlock( response );
}

This code also takes advantage of associated objects, another new language feature that allows us to avoid having to keep an array of connection info dictionaries around to store the associated responseBlock reference. (I am using an elegant category wrapper of the C API written by Andy Matuschak.)

Using this approach, the two connection requests can be implemented as follows:

// The first request
NSURLRequest *request = [NSURLRequest requestWithURL:myFirstURL];
 
[connectionManager performRequest:request 
                    responseBlock:^(NSURLResponse *response) {
  NSLog( @"Received a response from myFirstURL: %ld %@", 
                [(NSHTTPURLResponse *)response statusCode], response );
  // Perform whatever other specific magic you need for this response!
}];
 
// The second request
NSURLRequest *request = [NSURLRequest requestWithURL:mySecondURL];
 
[connectionManager performRequest:request 
                    responseBlock:^(NSURLResponse *response) {
  NSLog( @"Received a response from mySecondURL: %ld %@",
                [(NSHTTPURLResponse *)response statusCode], response );
  // Perform whatever other specific magic you need for this response!
}];

Note that there are no more if-else statements to deal with and even though the requests are being performed asynchronously, you can write a piece of code to deal with the response in the same spot that you make the initial connection invocation. This results in a much cleaner and more readable codebase.

Browse and/or download the full Xcode sample project on GitHub

Why support matters

2009-04-08T00:00:00-04:00

I’ve been a happy paid user of CSSEdit 2 for well over two years now. So when MacRabbit released Espresso it seemed only logical for me to try it out. I used it for about a week until I deemed it fit for purchase. I sauntered on over to the MacRabbit online store and discovered (as pretty much expected) that there was a discount purchase option for current CSSEdit 2 owners (at 49.95€ rather than the full 59.95€). To qualify one has to enter a valid CSSEdit 2 license code, so I dutifully looked mine up in my e-mail archives, copied it, and pasted it into the appropriate text field.

But instead of allowing me to complete the order I was greeted by a message stating that my license code “is not a valid CSSEdit 2 code.” Of course, I knew this claim to be false since this is the same code that works just fine in my still functioning copy of CSSEdit. Just to be sure though I headed on over to the MacRabbit support page where I hoped the license code lookup form would offer some kind of resolution. I entered my e-mail address (which I double-checked in my mail archives to be the one I originally used to register CSSEdit) to have my code sent to me. That didn’t quite work:

“Couldn’t find anything with this e-mail address! Are you sure it is correct?”

The next step was to shoot off an e-mail to the support people:

Subject: Espresso discount for CSSEdit 2 owners
Date: March 24, 2009 22:43:36 EDT

Hi,

I am trying to purchase Espresso via the CSSEdit 2 discount option. The form, however, is not accepting my license code:

Name: (redacted) Code: (redacted)

It claims this is not a valid CSSEdit 2 license code. Furthermore, I don’t appear to be in your lost code lookup database either.

Thanks.

Indeed, I sent this on March 24th. Somewhere around three weeks later I was left wondering if MacRabbit even has any support people. But just to be sure, I sent a follow-up on April 6th.

Subject: Re: Espresso discount for CSSEdit 2 owners
Date: April 6, 2009 18:17:59 EDT

A reply would be most appreciated as there are only 2 more days left in the trial period.

Since I have fit Espresso nicely into my workflow for several projects and its trial period is not of infinite duration, I had to make a choice. Either I could buy it at the full price of 59.95€ and be done with it, or I could partake of the MacHeist 3 bundle to get a license for considerably less than even the discount option I was initially trying to use. I wasn’t originally looking to get the MacHeist bundle since I would rather just directly pay the authors of the one application I actually need. Quality software development is hard work and developing a good application can take an inordinate amount of time, so I don’t mind rewarding such effort by paying a fair price.

Alas, quality software is a package deal. If I am going to pay a quality price I expect a certain basic level of support. It is rather difficult to justify paying full price for a piece of software when the support part of it is not being handled very well (or, seemingly, not being handled at all). Therefore, I went with the MacHeist bundle. The outcome is quite favorable for me as I can continue using Espresso to get work done. I can’t say it is nearly as favorable for MacRabbit’s cashflow.

It is certainly not my intent to bludgeon MacRabbit with this. They make fine software. But they do need to tighten up ship a bit, for their own sake.

Switching to Google Reader

2009-03-31T00:00:00-04:00

For several years now I have been using Cyndicate as my RSS feed reader. It is an excellent piece of software, but I have come to realize that I really don’t use any of the features that make the application so unique among its competition. I don’t use any filters, I don’t use ratings, and though I was taking advantage of its persistent architecture by filing interesting articles into various folders for future reference, it is a very rare occasion that I ever go into these archives to re-read anything I put there.

The most important thing I have been wanting for some time is something Cyndicate doesn’t offer right now. And that is the ability to synchronize across multiple devices. In particular I want to be able to check my feeds on my iPhone or MacBook Pro when I am away from my desktop machine. Sometimes I’d like to skim or even read read posts while standing in line.

In short, I have decided to switch to Google Reader for all of my subscriptions. Not content with using the web interface, however, I am trying out EventBox on the Mac side of this; for the iPhone it is Byline. Neither of these applications is really a terribly impressive fit and I will definitely miss Cyndicate’s persistence and overall polish. But for now this looks like a trade-off I am willing to deal with.

The trouble with Adobe

2008-09-21T00:00:00-04:00

I can’t remember a time when any one of Adobe’s Mac applications had an interface that felt like it truly belonged on my Mac. I don’t recall the problems being as pronounced in the pre-Mac OS X days, but there were always — at best — annoying quirks to be found. At worst, using their software made me feel like punching my computer screen.

But then Adobe brought their suite of applications to Mac OS X, and things got even worse. And ever since, they’ve spent each successive release screwing up their user experience with remarkable consistency. It’s to the point that the thought of punching my screen isn’t even enough. I want to reach into my Mac and beat the living snot out of every piece of the Adobe Creative Suite 3 I can find.

And, predictably, if the Fireworks CS4 beta is an indicator of what’s going to happen to the rest of the suite, Adobe obviously still doesn’t get it. Sadly, if a company has spent this many decades in the business and continues to utterly fail in this respect, it may be safe to bet they never will get it either.

Because when it comes down to it, I don’t need a window whose title bar is lacking a title and has instead been cluttered with a bunch of toolbar icons and a “mode” pop-up menu. In fact, I don’t even want a bunch of confusing interface “modes” to choose from. I don’t particularly care about throwing the palettes and everything else into one gigantic tabbed window. All of that is nothing more than extraneous fluff that’s detracting attention and resources away from what really needs to be fixed.

It is especially ironic that John Nack cites Panic’s Coda as an example of a single window application, because Panic would never ship something this utterly tasteless (not even as an internal beta, much less a public one). If you’re looking to Panic for inspiration, emulate their attention to detail. The suite’s problem isn’t that it needs a revolutionary new interface concept. Quite the opposite, in fact. The focus needs to be on the little things, because they all add up to one big mess of inconsistency and annoyance.

Perhaps Adobe needs to acquire some semblance of taste before worrying about tabbed windows and monkeying with title bars.

Lipstick on a pig

2008-09-12T00:00:00-04:00

Daniel Jalkut brings up some interesting points in his analysis of the new Microsoft ads. But I have to disagree with his fundamental assertion that the ad campaign is “genius.”

Far from it, in fact. For those who haven’t seen them yet, there are two spots out already. In the first, Bill Gates and Jerry Seinfeld go to a shoe store. In the second, the two live in some random family’s house. Neither ad appears to be actively marketing or selling anything. Jalkut counters this criticism by noting that the purpose is to build Microsoft’s image and brand, to “alter the long-term impression of the company that develops and markets the world’s leading desktop computer operating system.”

This would be fine, if it weren’t for the fact that Microsoft’s current perception is a direct result of its incompetently executed product line. The Zune continues to be a relative failure, seemingly everyone hates Vista, and its successor Windows 7 is, predictably, nowhere in sight. Releasing a lofty series of advertising spots with the goal of showing us some kind of kinder and gentler Microsoft will fall flat on its face without the product teeth to back it.

On the bright side, neither spot feels nor looks cheaply made. Bill Gates is better at acting than most people might expect. And the ads do have some funny moments. But the biggest problem isn’t the artistic quality of these clips. The issue is the deep disconnect going on between the “we’re cool” image that Microsoft is trying to push and the reality of what the company actually is.

Maybe this campaign is actually the signal of a Microsoft rebirth. That is, however, unlikely, especially given that Steve Ballmer is still the boss. Fundamental cultural shifts like this don’t usually happen without an executive shakeup, starting at the top. Some people are comparing these TV spots to Apple’s “Think Different” campaign. Yet they seem to conveniently forget that “Think Different” came onto the stage just as Gil Amelio was leaving it, among many other changes at the company’s core.

Until I see something similar happen at Microsoft, I don’t think this is much different than an artistically well-made Soviet government propaganda piece. And just like people found the same old regime hiding behind those, they will see that behind that pleasant, occasionally funny dialogue between Gates and Seinfeld still stands the same old Microsoft.

In the end, no matter how much lipstick you put on that pig, you’re still left with a pig.

A new platform in just a weekend

2008-07-09T00:00:00-04:00

Jesse Ezell believes it is too much to expect software developers moving to a new platform to spend more than a weekend learning the language, API, and tools:

Honestly, I don’t think most developers could get up and running with the SDK in a weekend and it’s a lot to ask to have people pour a lot of effort into an application without knowing whether it will actually be accepted.

To be fair, “get up and running” could mean a number of things. But the rest of his blog post is written in a tone which suggests that taking up iPhone development with no prior experience in Objective-C or Mac development should really be just that easy. Yet, software engineering requires “a lot of effort” on any platform. It is not outlandish to expect anyone who is serious about development — on the iPhone or elsewhere — to spend more than just a weekend getting up to speed with his new environment. (There’s a reason 464 page books are written on the subject. Hats off to anyone who can get through all that in a weekend.)

Ezell goes on to write about the model-view-controller design pattern:

The UI libraries are strictly MVC. You have no other good option. Either you write MVC, or you go home.

Not only is MVC a good choice for architecting solid applications, it is by far a superior alternative to the sort of schizophrenic “options” disaster Ezell is seeking. Perhaps going home is worth considering after all.

But the biggest indicator that Ezell just doesn’t “get it” is this:

As far as I could tell, the interface builder doesn’t really store the interface in a useful form. Early on, I tried to drag some buttons around and then go look at what it generated; but, as far as I could tell, the IDE appears to put the UI in some kind of resource file instead of generating something you can hand modify later.

The value of a generative approach in this situation is questionable. If any properties of these buttons need to be modified later, then the answer is to go back into Interface Builder and perform the modifications. The fact that a user interface designed in IB isn’t “hand modifiable” is not a bad thing. That this is even brought up as a criticism seems to strongly indicate a mental barrier erected by developers who want everything on the Mac and/or iPhone to be the same as what they are already familiar with, rather than a problem with Apple’s development tools.

Trial versions in the iPhone App Store

2008-06-26T00:00:00-04:00

Paul Kafasis lists a number of “Open Questions for The App Store” over at the Inside iPhone Blog. In particular, he asks about trial versions of software made available through the store:

We provide free trials of all our software for Mac and Windows. Just like test-driving a car, you can test our software, before you buy it. The goal here is to make sure our users know just what they’re getting, and that it will perform as expected. How will we accomplish this in the App Store? Can we have free software that’s just a trial, and then link it to a paid version?

Commenter Mitch Cohen replies:

The general consensus for trials seems to be to have two versions on the App Store – a trial and a real version.

I’ve been hoping since the announcement of the App Store that this isn’t how trial versions will be handled, as I believe this to be a completely uninspired approach to the problem. Why is there a need for two separate downloads? There should really only be one, which is automatically swapped for the full version if the user chooses to purchase the app.

Conceptually, I don’t see why it needs to be any different than an app on the Mac that you can “unlock” with a license code. Only that in this case you’d unlock it through the App Store, obviating the need for entering codes. Whether a new binary is actually downloaded and installed behind the scenes should be an implementation detail that need not concern the user.

Preliminary notes on Aperture 2.0 plug-ins

2008-02-13T00:00:00-05:00

Many Aperture users are starting to get excited about the upcoming Aperture 2 plug-in SDK. I think some people are expecting this to be some kind of “adjustments” API, perhaps allowing you to add additional effects filters on top of the standard adjustments like white balance, exposure, and so on.

Unfortunately, from what I’ve been able to figure out, the SDK will not support non-destructive adjustments. It doesn’t ask the plug-in to “apply” its changes anywhere in the current chain of non-destructive adjustments or anything of the sort. It creates a copy of the selected photo, lets the plug-in do whatever it does to that copy, and that’s pretty much it. So, if the user does some exposure adjustments, then uses some type of :filter effect" edit plug-in, and finally applies a few more standard (ie. contrast) adjustments, he won’t be able to change the initial exposure adjustments and have them reflected in the “edited” copy.

Using class-dump we can see that the following is all a plug-in appears to be able to do:

@protocol ApertureEditPlugIn
 
- (id)initWithAPIManager:(id<PROAPIAccessing>)apiManager;
 
- (void)editManager:(id<ApertureEditManager>)editManager didImportImageAtPath:(id)imagePath versionUniqueID:(id)versionUniqueID;
 
- (void)beginEditSession;
 
- (id)editWindow;
 
@end
 
@protocol ApertureEditManager
 
- (id)selectedVersionIds;
- (id)editableVersionIds;
- (id)importedVersionIds;
- (id)propertiesWithoutThumbnailForVersion:(id)fp8;
- (id)thumbnailForVersion:(id)fp8 size:(int)fp12;
- (id)editableVersionsOfVersions:(id)fp8 stackWithOriginal:(BOOL)fp12;
- (BOOL)canImport;
- (void)importImageAtPath:(id)fp8 referenced:(BOOL)fp12 stackWithVersions:(id)fp16;
- (void)deleteVersions:(id)fp8;
- (void)addCustomMetadata:(id)fp8 toVersions:(id)fp12;
- (void)addHierarchicalKeywords:(id)fp8 toVersions:(id)fp12;
- (id)apertureWindow;
- (void)endEditSession;
- (void)cancelEditSession;
 
@end

To get at the data required to actually perform any “edits” on the image, you have to send the editManager an editableVersionsOfVersions:stackWithOriginal: message. This causes Aperture to create copies of the requested images. That’s all the plug-in is then able to work with.

I’d love to be completely wrong on this, but it appears that these “edit” plug-ins won’t be that much different than using “open with external editor.” This isn’t looking to be nearly as powerful or “revolutionary” as a lot of folks are hoping for, I’m afraid.

Thoughts on the MWSF ‘08 keynote

2008-01-20T00:00:00-05:00

It seems only logical to write a post-”Stevenote” analysis following my obligatory Macworld 2008 predictions entry from last week. Complete rundowns of the keynote have been hashed out ad nauseam across the internet, so I will limit myself to just two points of interest.

The state of the Mac OS

Steve Jobs started off by reporting that Apple had so far shipped 5 million copies of Leopard, making this “the most successful release of Mac OS X ever.” According to Jobs, this constitutes 20% of the Mac OS X installed base. As a developer currently working on a Leopard-only product, I find these numbers to be outstanding news. Wil Shipley of Delicious Monster has noted several times that the type of users who quickly upgrade to the latest operating system are the ones willing to spend money on software, and as such constitute a terrific target audience for new applications.

One can only imagine what numbers Jobs will reveal at the WWDC ‘08 keynote this summer.

The MacBook Air

Unsurprisingly, the complaints, the incessant whining, and the usual proclamations of Apple’s impending doom due to the introduction of the MacBook Air are running rampant across the web. Price comparisons between it and other MacBook models are being used to justify claims that the machine is “overpriced” and “underpowered.”

Granted, the Air is obviously less powerful than its MacBook (Pro) counterparts and it does indeed cost more. But engineering a notebook to fit into the constraints this product dictated doesn’t happen by itself. Hardware engineers don’t work for free. Miniaturization is always expensive. Historically, notebooks have been less powerful than their desktop counterparts, yet tended to cost quite a bit more. Portability comes at a premium.

John Gruber published his take on the MacBook Air in which he says that it is “clearly designed as a secondary machine, not a main machine.” While I agree that this statement holds true for power users, I also think Scott Stevenson makes an excellent point that “there’s an entire category of users that could use this not just as their primary, but their only computer.”

I don’t know if the MacBook Air will be a bestseller, but I do predict it’ll be a success.

The eve of Macworld 2008

2008-01-14T00:00:00-05:00

With the Stevenote less than twenty-four hours away, it’s high time for the obligatory Macworld Eve post.

The big item that seems to be circulating the rumor sites is the so-called “MacBook Air.” While I think that name sounds rather pedestrian, there does appear to be some circumstantial evidence supporting the idea. But regardless of its title, I am betting we will be seeing some sort of slimmed-down MacBook, probably lacking an optical drive. Justin Williams has an interesting take on how this could be accomplished by Apple introducing a new digital software distribution model. I agree with John Gruber that it will feature a standard hard disk, not flash memory.

We may also see an updated iPhone. Revised Cinema Displays seem likely as well, along with a new Apple TV.

In any case, I’m sure it will be interesting. I’ll be following along via MacRumorsLive. Hopefully some people will be “twittering” live from the keynote as it unfolds, too.

Create a transparent fullscreen view

2007-12-15T00:00:00-05:00

The question of how to create a transparent fullscreen view came up on the cocoa-dev list recently. As it turns out, it is fairly trivial to implement.

The custom window subclass

Create the following header file:

1 // TransparentWindow.h
2  
3 #import <Cocoa/Cocoa.h>
4  
5 @interface TransparentWindow : NSWindow 
6 {
7 }
8  
9 @end

In the implementation all we need to do to make the window transparent is specify a NSBorderlessWindowMask and set the background color to [NSColor clearColor].

 1 // TransparentWindow.m
 2  
 3 #import "TransparentWindow.h"
 4  
 5 @implementation TransparentWindow
 6  
 7 - (id)initWithContentRect:(NSRect)contentRect styleMask:(NSUInteger)aStyle backing:(NSBackingStoreType)bufferingType defer:(BOOL)flag
 8 {
 9     self = [super initWithContentRect:[[NSScreen mainScreen] frame] styleMask:NSBorderlessWindowMask backing:bufferingType defer:flag];
10  
11     if (self)
12     {
13         [self setBackgroundColor:[NSColor clearColor]];
14         [self setOpaque:NO];
15     }
16  
17     return self;
18 }
19  
20 @end

Using the window class

To use this window you can either instantiate it programmatically or set it as the custom window class in your NIB file (I am using the latter method myself in a current project).

If you need a semi-transparent window, you can substitute something like [NSColor colorWithCalibratedWhite:1.0 alpha:0.5] for the color object in line 13.

And, depending on what you are doing, you may want your window to appear above the menubar. To do so, add [self setLevel:NSMainMenuWindowLevel + 1]; after line 14.