One of the compelling reasons to developing web-based or hybrid mobile applications is being able to use the tried and true HTML/CSS/JS stack, which allows your app to be used (with some minor restrictions) directly as a mobile website or to be compiled and distributed as a native application using a tool such as PhoneGap.

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:

In your .m file:

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.

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:

After a rather delicious holiday dinner at Nora in DC, Nicco, EchoDitto's president, got right down to business.

"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."

And then, from a tiny little bag, he pulls out this gorgeous matte black box with the word "iPhone" emblazoned on the side. If you've ever heard the sound of collective jaws dropping, you know what sound was heard at that moment.

So now, I've got an iPhone. Correction. We've all got iPhones (with the exception of JP and Tom - more on that in a minute). And this is a pretty sweet thing.

I was lucky enough to be the first person in the company to receive a phone that night, and for most of the rest of the party I was too busy gushing over the fact that I, too, was now a denizen of the land of iPhone to have any sort of meaningful conversation. I couldn't wait to get home and try it out, although to say I was cautiously optimistic would be an understatement. I had heard numerous reports of five-hour phonecalls to AT&T's activation department; I really didn't want to spend half the night on the phone with a CSR only to find out I had to pay $500 to get the darn thing.

Thankfully, my worries were for naught. I got back to the hotel, plugged in the phone, typed in my name, address, social security number (egh...) and there it was: a fully-functional iPhone. It quite seriously took two minutes. I then proceeded to call my girlfriend, my dad, and then Jason (who had apparently already gone to sleep - whoops, sorry dude) to make sure a sufficient number of people knew about my great geeky step forward.

They say the honeymoon is great, that it's the rest of the marriage that can be a pain, but again, I found this to not be the case. I was lucky enough to get my iPhone right as my contract with Sprint was expiring, so I wouldn't have to pay hundreds of dollars a month to have service with two companies. I was, however, concerned about how long it would take to port my number from one company to the other.

The process was surprisingly easy, just like everything before it. I called Sprint, who, because I was keeping one of my lines to give to my girlfriend as a Christmas gift, were happy because they were getting a renewed contract from a new iPhone owner, and they told me they'd get everything ready and that I could go ahead and call AT&T. So, I made the call to AT&T, and other than a rather annoying 'location change' they had to process (due to my phone having a 202 area code, but my account being based in NYC), my old number was on my new phone in what I would consider record time.

The minute my number was moved over, I felt a pang of guilt. There lay my Treo 650, my good friend through two years of calls, emails, and texts, never to be used again. And then I remembered that the iPhone ROCKS, and felt better.

How, specifically, does the iPhone rock, if at all? This has been a point of contention on many a tech blog post, but I think they're just being nitpicky. The iPhone completely changed the way carriers and hardware providers interacted: the former way of doing things was that the carrier determined the hardware to be used, and in so doing, made the hardware awful. Now that device manufacturers are seeing that they can turn the tables and build better (and more profitable) devices, and carriers are realizing that the market won't stand for what they were taking in the past, the iPhone is going to see much more competition. When you consider this fact, the addition of great email and web functionality, coupled with an iPod video, are icing on the cake.

I personally enjoy how I can switch between tasks, and keep multiple browser windows open. The Treo 650 didn't even come close to this functionality - if you answered a call, or sent a text, or did pretty much anything other than keep your browser window open, it would lose your session. On top of that, the Treo didn't handle text messaging or email very well, and the interface and settings were ridiculous. Not so with the iPhone - Apple spent a lot of time getting the intuitive nature of the device as good as it is, and it shows.

Now, here's what sucks. Where's the flash? I saw a vid on youTube a while back that made fun of a recent iPhone ad: "It's not the mobile web. It's not WAP. It's not text. It's the web. On your phone. Without flash." Cut away to a screenshot of a tiny question mark, the telltale sign that Safari for iPhone doesn't recognize a plugin. I don't know how many sites use flash, but I know that a good number of the ones I visit every day utilize it in one way or another.

Next, what's the deal with downloads? Half the time I try to download something from Safari I get a "Safari can't recognize this filetype" message. PITA.

And finally, the much-ballyhooed (and soon fixed?) lack of cut and paste. I have NO clue how they could have left out this most basic of functions, but hopefully it won't be left out for much longer.

Really, as a first-gen phone of its type, the iPhone succeeds in a lot more areas than it fails. Which means that the second gen will be even better. Tom and JP are hedging their bets that a 3G iPhone will come out at MacWorld, and while you can be almost sure that one will be released eventually, I'm not sure that January gives the developers enough time. One thing we can be sure of, however, is that an SDK will be released really, really soon, which for those of us (like me) who get nervous at the idea of jailbreaking a $400 piece of glass and plastic. Until then, well, I'll just have to settle with being more productive, more connected, and more entertained - all in one package.