Craig Hockenberry (Iconfactory & Twitterific) is looking to encourage more developers to request Apple to support the use of Mac OS X Client (Desktop) virtualization and not just the Server version of Mac OS X :

http://furbo.org/2008/03/21/vote-for-virtualization/

Of course I have a vested interest in this and am not without bias on the issue - but all the same he raises valid points…

There’s been some ‘grumbling’ (here and here) about some of the restrictions that are placed on application developers and their products if they use the iPhone SDK.

Many of the commenters seem concerned that the SDK is much more restrictive than ‘regular desktop’ development, with restrictions on running in the background, a lack of access to certain parts of the platform, and pieces of functionality present in desktop Mac OS X but missing from Cocoa Touch.

Why are things so different ? Technical challenges ? No. The reason - in two words is: Legal Liability.

I think Apple is very concerned that there is a danger someone would try to use their iPhone in an emergency (to dial 911) and have it fail because of a failure (or out of control) third-party application. If that happens and lawyers get involved I don’t think they’re going to  go after small  one-person software developers with buggy code. Rather they’ll go for the deep pockets at Apple.

Yes Mac OS X uses protected memory, and is a pre-emptive operating system. But it’s still vulnerable to people using too many resources and there are places in the OS where the failure of one application at the wrong time can lead other applications to fail (for example Disk Notification on the desktop  Mac OS X can cause Finder to stall if you fail to respond to the notification request in a timely manner).

Personally I’m grateful for a little care, attention and large walls in this space - my phone is probably more important than my desktop, especially in an emergency, making sure it’s always there when I need it is very important.

Part of the iPhone SDK is a requirement to spend $99/year if you wish to distribute your application through the iTunes Store.

The $99 also gives you the ability to load your application into your own phone for testing without needing to use the store. Apparently it does this by giving you a certificate which you can use to sign your application, the same certificate needs to be installed into the phone for the application to run.

This is part of Apples mechanism to ensure that only approved (blessed) applications will be distributed through the store - apps on the store will be signed with a different certificate that Apple will control and that certificate will be installed on all iPhones running V2.0 of the iPhone OS.

What about beta testing your application on a larger pool of users than just your phone - testing is always a good thing - but right now it’s unclear how you can distribute your application to a pool of testers and let them install it. Using the store won’t be a good thing because that exposes the app to everyone. Require every tester to have paid $99 for the tools to self-sign (as it’s called) and install the app on their phone ? That seems expensive. Distribute your certificate with each app and have testers install it alongside the app ? Better - but still the question of exactly how is the app installed.

How to test the fruits of your labours seems quite unanswered right now !

One of the things that Google announced with Android (though they’ve revised the rules once already) was a competition with between $25,000 and $275,000 in prize money for the best mobile applications on Android.

Today’s ‘One More Thing…’ announcement from Steve Jobs during the iPhone SDK event was for John Doerr from the VC Partners Kleiner Perkins Caulfield & Byers announcing that they’ve created a $100 million fund to invest in the development of applications for the iPhone. You can find the FAQ here - Kleiner has one of the better track records of picking good tech firms to fund. Gaining their funding would be a huge leg up for any developer !

Frankly I prefer Apple’s approach - it seems a little more professional and a little less like a competition for students !

Although I might have ordered a new zippy MacBook - my old PowerBook is still proving its use: highlighting pieces of code that are just too slow.

In the iOnTV UI application the schedule grid (list of what’s on) is a critical part of the main window. I noticed that as the database of program information got larger scrolling performance in the schedule grid (going backwards/forwards in time) was terribly slow on my PowerBook.

A little time with Shark showed that I was spending 80% my time in the ‘fetch schedules on a station between two times’ method. This method used a simple predicate to fetch only those schedule details fulfilling the arguments :

NSPredicate *predicate = [NSPredicate predicateWithFormat:@"((station == %@) AND (time >= %@) AND (time <= %@)) OR ((station == %@) AND (time < %@) AND (endTime > %@))", self, startDate, endDate, self, startDate, startDate];

A little thinking about it and I realized that the logic was overly complex and could be simplified :

NSPredicate *predicate = [NSPredicate predicateWithFormat:@"(station == %@) AND (((time >= %@) AND (time <= %@)) OR ((endTime >= %@) AND (endTime <= %@)))", self, startDate, endDate, startDate, endDate];

I don’t need to compare against the station more than once - start with everything on this station, and then consider only those things that start between the two times or end between the two times.

Result ? The fetch is now less than 10% of the CPU usage when changing the start time in the schedule grid ! Much better ! I still have a couple more optimizations to make - but watch those predicates !

I shipped an early version of the iOnTV app a few weeks ago now and have had a few bug reports etc. from the early adopters brave enough to try it out.

One thing that’s become clear is that the current setup process is

1. Not quite robust enough
2. Not ‘guided enough’

Looking over the logs of users with problems I’ve been quite surprised at how ‘random’ people can behave in attempting to get things to work.

I tried to set out a step by step approach that should give a complete list of all the stations available to iOnTV, however when it fails people step outside of the step by step approach (which is easy to do) and get lost.

What it comes down to I think is a fundamental difference between how programmers think and how non-programmers (users) think :

One of the mental skills that a good programmer develops that becomes a way of life is that we have a linear thought process with branches and that we’re particularly good at back tracking to the last junction and taking a different branch whilst remembering all the other junctions and branches we’ve ever seen (or made) in the past. In other words we’ve programmed ourselves to be just as linear as the machine we’re programming.

‘Users’ on the other hand are not so programmed - in fact they’re far more random in their actions and generally don’t maintain such a linear approach to things. They ‘jump’ from one spot to another without remembering (or paying heed) to where they were.

How can a developer cope with this ?

1. Work with QA people who are just as random - this is probably one of the fundamentals of QA and why programmers should not do QA and why a QA person should not write code (white box testing etc. is an engineering process not a QA thing). One of the best QA people I ever worked with (Baron Arnold at Be) was also capable of some of the most ‘random’ actions. Infuriating as an engineer to deal with (not personally - BA is one of the nicest folk out there), but definately ‘real world’
2. Don’t give choices without considering the consequences. For iOnTV this means I need to write a ‘wizard’ (as much as they can be loathsome) that will guide people through the step-by-step setup process to scan all the devices and find all the stations that iOnTV can receive.

I gave a presentation this evening at the monthly CocoaHeads meeting here in Boston. The topic was ‘Leopard Features in iOnTV’. You can download the slides of the presentation here.

Jason Fried has a nice article on ‘Why Enterprise Software Sucks‘ with which I agree entirely.For the last 10 years I’ve worked entirely on projects that individuals use - indeed the lack of the individual focus was why I left two previous employers. If I decide to move on from my current position I suspect that a shift away from focusing on the individual will be part of the reason why.One of the great things about the iOnTV project is that it’s entirely individually focused and I think this is also a driving force behind many of the ‘indie’ developers out there today for the Mac. I really don’t think Gus Mueller had the large art department in mind when he wrote Acorn, and Wil Shipley clearly doesn’t design Delicious Library for ‘libraries’. Both of these folks (and so many, many more) are focused entirely on the individual. 

One of the new ‘developer’ features (i.e. a new API) in Leopard is ScriptingBridge. It’s a significant improvement to the mechanics of driving one application from another using AppleScript/AppleEvents.It’s always been possible to use NSAppleScript in Cocoa to send AppleScript to another application basically using a simple string :

NSString *appleScriptSource = [NSString stringWithFormat:@"tell iTunes to add (POSIX file \"%@\")", moviePath];

NSAppleScript *aScript = [[NSAppleScript alloc] initWithSource:appleScriptSource];

NSAppleEventDescriptor *aDescriptor = [aScript executeAndReturnError:&anError];

Not too bad, and you do get the returned data and in theory you can use that in subsequent scripts to affect the added track (adding metadata, setting it’s kind etc). However it’s slow and still really rather clumsy, and if you want to do any real argument munging you may be forced to revert to NSAppleEvent directly which is really painful and exceedingly longwinded.ScriptingBridge in Leopard makes this much, much more straightforward and friendly. Using the command line sdef and sdp tools you can create an Objective-C 2.0 header file which contains all the scriptable classes and elements of an application. Then you can include the header file and ScriptingBridge framework and the above code becomes:

iTunesApplication *iTunes = [SBApplication applicationWithBundleIdentifier:@"com.apple.iTunes"];

[iTunes setDelegate:self];

NSArray *filesArray = [NSArray arrayWithObject:[NSURL fileURLWithPath:moviePath]];

iTunesTrack *theTrack = [iTunes add:filesArray to:nil];

At first glance it looks like this is about the same code, but it executes much faster (no script parsing/compilation to AppleEvents). The returned object is a real Objective-C object so in the next line you can do :

theTrack.videoKind = iTunesEVdKTVShow;

theTrack.show = movieTitle;

Note - you can use Objective-C 2.0 style properties. Much neater than lines and lines of coded AppleScript. There is one catch - the header file is built from parsing the scripting definitions in the application (the sdef). These can still tend to be rather opaque - and in particular rather ‘type free’. AppleScript generally is a very weak typing language, and if you’re used to strong typing (C like) languages it can be a bit of a mind bending experience. In the iTunes case I struggled for a couple of days with the add: to: message - the generated header says :

- (iTunesTrack *) add:(NSArray *)x to:(SBObject *)to; // add one or more files to a playlist

There’s no indication of type for the contents of the array. Experience with ScriptEditor (and the initial NSAppleScript solution) suggested I should be able to just use an NSString in the array with the POSIX style path. However that failed with a ‘not found’ error when the message was sent. I initially thought it was a problem with the to argument needing to be a valid playlist and I spent quite some time convincing myself that I had a valid playlist argument (basically iterating things in the iTunesApplication object to get down to a playlist). Finally I went back to ScriptEditor and launched it from Terminal with the AEDebug=1 and AEDebugSends=1 environment variable set. This shows on stdout a debug of the AppleEvents that ScriptEditor sends. Looking at the log I could see that ScriptEditor was converting my POSIX path into an ‘furl’ (File URL) ! The lightbulb came on and I adjusted my code to do likewise with an NSURL and everything ‘just worked’ as I’d hoped it would. It is odd however - the definition in the scripting def file actually refers to an ‘alias’ an old world MacOS 7 concept that’s pretty much fallen out of use. I expected the path string to be converted correctly, after all I’d already proven that other AppleEvents in other applications (Sketch2 in Leopard is a good test case) that take alias get converted, however it appears as though there’s something more specific in the iTunes case that needs the file URL.

A little late (I was sick on Friday) but here are some notes on Thursday evenings CocoaHeads meeting in Boston.This was my first visit so I didn’t really have any expectations, mostly I expected it to be a chance to meet a few other developers. It was a smallish crowd (around a dozen) with a mix of some students, some developers from other large companies such as myself (and another colleague from Avid), some software contractors, and a couple of ‘independent’ developers who are actually earning a living from Mac OS X software (Daniel Jalkut of Red Sweater and Ken and Glen Aspeslagh from Ecamm Network)Some demos were given :

• Jeff Dlouhy gave a demo of TabPosé a new feature he’s working on for Camino as part of the Google Summer of Code project. TabPosé is a neat looking idea, and though I’m not a big camino user (for some reason I seem contented with Safari) I can see it being ‘emulated’ in Safari in the future.
• Ken Aspeslagh gave a demo of the weeks ‘hottest’ product iPhoneDrive. Ken and Glen wrote the product over the course of about 5 days and managed to get it out and ‘plastered over the web’ earlier in the week. It’s a great solution to the fact that the iPhone doesn’t have a ‘disk mode’ (unlike the iPod) and they got a lot of press for this product last week including a nice commendation from David Pogue apparently. Ken said that actually the toughest part of the whole project had been the ‘finder like’ portion of the UI which uses an NSBrowser in column mode. This isn’t a class I’ve played with but apparently it’s very ‘picky’ and doesn’t handle things like drag and drop at all well.
• Dan Grover gave a demo of ShoveBox. It’s a small app which sits on the menu bar and provides a ‘drop point’ for ’stuff’. Things can be ’shoved’ in to the box and then organized, indexed and sorted. You can then pull things out again for use in other apps. It’s a little like the old Mac OS < X scrapbook, only way prettier and with 10 times the features. There was some general encouragement to Dan to ‘just ship’ and save some of the features he’s still trying to work the kinks out for V1.1 I think it was pretty clear for many of the developers in the audience that ‘getting things out there at V1.0′ is critical.

The meeting was great - it was a good opportunity to meet with other developers and talk about some of the issues facing small software developers. I look forward to going again and perhaps giving a demo of my own project !Oh and in one of those ’small world’ moments - it turns out that Ken worked at Avid until about 2 or so years ago !