Pursuit of Simplicity

These days, desktop applications are usually launched either from the Windows Shell, Mac OS Finder, KDE Desktop, etc. Less well-known is that these operating systems all also allow applications to be launched directly from the command line, terminal, DOS prompt, etc. When launched from the command line, applications can also receive command line arguments.

Consistent with our goal of making AIR-based applications as much like regular desktop applications as possible, this also works for AIR-based applications. In AIR, those command line arguments are received via the InvokeEvent dispatched from NativeApplication. This can prove useful in a variety of situations, especially when writing scripts for testing or other automated work.

On Windows and Linux, invoking AIR-based applications at the command line is straightforward. On Windows, inside the application's install directory you'll find an executable with the application's name; that's the thing to run from the command line. On Linux, the executable is inside the "bin" subdirectory.

On Mac OS things are slightly trickier. In Finder, applications appear to be a single file, but they're really a folder with with an extension of ".app" and a particular interior folder structure. To launch them from the command line with arguments, you have to dig into this structure and find the executable. For example, to launch an application named HelloWorld you'd run:

/Applications/HelloWorld.app/Contents/MacOS/HelloWorld

You can also run an application on Mac OS via the "open" command, but open doesn't support passing any command line arguments to the application.

One final note: You can also pass arguments to your application when debugging with adl. However, since adl takes its own arguments as well, you need to separate the adl arguments from the arguments intended for the application with the double-dash argument, like so:

adl HelloWorld-app.xml -- a b c

In this example, the application will receive an InvokeEvent with arguments a, b, and c.

Posted by Oliver Goldman at 1:13 PM | Permalink | Comments (4)

I switched to using iCal when my MacBook Pro became my primary email machine a while back. Continuing to run Outlook was too much trouble because it meant keeping a virtual machine running all the time. I tried Entourage, too, but iCal was simpler yet sufficient for my needs. True, iCal doesn't integrate with our corporate calendaring solution--but in my job that apparently doesn't matter much.

I found that iCal under 10.4 was a bit on the slow side. Performance enhancements were rumored for 10.5; another reason to look forward to the upgrade. Yet after the upgrade, iCal seemed as slow as ever--and sometimes worse. It's easy to find complaints about iCal on the web, I couldn't find many practical steps for speeding up. Time to do a little digging.

My events are divided among five calendars. With all five displayed, even changing the view from week to week was slow. I'd seen one reference on the web about a particular calendar giving someone trouble, so I tried mine one-by-one. Sure enough, just one calendar--let's call it "A"--was responsible for the slowdown.

This matched up with a hunch of mine: there was a repeating event on calendar A that was basically un-editable in iCal. It didn't cause a freeze or crash, but it hung iCal up for so long that I never had the patience to wait it out. Searching through the calendar event-by-event for a troublemaker could take a long time; starting with this troublemaker seemed like a good idea.

First, I exported the calendar to an .ical file which--thankfully--is a line-oriented text format. It was over four megabytes. Running "grep SUMMARY A.ical | wc -l"--SUMMARY is the field that contains the name of each event--showed it contained about twelve thousand events. I'm busy, but I'm not that busy.

Following up on my hunch, I searched manually for the repeating meeting. There were many, many instances--over eleven thousand. That's a lot--so many that if I'd been to this meeting once a day, every day since I was born I would had my eleven thousandth meeting just a few years ago.

How did there get to be so many instances? That I don't know. I suspect it's related to the fact that this meeting occurs four days a week, so there's probably no built-in recurrence rule for it. Worse, on one of those four days the meeting is in an alternate location, so that's an additional exception to the recurrence. Even so, eleven thousand is clearly excessive.

Should iCal have been able to handle this event without slowing excessively? Hard to say. It's not a large number of events in absolute terms; someone with ten years of experience and eight meetings a day would have more events in their calendar. Still, I suspect iCal scales more gracefully across a large number of different events and that the culprit here is the bizarrely large number of instances for the same (recurring) entry.

I removed all instances of the meeting by hand, deleted the original calendar, and imported the patched up version. Result? iCal is fast again.

Bonus question: Given what little I've said about our development process, what meeting do I attend four times a week?

Posted by Oliver Goldman at 9:45 PM | Permalink | Comments (0)