My apologies for not catching this one before launch day, it should have been found earlier and fixed in advance of the iPhone update. Signal was tested thoroughly against earlier development versions of the iPhone 3.0 software and I made the mistake of assuming that no compatibility-breaking changes would be made to the browser in the final release. Not so lucky.

The problem was caused by Signal’s use of a persistent HTTP connection back to the desktop application for fast interface updates. When putting the device to sleep with such a connection running Safari was suspending all JavaScript execution and Signal was not able to recover when the device was woken up again.

The 1.1.6 update resolves this issue and offers an added bonus – by taking advantage of network state notifications in Safari to fix the problem the iPhone interface now reconnects faster than ever. This fix has also served as a good reminder that even small OS changes can have a big impact.

This will bring up the web control interface on your device and you’ll be able to use your Palm Pre to control your media player!

To enable ChumbiTunes to talk to Signal an XML file needs to be installed alongside Signal, instructions are available on the Google Group. This file will be bundled with the next Signal release so the setup step will not be required in the future.

It’s great to see users extending the application this way, if you have a project you’d like to integrate Signal with just let me know and I’ll be happy to help.

Since it’s not exactly obvious how to narrow down the focus to particular development topic, I wanted to share a bookmark I use to browse recent Mac and iPhone development questions:

Stack Overflow: Mac/iPhone

This works by browsing a combination of tags and has turned out to be a great addition to my list of time killers.

I’ve set up a system to keep the two in sync (they’re actually generated from the same source files) so as tips and troubleshooting suggestions are added they’ll be available both here and within the application’s bundled help file.

The Apple examples for handling this situation recommend creating two separate views sets: one set for 10.4 and earlier and another set for 10.5 and later. Unless your layout is significantly altered between the two OS versions this has some drawbacks. You now have two sets of views to build and maintain, and if a future version of OS X alters the System Preferences window size again you’re going to need yet another set.

Luckily there is a simple solution. Although System Preferences does not resize the width of our view for us we can do this ourselves quite easily by matching the content width of the System Preferences window.

- (void)mainViewDidLoad {
    NSRect rect = [[self mainView] frame];
    NSWindow *systemPrefsWindow = [[NSApplication sharedApplication] mainWindow];
    rect.size.width = [systemPrefsWindow contentRectForFrameRect:[systemPrefsWindow frame]].size.width;
    [[self mainView] setFrame:rect];
}

We could simplify this code a bit by using the superview’s frame or the contentView of systemPrefsWindow, but contentRectForFrameRect: is used for a couple of reasons. We need to resize the view before it is first displayed, but the superview will not have valid size information until didSelect, at which point our view is already on the screen. In addition, by obtaining the content rect from the window rather than the frame of the contentView we are making no assumptions about the size of whatever contentView currently represents.

This simple change sizes our main view to the width of the System Preferences window, our autoresizing rules are now applied, and viola: a single set of views that scales to a System Preferences window of any width.

To work around this issue I made a modification to John Haller’s excellent registry tweak for disabling the Windows key to create a single file that disables both the Windows and context menu keys in one go:

Registry Patch: Disable Windows and Menu Keys

One caveat: This file does make a change to the Windows registry, so use at your own risk. You can open the file in a text editor to see exactly what it modifies.

To install, download the .reg file into the guest OS, double-click it, approve the prompts, then restart Windows. The keys should now be ignored by Windows and you can ⌘-Tab or ⌘-Function Key without any more annoying menus.

I considered splitting off a personal blog for this kind of thing so that the Alloysoft site could be kept nice and clean, free from rants or indecipherable technical posts. But the more I thought about what I wanted to write the more I realized that a lot of it might well be of interest to customers. Even discussion of a technical topic can give insight into how a developer approaches their products and what they care about. It also helps to keep the site active, showing that work is ongoing and possibly giving a preview or two about what’s coming next.

I hope that some of what starts to show up here proves useful, and as always look forward to hearing your feedback. The beautiful thing about software is that if something doesn’t work out it’s usually not too hard to change back.