There's a big bunch of changes, fixes & new features since the last release ca. 7 months ago, so a maintenance release would make sense. Here's a status update:
Map version will change, but GpsMid has backwards compatibility so that it can read old map versions too. (At some time support for oldest map versions will probably be dropped though, no definite plans whether it will happen with 0.7.8 or later; support for 6 months .. 1 year old maps however is planned to be retained).
A current snapshot is available at http://gpsmid.sourceforge.net/nightlies/
Although the snapshot (nightly) version often works well, for daily use the release version (currently 0.7.7) is recommended. It can be found in the Files section at sourceforge.
There's also an Android version which is not yet officially part of the release. You can download that from the snapshots directory.
Current WHATSNEW describing changes in the current snapshot since last release, 0.7.7:
*** Android Support ***
- many stability / usability improvements
- huge icon menu images are used by default which makes the icons look much better
- new option for backlight setting: Android WindowManager (KEEP_SCREEN_ON)
- new Android native location provider which can be used instead of JSR179
- reduced the number of build targets to simplify builds & distribution; different
targets (2.1, 2.2, 2.3 etc.) can be uncommented in build.xml if needed
- some minor adjustments due to upgrading to J2MEPolish 2.3, related to file dialogue
- various UI improvements and fixes with back key handling
*** Touchscreen / User Interface ***
- On the map screen long tap * to toggle track recording
- During track recording long tap recorded trackpoints on the map screen to suspend/resume track recording
- On the map screen long tap _ to manage track list, double tap _ to manage waypoints
- In routing choice, added buttons for selection of route mode - no need to go through menu
- More icon sizes are included, you can now choose from "useIcons = small|true|big|large|huge" in the .properties file.
useIcons=large and useIcons=huge make sense for devices with high resolution displays
- Links to online help for touchscreen and GpsMid wiki in Online menu
*** Map display ***
- The map screen now updated more often during panning when dragging the touch screen.
(not only after the ImageCollector class has finished drawing the map but every 1/3 s)
This improves zooming out very large maps. (thx walter9)
- Zooming far out and then zooming far in again works now faster because as soon as all tiles
for the map display are loaded remaining tile loading requests will be dropped (thx walter9)
- The number of not loaded tiles are displayed in the left upper corner,
and a * sign after the number if the map is actually being rendered (thx walter9)
- experimental support for dashed areas
add e.g. <lineStyle dashed = "true" /> for landuse/industrial in style-file)
- The width of the line to the destination is now configurable in Display Options,
default value is 2. (thx pos_ei_don for drawWideLine())
- If backlight method is known for the phone model backlight is turned on by default in new midlets.
- Additional backlight level 10% for Nokia and Android mobiles, so now there is 1%, 10%, 25%, 50%, 75%, 100%
- Time to change backlight level with keys 1 and 3 or zoom buttons on touch screens
after toggling backlight has been increased to 5 seconds.
- Some workarounds (mainly useful for sea rendering) for map data overflows which can
appear due to shortcomings of Osm2GpsMid
- option to use the GPS clock as clock source for on-map display
(currently only NMEA-transmitting GPS devices give clock information)
- option to set a time difference in minutes between device time and display time
(to work around platforms which for some reason give incorrect time
e.g. due to deficiencies in JVM time zone code)
- Bug fix: The ImageCollector thread no more is started twice
when a saved destination is restored at GpsMid startup (thx walter9)
- Map switch can now be done without restarting GpsMid
*** Sea generation ***
- greatly faster sea generation algorithm with option useSeaTiles = true
in .properties file. It divides the map into roughly 20km * 20km areas
which are processed one at a time, total time taken is a small fraction
of the time taken without useSeaTiles and map data is smaller.
There are however more map artifacts when using the option and shortcomings
which lead to incorrect choices of land / sea are triggered more often
when seatiles are used.
*** Search ***
- allow configuration of POI search distance; default is 10 km. A high limit
does not work in all areas, depending on number of map objects (tile size?).
- bug fix to prevent POI search crashes which appeared more often on slow
devices and less often on faster devices
- heed max search count for POI search, bugfix for name search fencepost error
*** Routing ***
- add support for toll rules for each travel mode to routemodes.inc.
Ways will still be rendered with toll decoration only if toll=yes or toll=true is set
regardless of toll rules or current travel mode
- when turn restriction checking is on, take account also the driving direction
in route calculation - in other words, when driving with car, don't assume we
can start driving backwards without a u-turn or can just take a u-turn with no costs
please consider setting up code-freezing period as well as updating master translation file to give translators opportunity to translate all new strings prior to final release.
I updated the English messages in the wiki earlier today, so now you the translations can be updated now.
There will be a testing period of at least three days after the announcement for release. (This thread is not yet the announcement for release, just reminding that one should be put out)
You can see new messages added after last release up to today by visiting the link below.
Now a very long time since the last release - would really make sense to do a release at last.
After the Android "NoFix" issue fixed and the Display setting menu save issue fixed, I don't see any major issues in the bug tracker.
But, I remember sk750 talking somewhere something about a search problem perhaps related to a "sort by proximity" search setting. I didn't quite get the details - sk750, how severe is this? In any case would be good if you can make a bug report about this if the bug still exists.
Anyone have an unreported severe bug which would be good to fix before release?
Regarding the release I think there should be some chance for people to update the various translations.
I did not commit the change to sort results by proximity by default but I think sometimes search results get lost, regardless of which sort mode is chosen and if the results are over the search limit or not.
One other thing I'd like to have in the release is being able to zoom out and even drop requested tiles during route line creation. This was in the original patch from walter9 but I disabled it as I did not know the mechanism enough to be sure if it could cause issues when dropping tile requests during route line creation.
"Regarding the release I think there should be some chance for people to update the various translations."
Please everyone update the translations - there are many new strings the last release, and a few new strings from the last few weeks.
Diffs in strings from last release to today can be seen by:
"One other thing I'd like to have in the release is being able to zoom out and even drop requested tiles during route line creation. This was in the original patch from walter9 but I disabled it as I did not know the mechanism enough to be sure if it could cause issues when dropping tile requests during route line creation."
Well, as you suspect it could cause issues, perhaps it'd be better to leave that to the next release? (which can hopefully come out sooner than this one)
Changed this already as I think those tiles needed for the route line production are not put into the request queue.
One thing I noticed is we should probably prevent changing travel mode during route calc with message "currently in route calc". Otherwise mixed routes might be calculated.
Is the release planned for Android as well? Just had a chance to test the latest nightly on Samsung galaxy s2 again and while this time it worked quite stable besides from some disconnects I could not explain, it seems to me it's quite too easy to terminate GpsMid by accidentally touching the back key in the map screen. Is there anything that could be done about this?
No, plan is Android will still have snapshot (unofficial) status.
What do you mean with disconnects - loss of GPS position, exit/crash of GpsMid, something else?
I guess the simplest and most reasonable thing to avoid accidental exits is to add the "are your sure" -query for which there's a feature request. I've seen other Android apps use this too. IMHO should be optional though.
There where unexplainable connects/disconnects when entering or leaving the icon menu.
While a query about exiting GpsMid might make sense for some people I'd prefer if the back button just would do nothing in the map screen - it happens too easily that after returning from icon menu or pressing the way bar you accidentally hit the soft back key.
Hmm, by connect/disconnect I suppose you mean GpsMid signals that it doesn't have / has access to the GPS receiver. (connect / disconnect audio message). Strange, I have never seen that.
Might be something device-specific related to power saving. On the Galaxy Note, when I have the Gps power save mode switched on, the device switches GPS off when the device is on the table (motion sensor doesn't sense movement). In adb logcat message there's also info about the device deducing that the device is "pedestrian".
As for back button - well, perhaps then a three-choices option for Android back key: ignore, exit or confirm. Or one bit flag for ignore back key on Android, and another bit for "request confirmation on exit" which would apply to all exit functions.
S2 has this power saving too, but don't know if this was related to the disconnects.
I think the ignore option makes most sense, not only for Android if the back key exits on j2me devices the application as well. And I think it should be easier to implement than the query.
With Android support still being unofficial, I think we should move down the Android section in WHATSNEW. On the other hand - what are the reasons to still keep Android support unofficial? I think we need a small tutorial for Android users to install the apk rather than the jad/jar and select the jar as an external map but that should do as an initial documentation.
"On the other hand - what are the reasons to still keep Android support unofficial?"
A couple of reasons for me
* Because there have been reports it's quite unstable (I haven't experienced this, and I suppose most of the issues with the reports by e.g. you have been fixed already)
* The UI is unfriendly / quite non-Android -like. Many of issues on this front have also had improvements.
Hey, now I remember that a while ago I jotted down some criteria for when to consider the Android version releasable. From https://sourceforge.net/apps/mediawiki/gpsmid/index.php?title=DeveloperInfo :
"When to move the Android version to release status
Most of the following:
Android-style friendly GUI for many important functions: waypoint entering, file selection dialogue, wp & track handling, …
wakelock on by default when recording tracks
make way editing work
thorough testing of functions and documentation what works and what doesn't on "generic" android
more documentation on what functions work on which Android versions and devices
more documentation on what builds to use on various Android versions and devices "
I guess someone (preferably an "android-native" who's used to the Android way of doing things and could evaluate the UI from Android perspective) could go through that list to see what the situation is at the moment.
"I think we need a small tutorial for Android users to install the apk rather than the jad/jar and select the jar as an external map but that should do as an initial documentation."
Yes, that's a good addition to what should be done.
Feature-wise, I think it'd be good to have this for the first Android release. I think multitouch functionality is what people expect, and if it isn't there, it'll be a bad first experience. Shouldn't be a big thing e.g. for you sk750 if you find the time and get your hands on an Android phone or have a fast enough machine than running the emulator won't be a big pain. (Oh, wait, not sure if multitouch can be handled with the emulator).
* multitouch zoom, pinch and rotate for platforms which support it (e.g. multitouch android)
Another thing good to do for Android release is map bundling - I don't think map bundling by Osm2GpsMid for Android is practical, but for first-user experiences, it'll make a smoother ride if we have a small bundled map within the Android release version. (There will be many people who won't read the documentation anyway, and it's much better if GpsMid can do something even without an external map). I haven't used the Android bundling scripts for a long time, and I haven't tested them with the "release" signing key used currently, but I don't see why the scripts wouldn't work with some small tweaks.
Well, time for getting all this setup and running, besides no own Android mobile yet, is the main issue preventing me from doing this.
On the other hand I think GpsMid is now the best offline routing software on j2me and it would be a pity if it would not complete the step to Android soon.
Regarding the map bundling I think the scripts are only for Linux but not for Android?
last Android -> Windows
I haven't tested the scripts for Windows. They will not work out of the box on Windows. They will probably work with relatively minor changes with the proper software environment (cygwin or equivalent; the scripts use a bourne-compatible shell, grep, echo, head, jar, maybe a couple of other ordinary, typical unix-like OS commands) installed on Windows.
To be clear, I'm not talking about making the scripts usable for ordinary users (if we want to go that way, it's better to incorporate the functionality into Osm2GpsMid, that's doable, but I don't see that as very useful, and that's a bit problematic as we'd need to use internal Android SDK functionality AFAIK), I'm talking about using them by whichever of us does a release build for Android.
Ok, now it's clear to me that you only want the release bundling by script for developers. But then, on the other hand why not simply copy the map data into the source directories just like any other resource file (png, etc.) and let the compiling / building process do the bundling?
If someone can get it to work that way, no problem. It's just that I couldn't find a way to do that at the time of doing the Android port.
I don't remember the details exactly or with certainty, but it was something to do with the way of how Android assets are handled. IIRC the problem was I couldn't find how to include Android assets so J2MEPolish would include them in the apk in the right place, so that the Android .getAssets() functionality would find them. Could be an oversight on my part, could be it was a J2MEPolish shortcoming on Android at the time. Many of J2MEPolish shortcomings on Android and Android issues have been improved since, so it could be now this can be done. (IIRC I had to use a nightly J2MEPolish to get the Android port to work at all).