It's the little things that make a good site into a great site. I'm sure that the iPhone's ability to add bookmarks to your home screen is one of its most underused features, but with advances in HTML5 and Mobile WebKit, it is becoming a more useful tool.

Since 1.1.3, iOS has supported custom bookmark icons. The icons are square PNG files (iOS uses 57x57 pixels for its native apps, but I've heard of other sizes, such as 45x45 working as well). You can either name the file apple-touch-icon.png and add it to the root folder of your site, or use the following link tag to point to a custom path:

<link rel="apple-touch-icon" href="/Graphics/iphone-icon.png" />

Mobile site libraries, such as jQTouch, include settings to automatically insert the above code.

Time for part two of my series on iPhone development basics. Last time, I gave some tips on writing settings to a binary file using Apple's Foundation Library. This time I'll show you how to retrieve those settings -- either from a cached version of the property list or from the filesystem itself. As with the first article, let's dive in head first with some code.

First of all, you'll want to add a static NSDictionary member to your settings data controller class for storing the cached settings.

In your .h file:

NSDictionary *cachedSettings;
@property(nonatomic, retain) NSDictionary *cachedSettings;

In your .m file:

static NSDictionary *cachedSettings;
@synthesize cachedSettings;

Here's the loadSettings function. As you can see, I've implemented it as a class method -- there's really no reason to treat your settings data controller as anything other than a singleton with some class methods. Some argue against using singletons in Objective C. In most cases, I could be persuaded to agree; however, app-wide settings don't really make any sense implemented as anything except as global variables, and singletons are essentially the OOP equivalent of globals. I'd love if someone wanted to discuss this in a comment thread, however.

+ (NSDictionary *)loadSettings
{
	if (cachedSettings == nil) {
		NSArray *dirArray = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory,
			NSUserDomainMask,
			YES);
 
		NSString *path = [NSString stringWithFormat:@"%@/settings.bin", [dirArray objectAtIndex:0]];
		NSData *settings = [NSData dataWithContentsOfFile:path];
 
		if (settings != nil) {
			NSDictionary *dict = (NSDictionary *)[NSPropertyListSerialization
				propertyListFromData:settings
				mutabilityOption:0
				format:nil
				errorDescription:nil];
 
			if (dict == nil)
				NSLog(@"Error in loadSettings");
 
			cachedSettings = [dict copy];
 

Over the past month or two, I've been fortunate enough to be able to put some work into an iPhone framework that interfaces with Drupal sites. In doing so, I've learned a number of things about the various Cocoa frameworks that might be useful to others. As such, I'm going to run a short series of blog posts documenting some of these discoveries.

First up is the subject of data storage -- particularly the storage of simple settings. There are several ways to accomplish this in the Cocoa touch framework. If your settings are fairly complicated and you don't expect your user to alter them very frequently, it's recommended that you hook into the Settings application (the way that Mail and Safari do, for example). Of course, this is cumbersome by virtue of the fact that you have to exit your app and start up Settings in order to change anything. If your user is tweaking settings frequently, this could spell a UI disaster.

Another option is simply to write settings to a file somewhere in your app's sandbox. For our Drupal/iPhone framework, I've adopted this approach. For most of our sites, I don't expect users to be dealing with very many settings -- username and password, of course, and perhaps a few other options tied into the Content Profile module. Therefore, while we can't take advantage of Apple's powerful Settings framework, data storage and retrieval is still very manageable.

It's probably been close to a year since the iPhone-optimized DC metro status page Meenster.com vanished from the scene (it now resolves to a blank page.) For those of us who ride the metro regularly, knowing when the next train will arrive before you enter the station is a major convenience -- especially given last month's tragic metro collision and subsequent service disruption.

Well, wait no longer - the DC metro on your iPhone is back!

http://echodittolabs.org/wmata

With fabled AT&T coverage coming in October, you'll never miss a train again.

And now for the nerdy details:

We're not using any of WMATA's APIs or feeds, but rather just old fashioned screen scraping using regex. Since the train status pages on wmata.com are already pretty handsome, I elected just to scrape out the body and wrap it in Joe Hewitt's excellent iPhone CSS.

Suggestions, complaints? Drop me a note!

So, as Phil mentioned, we all got iPhones as a holiday bonus. And they're pretty great. JP and I held off until Macworld, lest we miss out on a new 3G handset (a longshot, I know). When that didn't happen I immediately scurried over to Pentagon City and bought a beautiful internet lozenge.

Since then I've been figuring out all of the amazing things it can do for me. On Thursday I had a stroke of inspiration. I've been looking longingly at Bluetooth presence detection setups for a while. I like the idea of having my hardware respond to my proximity, but I've got some reservations about wasting a Bluetooth dongle (and server, and Bluetooth-on-Linux configuration time) on the effort. The iPhone is the first mobile I've owned that does wifi. This seems like an opportunity to do presence detection on the cheap.

My approach is pretty simple: ping the iPhone. If it's there, I probably am, too. But how to ping it? The iPhone uses DHCP to get an address. At home I've got a router running the SveaSoft firmware. It's simple enough to configure DNSMasq to always dole out the same IP address to my iPhone's MAC.

Then I wrote a bash script to send three pings, check the number of successful replies, and log the result to a text file. I set it up to run on a minute cron and let it go overnight:

PING_COUNT=`ping -c 3 192.168.2.21 | grep "bytes from" | wc -l`
test $PING_COUNT -eq 3 && RESULT="here" || RESULT="not here"
RIGHT_NOW=`date`
echo "$RIGHT_NOW - $RESULT" >> status.txt

Here are the results from the first 24 hours:

"When we were setting this up, we thought, 'You know, I bet they want something better than bonus checks. They want something different, something way cooler than cash.' So we decided to get all you one of these."