Need Chronometer On Your Mobile? - Stopwatch v1.1

Latest Nokia Mobile phones like E60, it don’t have any chronometer software.. But a Norwegian J2ME program devellopper Kristian has made this program.. It’s very easy to use;

Features;

* Up to 5 individual stopwatches each with up to 40 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 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.

* 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.

* 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
Key Features;

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.

About;