About the Oz Weather iPhone Web Application

Having been a bit of a weather geek for most of my life (and even studied it an uni), I have a keen idea of what I do and don’t like about many of the existing web-based weather services out there. The biggest problem is that many of the forecasts and observations that you find on the web for Australian cities is either inaccurate or out-of-date or both. This is typically because the major web weather suppliers are based in the USA and run their own weather forecast models, lacking the local input and expertise which our own Bureau of Meteorology is much better at providing in our neck of the woods.

Consequently I had been building my own world weather website with data sourced from the official government weather agencies, and when the iPhone 3G storm started brewing I was keen to see what kind of weather application Apple had built in. Well it was certainly attractively done, but – you guessed it – the application was supplied by Yahoo!, who themselves had sourced their data from weather.com ie. a US supplier. Although this was disappointing for me, it did immediately suggest that there was an opportunity to build something more useful for Australians.

iPhone applications come in two varieties:

  • Web applications – these are websites which are viewable on the iPhone’s built-in Safari web browser. They range from existing websites which have simply been enhanced for better viewing on the iPhone screen all the way through to custom built websites which are only viewable on the iPhone, and may also take advantage of a subset of the built-in capabilities which are exclusively available on the iPhone, such as its GPS, contacts list etc. Web applications cannot be listed in Apple’s App Store – rather they can be found by users only by looking through Apple’s web-based listings pages (free submission), or else via good old web search.
  • Native applications – these are applications which can be built only on Mac computers with Apple’s developer tools, using Objective-C within the Touch Cocoa framework. Consequently they can take full advantage of all the whiz-bang functionality that Apple’s design geniuses have seen fit to include. These applications can be made available in the App Store and iTunes, and sold for a nominated price from which the developer receives 70% – provided that you register as an Apple iPhone developer, pay the US$99 fee, and have sufficient patience to await their approval.

So the first choice I had to make was which type of application to build. Whilst a native application has many advantages (a bit sexier, lets say), it does take considerably more resources and time to build one. Also it seemed emminently reasonable to build, launch and run a web application first, and then later convert it into a native application if it still seems warranted based on the success of the web application. So that is the course I chose.

I am glad to be able to say that I was encouraged and supported in this by Mick Liubinskas (www.pollenizer.com) from whom I also received some screen layout and design input (Pierre Sauvignon of www.pxcream.com fame).

Given that I already had PHP code in place to obtain and store Bureau of Meteorology data every 10 minutes (permission gratefully received), the main job involved the design of an attractive interface that fits into the 320 pixel available width, and avoid the use of events such as mouseovers, which are simply meaningless on the iPhone. There were several technical hurdles to overcome. One is that a web application runs inside a browser on the iPhone, and consequently has its screen real-estate reduced due to the address bar. But it can look just like a native app provided that the browser’s address bar can be hidden, and earlier Apple documentation indicated that a certain meta-tag could be added to the page to automatically hide it. Alas it just didn’t work. After further research, a different technique was discovered which did the trick reasonably well – using javascript to scroll the bar out of the way after the page loads.

Two weeks later, the site was up and running: i.ozpda.com/ozweather/, and as I queued to buy my own iPhone from the Apple store at 6:15am on Monday morning, I was rather chuffed to be able to demonstrate it to a queue-mate on their iPod Touch using Apple Store’s own WiFi network.

Although an iPhone web application can be made available and advertised on the web like any other website, to have any real chance of success, the application should be registered with Apple, for appearance on their own listings: http://www.apple.com/au/iphone/webapps/. However, Apple’s submission process was fairly painless – and two days later the Oz Weather web application listing appeared on their site – complete with a “Staff Pick” endorsement.

Although I have an idealistic streak which has always made me shy away from adding third-party advertising to my sites, I wanted to try to at least re-coup some of the time and effort involved. Further advice from Mick at Pollenizer indicated that Google AdSense and AdMob were two good possibilities to try. AdMob have been heavily promoting their iPhone-dedicated advertising (and even targetted me directly via the Apple application listing), so I decided to give them a go first. One small problem to start with – if you want to receive payment from them which is not a $US cheque, your only other option is to set up a Paypal account. I would have preferred not to have to set up yet another financial mechanism which would likely be little used apart from for this specific purpose, but it was quickly done, and the addition of a few lines of code to the site allowed for a single ad, with a customisable background colour to be placed across the top of the page, hence not interfering too much with the visual flow of the page.

Although the AdMob advertising started well on the first day (during which a Sydney thunderstorm attracted a peak in site usage), the placement of ads available suddenly dropped to almost zero for the next two days, despite apparently having plenty of inventory. Another annoyance here is that the inclusion of ads seems to sometimes prevent the browser address bar from retracting. I suspect some kind of technical glitch is afoot, and may now see how Google compares while waiting for a reply to my AdMob queries.

And in the meantime I decided to go ahead with a conversion and enhancement into a native application, including current weather radar images and more detailed current observations. That is one of the advantages of putting out a web app first – lots of great suggestions for new and better features for the next iteration. So keep watching this space for more news as it happens… though will perhaps not be updated quite as often as the weather data on Oz Weather!

A footnote: As you might guess, there are currently many great new ideas being formulated right now for apps which have only just become possible with the GPS, accelerometers and slick animations that have been made so accessible to developers in the iPhone. Truly, Apple has just raised the bar by not just one, but at least three notches, in my estimation.

Graham Dawson

1 thought on “About the Oz Weather iPhone Web Application”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s