Develop a GPS-aware application for the Nokia N810, Part 3: Finish the job

Deployment, bug reporting and fixing, iterative development, and a final release

This series of articles shows how to build a global positioning system (GPS)-aware application using the Linux-based Nokia N810 Internet Tablet and its built-in GPS receiver. In this last of three installments, you'll put the final touches to the GPS trip tracker and get it ready for release.

Paul Ferrill (paul@ferrill.net), CTO, ATAC

Paul Ferrill has been writing in the computer trade press for more than 20 years. He got his start writing networking reviews for PC Magazine on products like LANtastic and early versions of Novell Netware. Paul holds both BSEE and MSEE degrees and has written software for more computer platforms and architectures than he can remember.



18 February 2009

Also available in Russian

Part 1 and Part 2 of this three-part series provided the tools and techniques for building a global positioning system (GPS)-aware application for the Nokia N810 Internet Tablet. The basic idea for the program came from a cross-country family trip and the ever-present question, "Are we there yet?" Providing an answer becomes a simple task when you have a programmable device with a built-in GPS. All you have to do is load up a few waypoints, and you're good to go.

When the first iteration of the application was complete, it was obvious that a few improvements needed to be made to make the program more usable. This really isn't that different from any other software product. The key is to make it easy to get user feedback, then make the program changes necessary to incorporate the new features. Fixing any bugs is another high-priority item if you want to keep your users happy.

A number of issues need to be settled before you start the process of releasing your new application. You can choose to host your project on any number of software-distribution sites, although the Maemo site would be the best choice for a project like this one, because its only target platform is the Nokia Internet Tablet family. If you want user feedback, you'll need to provide either a Web site or—at the very least—an e-mail address.

Deployment

The Maemo platform uses Debian packages for software distribution. Nokia has done a good job for tablet developers in defining how to package applications for distribution. A complete set of tutorials is available from the Maemo.org site to help guide you through the process along with a 545-page reference manual for the latest (Diablo) release. In essence, you have to create a .deb file and include everything necessary for your application to run properly.

Because this application uses Python, there are a few things you must do to make sure the program will run. Most modern Linux® distributions include Python as part of the default installation, so you can usually assume that the Python interpreter will be available. Running a Python-based application requires a line at the beginning of the primary source file to launch the Python interpreter—something like this:

#!/usr/bin/python2.5

For the N810 running the latest version of OS2008, you should have Python version 2.5.2 installed in the default location, /usr/bin. The #! in the first line instructs the command-line interpreter to attempt to execute the file python2.5, found in the /usr/bin directory. It then proceeds to take the remainder of the file as input to the Python interpreter.

The main script or source file must also have its file properties set to allow execution. You can do this manually with the CHMOD command or use an automated process with an installation tool. Python provides multiple methods for installing an application, including the ability to compile the source into a more compact form. For this project, I decided just to go with the standard Python setup tools and not compile the code.

The Python Distribution Utilities (Distutils) provide the basic tools to copy files to appropriate locations and essentially install the software. (See Resources for a link to a good Distutils tutorial.) All you have to do is create a file named setup.py that looks like Listing 1.

Listing 1. Python setup routine to install the program (setup.py)
from distutils.core import setup

setup(name='pyRWeThereYet',
       version='1.0.0',
       scripts=['pyRWeThereYet'],
       data_files = [
                    ('share/pixmaps',             ['RWeThr_icon_26x26.png']),
                    ('share/applications/hildon', ['pyRWeThr.desktop']),
                    ]
      )

The PyMaemo tutorial (see Resources for a link) has a good description of this process along with a sample "hello" application. Another method for installing applications on the N810 uses an .install file to accomplish a "single-click install." This file is a simple text file with information about the repository to which you can download the application.

Ultimately, you need to test your deployment on the device, but you can work out the bugs using either Scratchbox or ESbox (the plug-in for Eclipse—see Resources for links). You can step through the whole process without using a device until everything works as you want it to. The same goes for the entire development process, although you'll again need the device for hardware dependencies like the GPS.

Bug reporting and fixing

Most open source projects use some sort of bug reporting and tracking tool to help manage comments from users. Sourceforge has been around for quite a while and is a good place to consider for hosting your open source project. Google has a similar offering (see Resources for links). Maemo.org provides essentially the same capability with their Garage site (see Resources) for projects related to the Maemo development platform.

A wiki is another great way to make it easy to facilitate user feedback and to provide program documentation and information. Trac is a Web-based software project-management tool that includes a wiki for managing project documentation and notes (see Resources for a link). For developers, it's important to keep track of bugs and enhancement requests and the changes made for each. You can do this in a Wiki with team Read-Write access.

Source code control is a key to keeping track of software revisions. Although it might be a bit of overkill for a project this size, it is a lifesaver for any project with more than a few modules. If you've done a good job of modularizing your source code, you need a way to keep track of which modules (and versions) go with each release of your application.

One of the oldest version-control packages around is the Concurrent Versioning System (CVS). CVS is open source and available for just about any platform. Subversion (SVN) is another open source tool that's available for all platforms. GIT is one of the newest tools available for version control and was initially created by Linus Torvalds. It has a number of features that make it especially useful to distributed teams needing things like rapid branching and merging. (See Resources for links to these tools.)

The Eclipse integrated development environment (IDE) provides hooks to both CVS and Subversion. There's a good article on IBM®developerWorks® that discusses how Eclipse works with CVS, if you want to read up on the process. For Subversion support, there's Subclipse—an Eclipse plug-in that comes complete with a graphical revision tool (see Resources for a link). Work on a GIT plug-in for Eclipse is ongoing, and you can read about it on the GitWiki site.


Iterative development

Developing an application in an iterative fashion is all about making incremental improvements based on user feedback. Step 1 is to get an initial release out for users to test. In my case, the users were family members, and the feedback mechanism was all verbal. Version 1 of the application worked, but it didn't provide a way for users to enter a waypoint. You could get the distance from a previous spot, but that was about it. It was really meant as a proof of concept anyway, so the expectations for release 0.1 were pretty low.

This brings up a good point that arises in many software-development projects. When you have a version of a program, it's not uncommon to get feedback like "The program is really neat, but could you make it do this?" Requirements elicitation is a process whereby a software designer or engineer attempts to identify all the capabilities and features of a specific application. The problem with this type of approach is that the users frequently don't really know what they want and either change their minds or think of something else along the way.

For this project, the new requirements were not difficult to implement. Version 0.2 added the ability to input locations of interest by latitude and longitude. Having the ability to add points of interest is great, but what if you make a mistake or need to edit or delete an existing entry? These new requirements resulted in version 0.3. It's not a bad idea to do some sanity checking on input fields. Latitude and longitude numbers have a reasonable upper and lower bound for North America. Adding these checks came out of a user bug report identifying a potential bad distance calculation. When the actual cause was identified, it turned out to be an improper user input (no minus sign [-] in front of the longitude).

Understanding the cost of implementing new requirements is key to producing a new version in a reasonable amount of time. Some feature requests will be way beyond the scope of the original application and often exceed the available time and resources. Others could be beyond the capabilities of the hardware. For this project, it would not be possible to give continuous real-time position updates unless you tethered the device to a cell phone with a data connection—not completely out of the question, but it would certainly increase the amount of code to be written in support of that single feature request.


Final release

One of the biggest challenges for any software project is to know when to declare victory. Google has used the model of keeping projects in the "beta" phase for extended periods of time. For this project, the final release was achieved when all the current bugs were fixed and all user improvements were implemented.

A few finishing touches are needed to make an application as close to commercial quality as possible. Creating an entry in the N810 application launcher makes it easier for a user to start the program. Maemo uses the .desktop file to identify the details needed to launch the application. For the GPS application, it would look like Listing 2.

Listing 2. Desktop file contents
[Desktop Entry]
Version=1.0.0
Encoding=UTF-8
Name=GPS Are We There Yet?
Exec=/usr/bin/pyRWeThereYet
Icon=hello_icon_26x26
Type=Application

You can find more information about the .desktop file on the freedesktop.org wiki site. Another good finishing touch is an icon. For the Maemo environment, you'll want to create a 26 X 26 pixel image and save it in the Portable Network Graphics (PNG) format. You could use a program like the GNU Image Manipulation Program (GIMP) to build your own, or use Google to find something close to what you want and modify it accordingly.


Closing thoughts

This series of three articles has attempted to take a look at the process of developing an application for the Nokia N810 in a way that highlights the steps involved more than the end result. Developing applications for small form factor devices has its own set of challenges but really isn't that different from any other platform. Doing a good job on any software-development project is all about making good decisions along the way.

Building a software application is as much art as it is science. There are multiple ways to implement just about any idea you can come up with in software. Creating visually appealing user interfaces (UIs) is better accomplished by someone with an eye for design as opposed to the typical software developer. By the same token, you probably want someone with a math background implementing the algorithm to compute your payroll deductions instead of an English major.

In reality, developing software is very much a process with clearly defined steps. You might not use the same methodology as another developer, but you both accomplish essentially the same tasks. Keeping the user either involved in the development or—at the very least—using the earliest prototypes and alpha releases to get their feedback will hopefully keep the project on the right track.

Developing for the Nokia N810 is a real joy. The developer tools and community forums provide a wealth of resources to get the job done. It's still one of the smallest Linux-based computers available on the market today. While it might not be the most powerful device in its class, it certainly has all the capabilities needed to implement the GPS distance calculator for this project.

I'd like to acknowledge and recognize the contributions of my 19-year-old son Micah for helping with the Python code for this series of articles. He also got the Eclipse integration working with the N810 and did all the testing of the various versions.

Resources

Learn

Get products and technologies

  • Subclipse provides support for the Subversion.
  • For more information about CVS, visit the CVS project site. Other good options for version control include Subversion and GIT.
  • Scratchbox and ESbox are designed for the Maemo platform and work well with Eclipse.
  • With IBM trial software, available for download directly from developerWorks, build your next development project on Linux.

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Linux on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Linux
ArticleID=370510
ArticleTitle=Develop a GPS-aware application for the Nokia N810, Part 3: Finish the job
publish-date=02182009