Just because OSObject is pretty abstract and can’t be constructed on it’s own that doesn’t mean you can ignore its methods. In my case I was stymied by an apparent ‘hanging’ reference even though I could see that my very simple OSObject subclass was allocated only once and free() was called as the reference count went to zero.

My mistake was not to call the baseclass OSObject::free() from my own method – so of course although I thought (knew) I was done with the object the rest of the IOKit/kernel wasn’t so convinced.

So… don’t forget that OSObject still does very important things – even if it does seem a bit of a placeholder !

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…

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.

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 !

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 !

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 !

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.

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.