We’ve also added a new sub-forum to our support forum*, specifically for iPhone app queries. Feel free to check it out and chime in!

As always, if you have any questions, comments or feedback, please feel free to contact us!

* Unfortunately, iPhone-optimization for the forum is still in development.

What is it?

Out of the box, the iPhone does a great job of synchronizing with the Mac’s built in PIM applications, Address Book and iCal, and bookmarks, courtesy of Safari. After years of somewhat kludged together sync solutions on the Palm and Windows Mobile (at least on the Mac side of the fence), the iPhone feels great. One thing quickly becomes apparent, however: after editing a friend’s number in Address Book, I finished a few things, grabbed my phone, and was out the door. When I went to call him, I noticed that my recent edit was not reflected on the iPhone. As it turns out, the iPhone syncs only when it’s placed into its dock (or, manually, when you right-click on it in iTunes and select “Update”). Any changes you make between docking and undocking, however, are lost. Since my phone spends most of its time in the dock, these have to wait until the next time I come back to my computer.Enter iPhone AutoSync! iPhone AutoSync monitors your three synced applications, and, when changes are made, makes a note. After a few minutes, if no more changes have been made, it triggers a sync with your phone. Thus all your information in up to date in both places, pretty much all the time.

The Fiddly Bits

Warning: Here there be geekery. Skip past if you’re not interested in the behind-the-secenes.

The main challenge when writing a faceless app is to minimize resource usage. Since iPhone AutoSync is always running, we don’t want to hog too much memory, processor time, or other system resources. However, we also want to make sure we are responsive, and the user doesn’t have to wait too long for us to kick in.Our first attempt used kqueues. Mark Dalrymple and Aaron Hillegass’s wonderful book, Advanced Mac OS X Programming has a great set of examples making use of kqueues. In a nutshell, a kqueue will allow you (among other things; they’re very powerful) to watch a directory for changes. When any application reads or modifies files at that path, your application gets notified.Pretty much just the ticket, right? As it turns out, we were using far too big a hammer here. On a tip from Dave Nanian, we grabbed Notification Watcher, and found that each time you edit an Address Book entry, or modify an iCal event, a series of global notifications gets sent. By listening for those, we were able to find out each time the user’s data is modified, in a much lighter-weight system than kqueue.iPhone AutoSync has a giant bottle-neck, however, and that’s iTunes. Since we keep close watch on our target applications, we could immediately sync the phone each time they change. However, a sync is a relatively expensive operation: we don’t want the user’s iTunes hogging CPU and changing its UI every 30 seconds as they plan out their week’s schedule. The answer here was an aggregator: each time a change event occurs, we set (or reset) a timer. Once no change events have fired for a few minutes, we assume the user has finished editing, and fire the sync. This meant that there would be a slight delay between a change and the iPhone being totally up-to-date, but after a bit of experimentation, we think we’ve found the right mixture between the two extremes.

Finally

Getting iPhone AutoSync out the door reminded me how hard the last 10% of a software release can be. This post was written using Daniel Jalkut’s brilliant new blog tool, MarsEdit 2, just released. Congrats to Daniel on a great product, and conquering that last 10%; I feel your pain (though MarsEdit is of course a much bigger production than iPhone AutoSync.)

As you may have noticed, we’ve revamped our site!  First, let me introduce myself: My name is Glenn, and I’m the Stand Alone, Inc. web guy, and I oversaw and implemented our recent redesign. The redesign, as conceptualized by Ben and myself, was intended to make the site easier and more intuitive to navigate without sacrificing the more advanced features that our users enjoy, and I believe we succeeded!

While most of the redesign was focused on layout and presentation, there are a few new site features, such as a smarter download page that automatically serves up the best download based on your browser. We also streamlined our catalog and download index pages, made our version pickers more obvious, and a bunch of other minor tweaks that make the site a bit easier to peruse.

As always, we love to hear comments and suggestions on how to improve the site, so please let us know what you like, what you don’t like, or what you’d like to see added or improved!

Back when we started out on Newton, Palm was the new kid on the block. As we watched, it became the dominant player, and Newton began to fade. In February of 1998, Apple pulled the plug on Newton. Fortunately, we’d already begun the migration to Palm, so this just accelerated our actions. However, the loss of a platform is never enjoyable (especially one that was as fun as the Newton was). For the past several years, we’ve watch Palm cede more and more of the market to other operating systems (Windows Mobile and Blackberry, here in the US; Symbian in Europe).

Palm’s ‘new foundation’, however, is pretty much the ‘low fuel’ light for Palm OS as we know it. Sure, the new devices will most likely run OS 5 (Garnet) applications, but all the new, cool features will not be available unless you’re running natively.

So, again, we’ll be making a platform transition. However, this is now a known path for us: after the jump from Newton to Palm, the Palm to Linux switch will be smoother and more predictable. In addition, after shedding the limits that Garnet has imposed upon us, a fresh new OS with a solid core is going to be a breath of fresh air.

We’ve been meaning to start a blog for a while, this seemed like a good excuse: over the weekend, I entered the Iron Coder contest and won!

Iron Coder is based on the Iron Chef concept: you’re given an area of the operating system to work in (in this case the Screen Saver framework), and a theme (here it was “Life”). With those two constraints, you’ve got two days to put something, anything, together.

What to write?

With the work we’ve done on Quickipedia, I’ve developed a familiarity with Wikipedia and its layout, so some sort of Wiki-based screen saver seemed a good place to start. One of my favorite features of Wikipedia is its ‘Random Article’ function. I like to request a random article, and then follow its links, picking up odd bits of knowledge along the way. I figured I could recreate this sort of ‘random walk’ in a screen saver.

Wikipath

Wikipath starts with a random Wikipedia page, and draws a portion of it on screen. It then randomly jumps to one of the wiki-links on that page, and draws it next to the original. It keeps this up until it hits a dead end page or runs out of room, then it starts over.

A Plan

With my goal firmly in mind, I now had to figure out a way to get there. The first order of business was to figure out how to display a fragment of a webpage, using as little memory as possible (I wanted to have a whole bunch of them onscreen at once, so creating a lot of WebViews would blow memory usage way out of line for a screen saver.) With a little research on WebKit, I was able to create a WebView with a random Wikipedia page, and then use a handy method of NSView to pull out a thumbnail image:

	- (NSData *) dataWithPDFInsideRect: (NSRect) aRect

Taking this data, and then creating an NSImage with it, gave me a pretty decent snapshot of the page. I could then re-use the same WebView for additional downloads, and save on memory. Now, I had to figure out a way to extract all the links on the page, so I could randomly jump to one. I considered manually hunting for them, or perhaps using ruby or perl to pull them out. I recalled that JavaScript lets you access all the links on a page with a simple array. Looking at the WebView docs, I found the perfect method,

	- (NSString *) stringByEvaluatingJavaScriptFromString: (NSString *) script

The JavaScript I wanted to use was dead simple:

	"document.links"

You have to be a little tricky here, since you can’t just convert from whatever JavaScript returns to a nice, usable NSString object. First I needed to grab the number of links, and then iterate in Objective-C through them. The source code is included in the download, for those who want to see the nitty-gritty details.

Finally it was just a matter of adding a few (primitive) graphics so that you could visually follow the page as it wends its way around your screen.

I’m a Winner, Baby!

The upshot of all this is I won a free to ticket to C4, Jonathan ‘Wolf’ Rentzsch’s awesome Mac development conference, hosted right here in Chicago. In addition, I inherit the judging duties for the next Iron Coder, which promises to be an adventure.

Thanks!

Many thanks to the Judge of Iron Coder V, Jonathan Wight. I think there were nearly twice as many entries as the previous contest, and Jon put in a lot of time evaluating ‘em. Check out some of the other great screen savers and applications!

What’s Next?

Wikipath isn’t done yet. Right now I’m working on the ability to select a page that strikes your fancy, and jump to that in your web browser. Hopefully I’ll have that up and running over the weekend. A couple of optimizations are also planned, so it’ll run a bit more smoothly and not hog all the processor. Stay tuned!