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!

Adventures in S60 Web Runtime - Part 1

The further parts in this series of posts can be found here: part 2

To celebrate/commiserate (delete as appropriate) moving on from four and a half years of employment at Symbian and then Nokia I've decided to try my hand at writing a mobile application.

The first step in writing an application is deciding what to write. This is harder than it sounds as there are already quite a range of applications out there, both for the Symbian platform and for other mobile platforms. While there is nothing wrong with creating an application which has already been done, especially if you have a new and unique take on it, but you do have to ask yourself if the world really needs another glass of beer simulator.

After some thought I realised that I wanted to try to create a simple persistence of vision (PoV) application. The basic idea with PoV is that in trying to make sense of the world, your brain merges together what your eyes see over a short period of time. This has been exploited to write messages in empty space.

This is typically done with a row of LEDs (as in the above example) and a small micro-controller like an Arduino such as in the example above or like this.

While I have dabbled in hardware before, I'm primarily a software person and as I was looking for a small mobile application to try writing, I thought a PoV application would be an ideal starting point. It's a fairly simple application which using a mobile phone has some extra possibilities, such as higher resolution (so better quality images) and more colours. I don't, however, foresee any practical use for it aside from perhaps using it to send multi-colour messages across a dark and noisy room.

Doing a PoV application also had the advantage that I could start small and add new features easily. This is very important for all software projects, whether developed as part of your job or just for fun. If it takes you a year of writing to create something which you would be proud to show people then you are quickly going to lose motivation and stop caring. Put simply, I wanted regular and meaningful milestones (or key points) where I could point at something that I could be pleased to have created. I think that this is an important aspect for any project, be it software or building a shed in your garden, human beings seem to work best when they have regular goals which they get clear feedback when they've achieved.

In my mind two lists formed as a consequence of this. The first list was a list of things that I'd need to do to get the first version done. This list needs to be short so that I can easily achieve it. The second list was a list of possible future ideas. This list needs to be long enough for me to have some interesting features to add to the application.
First version features:

• Take some text as input.
• Display it in a set time period.

Future ideas:

• Accelerometer support - so it knows when to start displaying the message.
• Colour selection - more than the plain LED red of hardware PoV.
• Multi-coloured messages - because rainbow text would be awesome.
• Image painting - is it possible to paint more than a single line of text in the air?

Happily the PoV application idea satisfied both criteria, having only two things to do in the first version and a number of varied things to do in the future.

So that's is the first hurdle passed in software development; but knowing what I was going to write was worthless if it didn't have a name. Names are very important, especially for software projects. Some schools of thought subscribe to the theory that the name is the most important thing about a project. I wouldn't go that far, but a good name is the first step in creating a good application. It's also a case with naming that thinking about it for too long, or being too clever about it, leads to a worse name. Not wanting to pick on Google in particular, but the first example of this that came to my mind was when Google decided to rename 'Froogle' to 'Google Product Search'. They renamed it as the pun on the word frugal in the name wasn't obvious.

Immediately I decided that using the term PoV was a big no-no. I always read PoV as Point of View unless something about the context indicates that it's probably Persistence of Vision. If I, as someone who knows and understand the term, doesn't find it immediately conjuring up visions of text in the air then what hope has anyone else got? So my thought turned to other names and one which lead on almost directly from the anti-PoV viewpoint was to call it 'SkyWriter'.

The name SkyWriter does almost exactly what it says on the tin and so seemed like a good name. Before getting too excited though, I wanted to check that there weren't any connotations for the name that I wasn't aware of. The easiest way to do this was to just do a web search for it, using my favourite search engine. Sadly it turns out that there is already a mobile application called SkyWriter for plane pilots and I wouldn't want to confuse pilots and be responsible for them crashing!

So I tried AirWriter and discovered, to my horror, that someone had already created a PoV application called AirWriter. Slightly disheartened I tried a few other combinations and finally decided to settle on AirText.

With all that decided I had to decide what devices and what programming language I would write AirText in. The device question was easy to answer, 'my current mobile'. I currently own a Nokia 5800 Xpressmusic. The choice of what language took only slightly longer; I'd been wanting to try writing an S60 Web Runtime (WRT) for a while now and this seemed like the perfect chance.

Another reason, and probably the most significant if I'm honest with myself, is that I've spent over four years dealing with C++ code and using the simpler language of HTML and JavaScript of WRT was very appealing. HTML and JavaScript are the languages used for web-pages and let you concentrate on describing what goes where on the screen. This makes it easier to use than C++, which requires dealing with all the complexities involved in controlling all the parts of the computer to do what you want.

With that decision made, my final step in this instalment was therefore to go over the Forum Nokia and to read up on their quick start guide for widgets.

In other news I've finally worked out that I'll keep this blog as a blog of interesting things that I've done. I realised that I do spend quite a bit of time working out how to do things with technology or reading up on some information and that it'd be good to share. I can't promise regular posting, but I will try to keep the posts here as journal entries that are hopefully an interesting read.