As part of the Parking Mobility iPhone app I’ve been building, I wanted to integrate a simple “Quick Start” help guide to show people how to use the app without being intrusive.  I wanted to use the project’s branding as much as possible, and give the user a feeling like they haven’t left the main portion of the app.  So I wanted the user to be comfortable with it, and always have a quick way to close the help window to get back to the app.

One of the iPhone applications I’ve written, Parking Mobility, is primarily a map-based application.  Since the iPhone’s screen is so small, we want to maximize the screen real-estate while still providing navigation bars for users to interact with.  To that end, the app uses a black-translucent navbar and toolbar at the top and bottom of the screen.  In the past this has never been a problem, and most mapping applications do the same thing.  I recently submitted a huge update to the app which is a complete re-write as a 100% native Objective-C based application (all vestiges of PhoneGap having been removed).  With this latest submission though, we’ve run into problems.

Read on for more, and what I’ve done to (hopefully) get around this.

Recently I was working on a refactor of one of my CPAN modules which, among other things, involved changing its name from Test::A8N to the specific Test::Story.  Doing so made me think about the process I usually go through when I consider releasing a CPAN module.

I’ve already posted before on how to set up Hudson to compile and build iPhone applications, but I just had a “OMG I <3 Hudson!” moment just now, and felt I had to share it.

I do most of my mobile development literally while I’m mobile; on the train during my morning commute, from coffee shops on the weekend, or in front of the TV in the evenings when I’m winding down for the night. Because of this, I don’t have any consistent time when I’m making checkins, nor do I have the time to create builds for my beta users.

Wow the past few months have been quite a wild ride, and a ton of things have happened!  So much has gone on and I’ve been writing so much software that I haven’t had the time to blog about it.  In the time I’m not writing software, I’d rather spend it with my wife than spend it writing about the software I’d written.

Over the past few months, while the PhoneGap team started a major refactor of their codebase, I spent some time learning more about Objective-C and UIKit, and discovered that writing native software on the iPhone is a heck of a lot easier than I’d previously expected. It shouldn’t have surprised me, because I’ve heard rave reviews from developers I have a great deal of respect for, and it also shouldn’t come as a great shock that Apple treats their developer SDKs with the same degree of polish and attention-to-detail that they do to their hardware. So while I was working with PhoneGap I’d contributed a number of plugins exposing the iPhone’s native UI elements to JavaScript-based apps, I’ll no longer be updating or adding any new plugins.

My friend Scott McWhirter, who heads up the Vancouver Perl Monger’s group, asked me yesterday to give a last-minute talk on anything in particular at tonight’s Vancouver.pm meeting. He wasn’t exactly begging, but I know he’s short on speakers this month, and he wanted something interesting to show.

So I decided I’d talk about building and testing Perl-based projects using Hudson. I’ve been planning on writing a blog post on the subject for the past month, but haven’t found the time to finish off the post properly. So if you’re interested in the topic, and you don’t want to wait for me to get around to writing about it online, please feel free to drop by tonight!

Just like most of the men at my office, I’m participating in Movember this year, largely due to the razzing I got last year when I didn’t participate. Yes, I’ve succumbed to peer pressure…what would my mom say? At least it’s for a good cause. Of course, the first question I asked is “What’s Movember?” It’s a fundraising event for prostate cancer where men grow mustaches during the month of November.

Plenty of times in applications, especially on mobile devices, you just need to tell your users to hold their horses and wait while your application processes something in the background.  Maybe you need to query some data from a remote server, save a file to disk, or maybe you just need to do some number crunching.  Whatever the reason, you don’t want your user to think the program has crashed if you don’t give them some sort of visual feedback that you’re busy and they just have to wait a few seconds.

An important part to any application is issuing a simple alert to your user. Whether it’s to tell them about an error that just occurred, or if you need to ask them a simple question, giving a message to your user is about the most basic part of any app.

Sadly, when you try to rely on the ever faithful “alert()” function in JavaScript inside a PhoneGap application, you’ll notice the alert box it shows is titled with a very unprofessional “index.html” across the top. Not only does it make it obvious that the app they’re interacting with is actually HTML-based, but you can’t convey the importance of one message or another with a title. Most people only ever read the title anyway, so in order to provide this capability to your application, PhoneGap has an answer for this problem.

One of the integral features of the next application I’m releasing (I’ll write a post about it soon, honest) is the capability of saving a copy of the user’s work in my app to their Photo Library. For a while now I’ve been wanting to be able to save screenshots from within PhoneGap for two main reasons:

1. Be able to export the user’s work and allow them to email it, import it into other applications, etc.
2. Save a screenshot to their splash-screen image, that way when the application restarts it shows their previous state while they wait (for example, the Notes application on the iPhone).

I’ve implemented #1 right now, meaning with a simple non-blocking call you can save the current view to the photo library. In the future I’ll add another three options: Save to the default splash-screen image, save to a file, and save and upload to a remote location.