The Spatial Miscellany

I finally found some time to have a tinker with the Nokia Series 60 SDK, and build a hello world location application for my Nokia N95. Applications for the Series60 platform can be developed in several languages, as a developer you are spoilt for choice.

Having vague recollections of working with Java whilst undertaking my undergrad dissertation at Lancaster way back when, I plumbed for Java and promptly downloaded the Eclipse IDE. Next up, I installed Carbide.j, a suite of mobile development tools from Nokia. It was at this point I encountered my first frustration; it turns out the Carbide tools from Nokia don’t support the latest version of Eclipse, a school boy error of failing to read the doc. A quick uninstall, download, and install later, I’m back on track with an older version of Eclipse (3.1.2).

Nokia have provided a whole host of up-to-date documentation for building LBS applications for the series60 platform, so I downloaded their TouristRoute Java Midlet example and their location API developers guide. The location API is pretty concise, with a handful of important classes:


LocationProvider: represents the source of the location information (in this case the integrated GPS)

LocationListener: receives events associated with a particular LocationProvider.

Coordinates: represents coordinates as latitude-longitude altitude values.

Location: represents the standard set of location information (time-stamped coordinates, speed, accuracy, course, etc.)

Landmark: represents a known location with a name.

LandmarkStore: has some methods for persistent landmark store management (store, delete, and retrieve landmarks).


The sample built fine, generating a Java Archive (JAR) file and Java Application Descriptor (JAD) file. The JAR file is a package of the classes and resources, the JAD file a description of the Midlet. Right clicking on the JAR file (the midlet executable), the Eclipse context menu gives you two deployment options:


1) Deploy by Bluetooth
2) Deploy to Web Server


Unfortunately my laptop doesn’t have Bluetooth, so I went with option two and uploaded the files to my server (they can be downloaded here). I uploaded both files, the JAR and the JAD, I’m not sure if both are required or not? I added corresponding mime types to the .htaccess file on the server (this instructs the server how to handle requests for jar and jad files) and browsed to the jar file with my mobile phone browser. A couple of keypad clicks later, the application had been downloaded and installed on my phone.

Lots of useful documentation and active discussion forums made getting started building mobile app’s a breeze. However, it looks like my experiences may already be somewhat outdated, it appears Nokia have recently abandoned the Carbide.j developer kit in favour of newer tools provided by Eclipse.

I have had the phone for a couple of months now and am very impressed. Nice design, great camera, and a half decent GPS, but it’s the open development platform that sets this phone apart from the crowd, allowing everybody and anybody to develop a whole host of useful (and not so useful) applications. So far I’ve already acquired SportsTracker, which allows me to save my mountain bike routes as KML, some handy software that uploads my photos to my Flickr account, and the ubiquitous Google Maps which syncs nicely with the GPS.

I help to design software, it’s my day job. A smile crept across my face when a friend sent me a link to the following video:

Obviously, it’s a great plug for his book, but David Platt makes a good point in the video clip and something we continue to remain aware of here at ESRI. On this front I think ESRI make a fair effort, and a lot of time and energy is invested to ensure it’s the ‘end user’ experience that drives software development. For example, all our core software engineers are loosely coupled to product engineers (or product specialists), and it’s the product engineers that drive software development from an ‘end user’ perspective – at least that’s the theory; sometimes we get it right, sometimes there is room for improvement.

After watching the clip I surfed to Dave’s website whysoftwaresucks.com, where he has posted a sample chapter, I think he makes a valid remark when he states:

“The designers of the earliest computer programs didn’t care about making their products easy to use. Solving the computing problem at hand, for example, dealing with a printer to make the words come out properly on paper, was so difficult that no one had time or money left over for making a user’s life easier. A computer’s thinking time was enormously expensive, much more so than the user’s time. Forcing the human user to memorize complicated commands, instead of using computer power to provide a menu listing them, made economic sense. The relative costs are now reversed, of course, but almost everyone in the industry older than about 30 grew up in that type of environment. It can’t help but shape our thinking today, no matter how hard we try to leave it behind. Think of your older relatives who grew up in the Great Depression of the 1930’s, who even today can’t bear to throw away a sock with only one hole in it.”

Do GIS developers drive shift sticks?