[Notice that this page is of somewhat technical character, you may also obtain this Java MIDlet directly from GetJar.]

This stopwatch MIDlet for mobiles is a result of a little bit of curiosity in J2ME technology and the fact that my Nokia E70 lacked a stopwatch. It is not exactly rocket science, but served as a practical example when studying J2ME. If you think that sounds disturbing, I am a professional SW developer; so at lucky moments I know what I am doing...

I know, there are probably lots of available JAVA stopwatch MIDlets around (see for instance www.getjar.com). But I believe this version has some new features that may justify "polluting" the web... In general, embedded system stopwatches (available on many devices I believe), should probably be better to use. See Caveats below for some comments on why I think so. That being said, this MIDlet might still be useful.

Features.

• Up to 9 individual stopwatches each with up to 50 cumulative split and lap times.

• Supports split and lap mode timing (toggled with * key). Split timing shows time since started, lap mode timing shows time since last lap (and split) taken.

• Select to show split, lap, both lap and split, delta lap, start time or time only (toggled with # key). Notice that both lap and split can only be shown at the same time if screen width supports it. Start time can only be shown if device supports CLDC 1.1 or later. The delta lap mode shows graphically deviation from average lap time (if more than one lap taken).

• Shows average, best or worst lap when displaying laps (toggled with 0 key).

• Stopwatch up to max 999 hours 59 minutes 59.99 seconds with 1/100 of a second accuracy. You may argue; what is the point with an accuracy of 1/100 of a second when measuring 100s of hours? And my answer is laziness, I didn't bother to strip away those decimals for you with the impact it may have on layout/alignment. Accuracy admittedly also depends on the system timer of the device, which has not been tested on any device. And it depends on system latency when pressing a button. Design considerations have been given to ensure minimum delay from pressing button until stopwatch is started/stopped etc., but you never know what is going on in there. Don't worry too much, it seems to do the job.

• Persistent saving of data and mode for all stopwatch instances (but avoiding saving for a stopwatch instance in reset state, which probably is the most common thing).

• Simple key interface with what I believe is convenient use of the keys for fast and accurate use. Based on assumption that most common use is start/stop/reset. Can be used with joystick/soft buttons and/or numeric keypad. (See comment in Usage below for special Nokia E70 mapping.)

• Stopwatch will "keep" running even if closing the Java application when running. Saves battery if required to run the stopwatch for a long time.

• Designed with low CPU/power usage in mind. That is, update to display (which is the main CPU intensive activity) is only done as required by state of shown stopwatch instance.

Known caveats.

• The stopwatch uses the system timer (which tells the time in milliseconds from Jauary 1 1970). There is however no way for a Java MIDlet to get information about system time being changed while a stopwatch instance is running. Some changes in system time can be detected, resulting in a SYSTIM CHNGD message, but many types of system time changes cannot be detected, causing measured time to become wrong. Normally this is only a problem if running long time measurements when summer/winter time change occur, or if changing time due to traveling to different time zone. It may also be caused by the cellular network auto updating device time, if that is enabled. I don't believe there is a good workaround for this in a Java MIDlet application. On the other hand, it is probably a rare problem for normal use.

• When devices go into screen save mode, a Java MIDlet application is normally hidden and any key presses are flushed by system while hidden. The first key press is used to take it out of screen saving (and thus hidden mode), but the key press is lost. This is annoying, and behavior varies a bit from device to device. Haven't figured out a generic workaround for this, I don't think there is one for a Java MIDP midlet.

• On at least Nokia, when auto keyboard locking takes effect, the stopwatch display stops being updated. This is partly due to the power saving feature implemented in the stopwatch SW, since the SW will stop all updates and suspend when told by the system that it has been sent into background mode. For at least Symbian 60 series, this background mode seems to be invoked when keyboard lock is activated. Although not desirable due to power saving requirements, trying to disabe the suspend feature does not help, since it seems that the system disables updating of the MIDLet canvas completely. If this becomes a problem, auto keyboard locking must be disabled, or set sufficiently long for your normal use. Or live with that the keyboard must be unlocked in order to let screen be updated. No generic way to handle this for all sorts of devices. (It may not be a problem on all device types.)

• The MIDLet icon might not be shown as intended on all platforms. The JAR file contains a MIDLet icon that can be used by the system for displaying the MIDLet in menus and on status line when running the MIDLet. Some systems are unable to scale or don't scale very well, leading to truncating the MIDLet icon etc. This is a well known problem and hard to solve with one common deliverable JAR file. One solution could be to remove the icon file usage, and the system would give a default one. I left it in there since it works for me, and many more, and does no harm. For the more technical enlightened, it is possible to replace the icons/stopwatch.png file in the JAR file if it annoys you. (Please don't ask me to do it, you need some basic JAR usage knowledge.)

Supported devices.

Both MIDP1.0 and MIDP2.0 type devices are supported (by different JAR files). This should cover most Java enabled devices. Minimum screen width is 128 pixels. This is not a commercial application, and it hasn't been tested on all sorts of devices. In fact, it was developed and tested for the Nokia E70 (MIDP2.0 352x416 pixels) and also tested on a SE K300i (MIDP2.0 128x128 pixels) and Nokia 6800 (MIDP1.0 128x128). Your device should probably have a color screen.

This application may not work very well on touch devices, since it requires use of a full numeric keypad, including * and # keys. Some touch devices may have a virtual gamepad and soft keys launched when this application is started, but * and # keys may still be missing. Please refer to the instruction manual of your device for further details.

Usage.

See Info soft button available on device when viewing stopwatch instance in reset state. Notice that there is no embedded documentation for the key mapping on for instance the Nokia E70 with keyboard flipped open. In that case, the following sets can be used as an alternative to the joystick: [D, F, G, R, V] or [H, J, K, U, M]. "1" is still used as with numeric keypad only. (This special mapping is nothing I invented, it is a system issue and quite convenient.)

Concerned about using free Java applications (MIDlets)?  

Well, you shouldn't really be too concerned. Of course, a badly written Java application (MIDlet) may contain bugs etc. that can jam up resources while running. But it shouldn't really be dangerous since it can not access file systems etc. In other words, you may try it. If it annoys you or behaves badly, you can just remove it. There is of course no intended "malware" included in this MIDlet, but just thought I'd mention it if you have read all sorts of virus things and are concerned.

Tevero AS is not responsible in any way whatsoever for this content other than making it possible for employees to publish concepts for common benefit. Tevero AS acknowledges that this SW is provided for free, and that the SW as such is owned by the designer. Any objections to the content of this page should be forwarded to the author at <kristian -dot- otnes -at- tevero -dot- no > or  mail@tevero.no.

Download.  

Go to download.