Archive for August 2008
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.
<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 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>
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.
var pclone = element.cloneNode(true);
var parent = element.parentNode;
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.
Hopefully I will be able to post my solution in a future blog entry.
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.
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.
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:-
The following example can be placed into a class style which applies only to fields in which the text actually overflows.
white-space: nowrap; overflow: hidden;
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.
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).
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.