Adventures in S60 Web Runtime - Part 2

This is the second installment in a series on writing an S60 Web Runtime widget, here's the first.

As I said in my last post, feedback is very important if you want to stay motivated. As well as being important for setting goals, this is very important for the actual writing of the code. To possibly state the obvious, software development follows a series or steps:

1. Think about the problem.
2. Think up a possible solution.
3. Write code expressing that solution.
4. Build the code you've written.
5. Test your built code.
6. Repeat from step 1.

The astute programmers among you will have realised that this is a never ending loop as there is no termination condition such as "On the 100th try give up and go home". The non-programmers will have thought that was a rather obvious implicit step. You're both write, it's a never ending cycle of improvement but every so often you have to stop and do something else.

One of the key steps in this list is step 4 ("Build the code you've written"). This is the process of asking the computer to translate your program from the human programmer readable code to something the computer can run. It also includes packaging up the built code in a way which means you can actually run it. It's roughly equivalent to taking the plans for a building (step 3) and building the house before you can live in it (step 5). It's very important to keep this step as short as possible, as if it takes more than a few seconds the programmer will lose focus, start thinking about if they need to buy more bread and milk on the way home and forget the intricate details of their solution from step 2.

Compiler by Luiscdiaz

S60 Web Runtime widgets are essentially an interpreted language. This means that the computer can go straight from the code you've written to running it. This is different from a compiled language which requires translating your textual code (saying something such as "add 1 to count of people") to numbers that the computer can run (such as "07 A4 7E 1F"). By being interpreted, a large part of step 4 is removed. However there is still the need to bundle up all the files in your program into one file and to install the application onto something that you can test it with. This can take a surprisingly long amount of time while also being tedious and dull.

Luckily several people have worked to make this easier. A glance at the quick start guide from the Symbian Foundation showed that there were several useful tools for speeding up this process. The one that they focus on (due to it being free) is Aptana. Aptana is an Integrated Development Environment (IDE) which means that it tries to have as many easy to use tools all integrated together in one place as possible.

The big feature of Aptana which made me want to use it is that it makes it possible to go straight from writing code to testing it in one click (going from the "Source" view to the "Nokia Web Runtime (WRT)" view). This was going to make development much more streamlined and, most importantly, more fun.



So with Aptana installed and tested to check that it was working (by following the rest of the quick start guide) I now had to get down to writing the actual code. In actual fact that's a bit of a lie as I first of all had a look at some of the example code and noticed that it was written in an apparently non-optimal way.

Anyone who has used a WRT widget on a phone might have noticed that they're a bit slow to start-up. When programming for web pages it's common to put code which does complex things (and therefore takes a while) at the end of the page. This means that the user can at least see most of the page and start reading things while the computer is doing the complex things. This does require a bit of extra work, as you must divide the things you need to do into things you have to do now and things you can do later (further details on this can be found in the Episodes pattern in this book).

However the example code wasn't doing this, instead of:

1. Perform just enough calculations for the first view.
2. Display the first view.
3. Do the other calculations.

The example code was doing:

1. Calculate everything and get it all set-up and ready to go.
2. Display the first view.

By doing the non-essential work first, the example application was unnecessarily slowing down the start-up of the application. After all, why do something now that you can put off doing until later!