a glob of nerdishness

September 22, 2009

Be careful when using Uniform Type Identifiers

written by natevw @ 6:14 pm

Someone posted a lengthy article today (here, and cross-posted here) claiming that even though Snow Leopard ignores creator codes, applications can use Uniform Type Identifiers to match a file in a generic format to a specific editor. As far as I can tell, someone is wrong on the internet.

There are two potential problems with expecting UTIs to take the place of creator codes as the article claims. The first is that applications are not encouraged to make their own app-specific UTI if one already exists. Consider the case of a JPEG file, which is a common format that many apps can open. With creator codes, an app that creates a JPEG file could make it easy for the user to re-open it later in the same app by setting its creator code. In common practice, an application would just be using the predefined “public.jpeg” UTI when dealing with JPEG files, instead of an app-specific code, as Apple had never encouraged otherwise.

Using an application-specific UTI even when a predefined one exists is a clever idea. Update: no it’s not. Doing so would mean no other app could open your app’s files. That would be bad, too. Or it would be, if not for the second problem. A file’s UTI is determined by Launch Services, and there isn’t a good way for an app to set one itself. (I would love to be wrong on this!) When Launch Services needs to know a file’s UTI, it looks at the file’s extension and picks just one of potentially many matching system and application defined UTIs.

Launch Services’ behavior in this regard is no better than file extensions. It’s worse, in fact. Consider a “.log” file: This common extension could be used for a system log, an application history, a GPS tracklog or any number of file types. If an application lets a user open any file with the “log” extension, it will be able to open its own files just fine. If, on the other hand, an application wants to use the new, shiny, recommend UTI system and offers to open files with UTIs of “com.example.tracklog” instead, it sets itself up for failure. If Launch Services has decided that the “.log” extension means “public.systemlog”, all .log files will have that type and the user won’t even be able to open a file from within our tracklog application itself.

Uniform Type Identifiers are a neat concept, and I recommend you use them. They do offer many advantages, including the potential to eventually replace creator codes in a future version of OS X. But you must use them with care. The main pitfall is Launch Services. You can use UTIs and UTI concepts so long as you always keep in mind that a file may have a completely different UTI on a user’s machine than it does on yours. When creating an open dialog, include the extensions you may be able to open in addition to UTIs. When defining a document type in your Info.plist, use the old (deprecated!?) CFBundleTypeExtensions instead of LSItemContentTypes. Otherwise, another application on your user’s system could end up overriding your extension’s UTI and your application will be unable to open its own files.

Launch Services should really report a different UTI based on which application is requesting a file’s type, or report a set of all potentially matching UTIs instead. This would affect some file-handling parts of the Cocoa framework as well. I reported this problem with the current way file UTIs are assigned in rdar://problem/6590416 this past February. I hope it can be fixed, because Uniform Type Identifiers are a win in the long run.

September 18, 2009

Grand Central Dispatch

written by natevw @ 12:55 pm

Mike Ash just finished another accurate and detailed series covering an interesting low-level topic, this time explaining all about Grand Central Dispatch.

Apple’s thread pools help reduce processor contention, but I’d been mulling over how to best use queues for performing file operations optimally. Mike nails it in this last post: create a hierarchy of custom queues that end up funneling operations through one custom queue per disk. It’d be interesting to wrap this technique in a higher-level API that dealt with disk and other bottlenecks in a more automatic manner.

September 12, 2009

1 working home button in my pocket

written by natevw @ 7:07 pm

My iPod touch’s home button was growing gradually unreliable, and finally stopped letting me switch between apps right before this week’s iPod press event. I was hoping Apple would finally announce a new iPod touch that could serve as an iPhone without the phone, with a camera and mic and compass and GPS. Instead they announced the opposite.

This was the second time the iPod touch’s home button had failed me. The first one failed under warranty, but between two bad hardware experiences (actually three, long story…), a lack of compelling new features, the lack of independently published applications and my own lack of income, buying an expensive replacement seemed like a bad idea.

Instead I spent $3.98 to have OWC ship me some nylon iPod case opener tools. Once inside I found a lot of lint, dozens of tiny screws and chips and connectors, and underneath it all:

Disassembled iPod touch home button mechanism

My iPod’s home button!

I used some rubbing alcohol on a q-tip to clean it and its target off a bit, then used a very short slice of electrical tape to hold the little clicker sticker back in place.

First generation iPod touch home button homebrew fix

Take a look at this iPod Touch repair guide for a better walkthrough of the internals. Because of the way the lower assembly is glued down, the screen does need to be taken off to safely pry the button board from its sticky bondage. There was dust under the glass anyway, so it was nice to get a PEC*PAD in there for some cleanup.

In addition to the case opener (good for prying PCBs from their glue as well) and a very tiny Phillips screwdriver, I found a brownie cutter useful. Its large surface area helped me pry up the battery pack without the acute pressure of a flathead’s blade; a metal spatula or wide paint scraper could work as well.

After reassembling most of the device, I was relieved and more than a bit surprised to see it spring back to life. Despite the second-rate button, some impressive engineering went into this device. It is incredibly small, yet was able to survive an hour of my (very careful!) amateur hamfisting. I can now return to my Home screen at will; all other systems are still go, too!

September 2, 2009

Use Trail Location as a Core Location testing framework

written by natevw @ 8:55 am

Trail Location is a subproject I’ve been working on at Calf Trail. Its primary goal is to be a drop-in replacement for Core Location that can use position data from any location service.

This enables a number of new possibilities.

But first a demonstration

More interesting location data in the simulator

Testing a Core Location app in the simulator is really boring. Apple might eventually wire the simulator up to Snow Leopard’s Core Location implementation, but that would just move your app from Apple’s headquarters to yours. Trail Location lets you send your own test data, which your app receives just as from Core Location.

Trail Location includes a sample app for your device that can send locations to the simulator as you pan around the map. It should also be easy to make an app that plays back recorded location patterns.

Send real GPS data to an iPod touch during development

This one’s a bit more complicated, but worth mentioning. The first two iPod touch models (hopefully NOT the third, but we’ll see) don’t have GPS chips and rely exclusively on Skyhook positioning, which is based on visible wireless networks. With Trail Location, you can use a laptop and a GPS receiver for better results in rural areas. (I bought an Amod ABG 108 Bluetooth GPS mouse for about $20! Unfortunately, you can’t use a Bluetooth GPS directly even with a second-generation iPod touch, because it would degrade the core experience or something.)

Trail Location includes a sample Mac app that can pass locations from gpsd to a listening iPhone app via WiFi.

Better Core Location on the desktop?

Snow Leopard adds the Core Location API to Mac OS X. This is interesting, because while on current hardware the Core Location framework itself is still limited to Skyhook positioning, the rest of the Mac platform is much, much more developer friendly. Trail Location could serve as the glue that connects third-party apps to third-party GPS receivers using the same well-designed API that Core Location provides. Just like you can use your device to send data to Trail Location on the simulator, you could use an iPhone as a GPS mouse for a desktop app.

Eventually, I hope Trail Location can grow mature enough to be left in code that ships to end-users, giving more people the benefits of an open location platform. Currently, you should consider it as an alpha release, NOT ready for anything but debug builds. Right now the code is overbuilt (debatably) but under-implemented (definitely). We’ve released it now so that it can help other developers test their Core Location apps, and so that any progress towards the long-term goals can be influenced by other developers. Get the source at Google code; it’s shared under a non-viral license but your patches are welcome.