Oz Weather AJAX Refinements

Oz Weather - sample contracted view with 4 day forecast
Oz Weather - sample contracted view with 4 day forecast

Although Oz Weather is a fully functional app, as usual I feel driven to improve it further. So what is the next step? It is to improve the speed and efficiency (and hence user experience) by moving towards a purer AJAX implementation, and using whatever data compression is possible in delivering the data to the browser.

The existing application renders the page from PHP, and then uses javascript to update the time values on the page at regular intervals. The rendered page also includes the following meta tag in its header.

<meta http-equiv="Refresh" content="600" />

This forces a page refresh every 600 seconds (10 minutes), to ensure a fairly small time lag between data availability and the user’s view.

The ideal I wish to achieve is to render the initial page layout purely as HTML, and then deliver the weather data via AJAX as needed ie. using a javascript timer to decide when the data content needs to be refreshed, instead of requiring a reload of the entire page. Consequently, apart from the initial page load, no further html needs to be delivered.

The first step was to create a PHP data query module, delivering the data in JSON format. For future flexibility (and readability), I also added an XML format option, of which a truncated example follows.

<?xml version="1.0"?>
<forecast>
 <numdays>2</numdays>
  <day1>
   <date>2008-08-25</date>
   <dayname>Monday</dayname>
   <min>8</min>
   <max>18</max>
   <icon>34</icon>
   <desc>Fine. Partly cloudy.</desc>
  </day1>
  <day2>
   <date>2008-08-26</date>
   <dayname>Tuesday</dayname>
   <min>8</min>
   <max>20</max>
   <icon>32</icon>
   <desc>Fine. Mostly sunny.</desc>
  </day2>
</forecast>

The next step was to create the HTML page with null data, with all data-bearing divs identified with appropriate id values. And then to write the javascript required to place the data query, and then populate the divs with the returned data values. All of this is relatively straight-forward with the use of statements like the following.

document.getElementByID('temp_max').innerHTML=JSONObj.forecast.day[iday].max;

This all worked as expected. However, a few unforeseen problems arose, in particular relating to the –webkit-marquee CSS behaviour (also referred to in an earlier blog post). The problem is that the marquee behaviour only appears to work when the div using marquee in its CSS style is first rendered ie. when the page is first loaded or refreshed. But with the new AJAX version, no page reload occurs, even when the user selects a new city to display. Also, even altering the contents of the div doesn’t re-trigger the marquee motion. Eventually, though I found a workaround. The trick is to clone the div, and then replace the original div in the DOM model with the newly created clone. Sample code follows.

function refreshMarquee(element)
{
var pclone = element.cloneNode(true);
var parent = element.parentNode;
parent.replaceChild(pclone, element);
return false;
}
refreshMarquee(document.getElementById('weather_description'));

Note that the cloneNode call requires its “deepBoolean” parameter to be set to “true” in order to copy the text value from the source node.

Another issue is how to force a data refresh every 10 minutes without a manual page reload. This is fairly straight-forward with the use of setTimeout function calls used recursively, which I was already using at 10 second intervals to update the time since observations were made. However, as this is an iPhone application, it is likely that users will view the page, then close the browser, and perhaps come backs hours or days later and reopen the browser still viewing the same page. Of course the javascript would have stopped running, and the timer code would simply restart without realising that there had been a suspension, and the data would thus remain out-of-date until the remainder of the timer period eventually expired – which could be up to 10 minutes. The solution here is to set up a start-time variable, and frequently check how much time has elapsed since then. In this case, after the page is resumed from dormancy, then next check will immediately reveal that the data needs an update… problem solved!

All desired changes having been made, the html, javascript and css files were converted to include php wrappers to allow gzip compression, and then a benchmark comparison was made with the previous PHP intensive version. Hmmm – it seems almost nothing gained on load, despite all the compression, due to the need for the AJAX data query to run (owquery2.php) after the initial HTML load – but obviously substantial gains for subsequent updates without reload.

One nagging problem remains. Despite trying at least half a dozen coding variants based around “window.scrollTo(0,1)” the url bar refuses to retract after the initial page load. There is no problem at all in getting it to retract after an AJAX data refresh, and I suspect it has something to do with the AdMob javascript that is rendering the ad banner at the top of the page – but at this stage still not sure exactly what.

Hopefully I will be able to post my solution in a future blog entry.

Virtualizing My World on an iMac

Having recently acquired an iMac, I find myself torn between the familiar Vista machine I use as my development machine vs the slick, shiny, performance-enhanced 24″ iMac. And I am wondering if this is what schizophrenia actually feels like.

Its hard to let go of so many years of sometimes painful Windows-based experiences, and the feeling (no doubt totally illusory) that I have somehow “mastered” PCs, and am therefore  optimally productive when I use one. And on top of that is the fact that so many of my essential and favorite software development and productivity tools are available only on Windows. But I do need the Mac to build iPhone applications. Can you see my dilemma?

So the glaringly obvious solution here is to move fully onto the Mac, and run a virtual copy of Windows as and when needed for the Windows-only stuff. But will it fly? What are the pitfalls? Is it a pipe-dream? Well I guess its time to find out!

First I installed VMWare Fusion onto the Mac. Quick and painless. My next step was to install VMWare Converter onto the PC, and use it to attempt to virtualize the entire PC, including 80GB used disk space. This bit already seem rather ambitious to me. Firstly I wasn’t sure whether an 80GB virtual machine could run with reasonable performance at all. Secondly I was using a wireless 802.11g network which could be something of a bottleneck in moving the virtual disk image onto the Mac. The latter issue was easily overcome by using an Ethernet cable to link the PC and Mac directly (no hub) – although I could only get this to work after I switched off the wireless link on the Mac. But it did increase the throughput by a factor of 10 – so well worth the experiment.

I set up VMWare Converter to run on the PC, convert the physical machine into a Mac compatible VMWare virtual machine file and write it via the network connection directly into the Documents folder on the Mac. Well, off it went, and (after a couple of hiccups caused by me foolishly switching the wireless connection back on during the process, and having to switch it off again and restart) the full conversion and data transfer took about 2hrs for the full 80GB file to be placed onto the Mac.

The next step was to start up VMWare on the Mac, and see if it would run. I should point out here that I only had 2GB RAM installed on the Mac (to get a quicker delivery), with the intention of upgrading to 4GB later if and when I needed it. Now was obviously that time, but being the impatient and perhaps over-adventurous person that I am, I gave it a go after setting the VMWare allowance to 512MB for the Windows virtual machine.

I was gratified to see that it did (quite slowly) start up. However, there were some glitches. For example I was informed that there was no known driver for device “IDE01” – perhaps the fingerprint reader? But basically it worked. The only problem was memory usage. Despite having installed 4GB physical RAM, and allocating 2GB to the virtual machine, Activity Monitor showed that things were getting very tight with only minimal applications open.

So my next move was to install a new OEM version of Windows XP Professional as a virtual machine. This started up and ran just fine even with 500MB memory allocation. Ramping that up to 2GB should allow me to run all the apps I need at once.

So now all I have to do is install all the development tools and utilities I need and am used to. However I will only install what I really need on Windows, and start to use more and more on the Mac. That will all take a while though – so I will report back later on to see whether the dream is becoming a reality or not.

Scrolling text with -webkit-marquee

As iPhone web apps have limited screen width to play with, and you also generally need to avoid small font sizes, there may be times when you need to use scrolling text. This is the case with Oz Weather – where the weather forecast description is usually quite brief eg. “Fine”, “Scattered showers”, but can sometimes be much longer eg. “Showers, windy, mountain snow”, which overflows the available space.

One solution here is to add an onclick event to this text field, and show the full text using an “alert” call. However, unless the text had an (ugly) underline or similar, most users would probably not realise it could be clicked on, and in any case, it is always best to avoid forcing the user to take extra action simply to see what should be readily visible already.

You could also deal with this using javascript code to scroll the text one letter at a time. However, in practice this results in very jerky motion – not at all compatible with the iPhone’s other slick animation capabilities.

Fortunately the built-in Safari browser allows some CSS3 type markup, including marquee capability – which does have nice, smooth animation. Apple’s reference for Safari’s CSS can be found here. Look in the section “Visual Effects”.

The relevant CSS properties are:-

  • overflow-x
  • -webkit-marquee-direction
  • -webkit-marquee-style
  • -webkit-marquee-speed
  • -webkit-marquee-increment
  • -webkit-marquee-repetition

The following example can be placed into a class style which applies only to fields in which the text actually overflows.

.marquee
{
white-space: nowrap; overflow: hidden;
overflow-x:-webkit-marquee;
-webkit-marquee-direction: backwards;
-webkit-marquee-style: alternate;
-webkit-marquee-speed: normal;
-webkit-marquee-increment: small;
-webkit-marquee-repetition: 4;
}

The effect here is to cause the text to scroll from left to right until the end of the text falls just inside the visible area, and then scrolls back the other way. It does the entire loop twice (4 repetitions in alternate directions).

Obviously, if you want to see this in action, you will need to try it in a browser that supports these properties eg. Safari 3.0 or later on iPhone, Mac or Windows. (If you are viewing the Oz Weather site to see this in action, you will need to find a city which happens to have lengthy forecast description text for at least one of its forecast days.) However for now IE or Firefox don’t support it, and you will simple see motionless, truncated text. In that case you can still click on the text field to see the full text.

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