For now you can only install the beta of OS 4.0 if you are using a Mac, so it was up to the trusty MacBook Air to get the job done. Installing (or should I say “Restoring”) OS 4.0 was a breeze through iTunes. My only caveat was when it came to activate the phone. However, A quick trip to the Apple Developers site to pair my device ID with my developer account and I was on my way.

Primarily I’m a designer before a developer and I have no real experience in developing apps for the iPhone, unless you count web apps. I hope to change this over the coming months, but for now I was curious to see what immediate benefits the end-user would gain from 4.0.

Customisation? Steady on!

Customisable home screen background and redesigned dock

Far be it from a “tentpole” feature, the customisable home screen background is the first thing you notice in OS 4.0. It’s by no means an original or groundbreaking feature, but it is a welcome change from the solid black that many have become accustomed to. However, I did feel a little bit embarrassed for Mr Jobs during the keynote when he decided to demo the feature (at least twice) to a crowd of developers. We have also been blessed with a redesigned dock, which now takes design cues from the dock in OS X and on the iPad. It’s a definite improvement on the previous dock, which had started to look a bit dated.

Multitasking, sort of, finally…

The main touted feature has been multitasking, or for the time being at least, fast app switching. At the time of writing there are (to the best of my knowledge) no apps that have been updated to take advantage of Apple’s multitasking APIs. As a consumer I am most excited about background audio, being a keen supporter of Spotify Premium. I love Spotify so much that since installing OS 4.0 I haven’t even bothered to sync any music from my iTunes library, Spotify caters for 99% of my music requirements.

Putting applications into folders, a novel concept

Expanded folder view in OS 4.0

I think my favourite addition in 4.0 is the new folders feature. I don’t know about you but I have a fair few apps and having the ability to organise these now is a godsend. It was a royal pain to try and segment different categories of apps onto different pages in some convoluted attempt to keep everything organised. The functionality and the UI design is pretty much there, although I’m not overly keen on the background texture they’ve opted to use for expanded folders. It’s also a slight annoyance that each folder can only hold a total of 12 applications. I don’t see why you shouldn’t be able to scroll within a folder, but that’s just me.

There are of course more features in iPhone OS 4.0, I just wanted to provide a quick overview of the ones I’m most excited about.

Nobody’s perfect

I’ve tried to test multiple Exchange accounts, without a great deal of success. This may be a server or account setup issue over a 4.0 bug so for the time being I’m willing to let that slide. Being a beta there are of course bugs; here are just some of the UI ones I’ve stumbled across so far:

• Deleting the most recent photo from your Camera Roll doesn’t update the icon in the camera app
• Sending an SMS or MMS causes the conversation to jump around until it has finished sending the message
• In some scenarios the camera app toggle switch used for selecting photo or video disappears
• Attempting to MMS a photo straight from the Camera Roll results in the “Send” button disappearing

Final (preliminary) thought

4.0 is a necessary and welcome progression of the iPhone software. However, I would have really liked to have seen a revised home screen announced, similar to that of Android and Windows Mobile 6.x. Having a badge icon on top of the relevant icon simply isn’t enough, especially for business users. A bit more customisation with the message alerts wouldn’t go amiss either. Seriously, how hard can it be – we can already customise the ringtone, to an extent.

Say what you like about Apple, I believe they still have a winner with the iPhone. They’ve done what they’re best at; take an existing product and made it friendlier and more marketable to the masses. Having said that, ever since introducing the iPhone the competition has soared and I can’t wait to get my hands on a Windows Phone 7 device later on this year to see how it compares. With Android also gaining more popularity as big mobile manufacturers take the plunge, 2010 is set to be a great year for the consumer.

I can only hope that Apple release a killer hardware update in the Summer to keep the playing field equal, otherwise I fear that not even the mighty app store can prevent them from falling behind.

A bit of background

I follow a lot of American TV shows and used TVRage to find out when the next episode for each of my shows was airing. This was great, but I was becoming increasingly frustrated by navigating the TVRage website on my iPhone. Using the TVRage API I quickly threw together a quick “web app” which simply listed out the shows I follow and displayed when the next episode was on. As I neared completion I realised that some of my friends, and others too, may also find this a useful thing to have. With the help of my good friend Mark, Prowlr was conceptualised, brainstormed and born.

Design considerations

Deciding on the appearance of the app was pretty straightforward. I wanted to promote the familiar components of the iPhone user interface, whilst adding in my own unique styling and functional elements to set it apart from a generic app. The design for the app was done in Adobe Fireworks CS4, which is my personal design application of choice.

Certain considerations had to be kept in mind when designing an iPhone web app:

• Buttons should be larger than normal to facilitate ease of access
• Text should be sized reasonably to ensure legibility
• Use of white space kept to a minimum to make the most use of the available viewport

Navigating pages in a web app

Early on I discovered my first big “gotcha!” in developing an iPhone web app; you can’t link to separate pages if you want your users to be able to launch your app from their home screen. If you do, your web app is closed and the new page opens in a bog standard Safari window. Not ideal.

This was resolved with a fantastic plugin called hashtrack.js which provides an easy way to handle navigating pages. Below is a very cut down example of how I implemented the plugin in Prowlr, using the jQuery library.

$(function() {
    hashtrack.onhashvarchange('page', function(value) {
        initPage(value);
    });
});

function initPage(data) {
    $('#content').load('pagehandler.php?p=' + data);
}

Hopefully this is pretty straightforward to grasp. Basically, when the hashtrack plugin detects that the #page value has changed, it passes the value into my initPage function. The initPage function takes that value and appends it to the end of a file request. The requested PHP file uses that value to determine which page content to display, whether it’s the login form, a list of shows, etc. and loads that into a <div> with the ID of ‘content’. Changing between pages is simply a case of linking to a ‘page’ – <a href=”#page=home”>Home</a>.

Obtaining TV series information

I mentioned TVRage earlier. They have a fantastic database of TV series and also provide an API to request data from their database. I initially used their API to populate my own database with TV series information, but found it quite a cumbersome process. The main quarrel I had with it was that the XML files they provided weren’t always presented in a logical way, which made extracting data from them a bit cumbersome.

After a quick session on Google I stumbled across TheTVDB.com, a user-driven TV database with a far superior API. Changing providers mid-development wasn’t ideal, but it did give me a chance to perform a quick code review and tighten up some of the functions used to process data from an external source.

When a user searches for a TV series, Prowlr does a live search on their API to see if the show exists. It returns any matches as a list of seriesand gives the user the option to add each to their favourites. When a user does add a series, a process is triggered:

1. Make sure that the user doesn’t already have the series in their favourites
2. Check our local database to see if we have any data for that series; if we don’t, request the full series information (including episode data) from the API
3. Remove the series from the user’s search results

Keeping the TV series data current

One of the main benefits that TheTVDB.com has over TVRage is when it comes to updating series information. Every hour I request a file from TheTVDB.com, which contains a list of all series and episode IDs on TheTVDB.com that have changed since the last update. With each ID returned I check our local database to see if any of those series IDs match. If there is a match, pass the series ID into my update script, which grabs the latest series data from their API. It’s a similar process when it comes to updating individual episode information.

Prowlr in the wild

At the time of writing, Prowlr has had 2,140 users sign up since our launch a few weeks ago. This is mainly due to Prowlr becoming a featured web app and a staff pick in the Apple Web Apps Directory. It has been an interesting to see how my code has stood up to the number of users accessing it on a daily basis. To date there hasn’t been any significant problems to speak of and miraculously the system has scaled up rather well. User feedback has been great, too; there have been really positive comments on the AVForums, Twitter and various other places.

Plans for the future

I’d be lying if I said there weren’t any plans to extend Prowlr; full details will be released in the near future. One thing that the new version of Prowlr will sport is a refreshed user interface and enhanced usability. There will also be some great new features introduced, all designed to make Prowlr the best free web app out there to keep tabs on your favourite TV shows.

If you have an iPhone or an iPod touch, please check it out – prowlr.tv

I wanted to display a gentle reminder to users who hadn’t launched the app from their home screen, but I also didn’t want to intrude on users who already had done this.

Reading through Apple’s Safari Reference Library again, I came across a snippet I’d missed the first time around.

window.navigator.standalone

This returns a boolean true or false depending on the outcome, which can be translated into a simple code example:

if (window.navigator.standalone) {
   alert ('Thanks for launching this app your home screen')
} else {
   alert('Add this app to your home screen for the best experience')
}

You could modify the example to show/hide a friendlier message, or something completely different!

Co-workers of mine will admit (with a sigh) that I am a HUGE fan of the television show “24″. Early in January of a new year a group of us get together with some pizzas, beers and watch the 4 hour premiere via a projector and some big speakers. It’s sort of become a tradition these days and as long as they keep making new seasons, we’ll keep doing it.

Seeing as everyone who attends our makeshift premiere now has an iPhone, I decided to create a 24 Countdown Clock iPhone web application.

Designing and developing for the iPhone is, on the whole, a dream. You only have to worry about it looking right in one browser and if it looks right on yours it’s going to look right on every other iPhone owner’s browser too.

Apple has some great documentation on developing web applications on the iPhone. For my web application I used several of their meta tags and a link tag, all of which I’ve detailed in this blog post.

As with all meta tags, these should be placed in the <head> section of your HTML.

<meta name="viewport" content="width=320; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;" />

This meta tag is the first fundamental step to creating your own web application. By setting the viewport width and scaling options it disables the user’s ability to zoom into your web application, giving it the behaviour of a native iPhone application.

<meta name="apple-mobile-web-app-capable" content="yes" />

This meta tag helps you break away from the look of Safari, allowing you to create a true replica of a native iPhone application. It removes the address/search bar from the top of the window as well as the navigation bar from the bottom of the window. However, it will only do this if your web application is launched from a web clip icon on the home screen.

<meta name="apple-mobile-web-app-status-bar-style" content="black" />

This meta tag changes the status bar (carrier name, time, battery icon, etc.) background colour to black. Whether you use this tag or not depends on the overall style of your web application. As my own uses a dark background this was ideal for me. As with the previous meta tag, this will only be applied if your web application is launched from a web clip icon on the home screen.

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

To complete the authentic iPhone application look you can define an icon to be used when a user adds your web application to their home screen. The icon should be 57 by 57 pixels in dimension. Any larger or smaller and the icon will be scaled.

With the framework in place, all that was left to do was apply a background image and style the countdown text.

Sadly, the Safari browser on the iPhone only has limited CSS3 support. I was able to use the text-shadow property on the countdown text, but I was unable to use a custom font face to replicate the “24″ LCD-style digits in the logo.

As there is no Flash or Java support on the iPhone in Safari, nor do I want there to be, I used a JavaScript based solution. Using jQuery and the Countdown plugin, with a few lines of JavaScript the countdown clock was easily implemented.

$('h2#countdown').countdown({
	until: new Date(2010,0,17),
	format: 'DHMS'
});

The live web application lives at http://joeserg.com/24/

It’s hardly the best iPhone web application out there, nor is it the most complicated. However, by starting out with a simple web application and learning the basics, I can look forward to developing bigger and better ones in the future.

All I need to do now is find the time to create them.

That worked well until it was pointed out that, from a usability point of view, it would be far better to let the user click on the icon to select the relevant radio button, as well as the radio button label. At first I thought this would be a pain to implement but, as usual, jQuery shone through.

After one line of jQuery, the user could now click anywhere on a table cell and the child radio button would be selected.

$("td").click(function() {
     $(this).find("input").attr("checked", "checked");
});