GpsMid

It'd be good to improve the Android user experience so we could classify the Android version to be release quality. Currently the big issues are problems with everyday usability. It would be good to have feedback from everyday Android users on how to improve GpsMid user interface on Android. Seems like we don't have "android-natives" among developers, so some feedback would be quite useful. At the end of the message you'll find a list of what we have written down for points of improvement, but some practical feedback on how to improve things would be quite welcome. Hopefully for 0.7.9 or 0.8 we could classify Android as part of the release. When to move the Android version to release status Most of the following: multitouch support (zoom by pinch, rotate) 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 instructions for external map use small bundled map (doesn't mean bundling support for end users, just the release builder needs to be able to do bundling)

Just tried GpsMid-latest.apk on a HTC Desire Z (Android 2.3.3). I got GpsMid installing using Astro File Manager. When GpsMid is started there's however no splash screen shown. Tried Setup/Map Source and this setup form showed up. However I can't select a map source - when pressing the menu button there's just a black screen showing, so I can't give it a try. Also, when pressing the Home button in icon menu it tells that GpsMid (process de.ueller.gpsmid.ui) was terminated unexpectedly.

More info on the setup forms on HTC Desire Z: - None of the setup screens has any menu so they can be just left with the back button. - Setup / Sound: just a white screen is shown with the form title - Setup / Navigation immediately tells that GpsMid (process de.ueller.gpsmid.ui) was terminated unexpectedly - Setup / Map Source tells on pressing back that rereading the legend failed. This form can't be left therefore. - Other setup screens show up, including loading / saving configuration (directory browsing works but no screen showing) Is this related to compiling with JDK 7? When having tested some weeks ago on Samsung Galaxy S2 GpsMid worked much better.

Failure of the menu button is most probably a result of the change a few days ago to avoid the exit with the back key. I can repeat this on the Samsung Galaxy Note and on the emulator, so it's probably on every Android device. I'll see how to fix this.

No splash screen is caused by missing internal map, so GpsMid forces setup so user can set up the map. The plan is to have the minimal map bundled in the future, so GpsMid will start with the small map, show splash, and normal functionality will work so the user can get a feeling of GpsMid even without an external map. Setup / Sound & Setup / Routes works on the Note with current snasphot. Back from setting map source takes a while but succeeds. One strange problem which I saw on the Galaxy Note, which might be related to JDK7 (happened after that) - GpsMid started but only showed a black screen. Even a reboot of the phone didn't change anything, GpsMid just showed a black screen for minutes. Then after half an hour or so GpsMid started normally and has worked after that. If you can't select a proper map dir / file on setup, rereading of map legend will fail, so that's as expected. Don't know, but would think probably the setup / navigation (or routing as it's in English) setup entry also fails because of missing map.

Now that's bad luck if the issue with the menu button was caused by the change a few days ago. Good luck at fixing. In either case I think we should handle it more gracefully if a setup entry cannot be shown, e.g. tell the user understandably what's the issue why the setup entry can't be shown. Also splash screen should be shown without map data available. Any idea about the crash when pressing the home button? Is this also related to the missing map data?

Menu button fixed in git, should also be in snapshot. Yes, I'd say home button crash is probably due to missing map data. I agree that the splash screen should be shown even with no map. However, while a good goal, it might be needlessly complicated to make everything work even without map data. Instead, would be a good idea to always bundle the internal map, and when map data is missing, inform the user and present the user with a choice of three options: 1) switch to the internal map 2) select an existing external map 3) exit GpsMid Option 3) would be a needed choice for the cases when the user realizes "Oh, the map is in the card that is mounted on the computer" or "Ah, the phone hasn't started up yet, and sdcard is not available yet" among others.

Tested again on HTC Desire Z with latest nightly: "Press back again..." saved me a couple of times from accidentially exiting GpsMid. Overall good performance with >200MB zipped map, however some unexpected non-reproducable exits of GpsMid, e.g. in GuiSearch. Maybe increasing the number of search results made this more stable.

Still trying to improve map looks on Android without needing to the drawlines hack. As using native Android views doesn't work yet, I decided to modify J2MEPolish so I can directly access the Android canvas & paint objects. This way I could try the various antialiasing & stroke width options for drawing filled triangles. Could't get any to improve things. Then I tried sk750's idea of having all the triangles in the same path (diff below). Compiles & runs, and some buildings are areas are OK. But many triangles seem to be missing a rectangular building consisting of two triangles has only one triangle. Also more complicated buildings are warped in more complicated ways. int idx; + //#if polish.android + if (path.length > 0) { + Path aPath = new Path(); + g.getPaint().setStyle(Style.FILL); + idx = path[0]; + if (idx < 0) { + idx += 65536; + } + p.forward(t.nodeLat[idx],t.nodeLon[idx],p1,t); + aPath.moveTo(p1.x + g.getTranslateX(), p1.y + g.getTranslateY()); + for (int i1 = 1; i1 < path.length; ){ + idx = path[i1++]; + if (idx < 0) { + idx += 65536; + } + p.forward(t.nodeLat[idx],t.nodeLon[idx],p2,t); + if (i1 % 3 == 0) { + p1 = p2; + } + aPath.lineTo(p2.x + g.getTranslateX(), p2.y + g.getTranslateY()); + if (i1 % 3 == 2) { + aPath.lineTo(p1.x + g.getTranslateX(), p1.y + g.getTranslateY()); + } + } + aPath.close(); + g.getCanvas().drawPath(aPath, g.getPaint()); + g.getPaint().setStyle(Style.STROKE); + } + //#else for (int i1 = 0; i1 < path.length; ){ // pc.g.setColor(wayDesc.lineColor);

Tried with real multipolygons, i.e. don't use the results of triangulation in Osm2GpsMid but just write the path to the map data. Seems to mostly work for a small map, though probably the area splitter needs to be modified for this to make bigger maps work. Can't say anything about speed yet, as so much is different with the small map.

Switched area splitting off, and now map is flawless, and performance seems very good, though no comparable numbers yet as I still only have a Helsinki region map, not country-wide. One problem though, an arrayindexoutofbounds exception when zooming out, e.g. length=99;index=175:length=99;index=175

OK, now I've got numbers from the version drawing areas directly with android native Paths. Looks very good! From 14s / 6s down to 0,5-2 seconds with no need for map simplifying. Probably will be even better after I rewrite way drawing to use Paths. As paths can contain arcs, would also be doable to improve performance for the rounded way ends. Very promising, though a few issues to iron out: * sea tiles flood more than usually, but this is probably due to the sea tile code geneting non-closed (buggy) polygons and gives a good incentive to repair the broken sea tile code * null reads from map * the index errors * make it work with non-modified J2MEPolish; now it relies on a modified j2mepolish which makes lcdui's graphics canvas & paint objects public I/System.out(29564): Painting map took 1068 ms 992/1524 I/System.out(29564): Painting map took 1209 ms 992/1524 I/System.out(29564): Painting map took 1042 ms 992/1524 I/System.out(29564): Painting map took 740 ms 992/1524 I/System.out(29564): Painting map took 730 ms 992/1524 I/System.out(29564): Painting map took 844 ms 992/1524 I/System.out(29564): Painting map took 828 ms 992/1524 I/System.out(29564): Painting map took 585 ms 992/1524 I/System.out(29564): Painting map took 827 ms 992/1524 comparison to the current git times: // with 250 m zoom on Sams. Galaxy Note, paint times with the drawLines: // I/System.out( 7740): Painting map took 18176 ms 992/1524 // I/System.out( 7740): Painting map took 19300 ms 992/1524 // I/System.out( 7740): Painting map took 14855 ms 992/1524 // I/System.out( 7740): Painting map took 14030 ms 992/1524 // I/System.out( 7740): Painting map took 14450 ms 992/1524 // I/System.out( 7740): Painting map took 13993 ms 992/1524 // I/System.out( 7740): Painting map took 13572 ms 992/1524 // without drawLines: // I/System.out( 8938): Painting map took 6304 ms 992/1524 // I/System.out( 8938): Painting map took 5430 ms 992/1524 // I/System.out( 8938): Painting map took 5587 ms 992/1524 // I/System.out( 8938): Painting map took 5219 ms 992/1524 // I/System.out( 8938): Painting map took 4609 ms 992/1524 // I/System.out( 8938): Painting map took 4386 ms 992/1524 // I/System.out( 8938): Painting map took 4287 ms 992/1524

Most of the stuff on the list is now done, so it's time to take a look at the situation. (the list is at https://sourceforge.net/apps/mediawiki/gpsmid/index.php?title=DeveloperInfo#When_to_move_the_Android_version_to_release_status ) What's missing from the list is a) comprehensive documentation on what works and what has problems, and what targets to use and b) friendlier UI for some functions. On this front, by the original criteria, most of the above now has been done, so the Android version would be ripe for release - or not, depending on how friendly we want the UI to be. It's told first impressions matter a lot, so it might be good to still improve the UI. Also, relating to first impressions, there's one big performance issue. With current GpsMid, the user's performance experience in map display is worse than on many, even not-so-high-end J2ME devices, even though most current Android devices are more powerful than the J2ME devices. There's a partially working up-to-10-times improvement by using Android native multipolygons instead of the current triangulation for drawing areas. The improvement makes GpsMid on Android feel much more responsive and up to what Android users expect, which the current git version definitely isn't (especially with pinch zoom & map panning) on the phones I've used. So, my position is to not declare Android version release quality yet, but to aim to have the performance improvement in, and aim to improve the UI dialogues with settings, waypoints, SMS etc.

Mostly agreed, so I also think we should get out an official GpsMid Android release soon... One thing that still irritates me on Android are the GPS connects/disconnects when going to home screen (http://sourceforge.net/tracker/index.php?func=detail&aid=3548280&group_id=192084&atid=939974). Also any crashes we detect in should be fixed for stability experience. Irritating is sometimes also the behaviour of the Back button, after e.g. using it to close the device's on-screen keyboard the toast for exit tends to come up, same for returning from icon menu or somewhere else I think. But might be me or device specific, at least I did not accidentally exit GpsMid.

Also very irritating is that when in icon menu or e.g. in "Enter waypoint" you press the Home button and then returning to GpsMid the map will be shown. This is especially irritating because the calculated route is still there, i.e. GpsMid is just resumed.

I think I've fixed a couple of bugs with back key trying to exit in the last few weeks, but might be the issue still happens somewhere. I think it's been mostly cases where the Android native UI methods have been used; a special back key catcher is required for at least some of those cases. If you can find a repeatable case, that can probably be fixed relatively easily.

Lately, I don't remember seeing force closes, except the one I reported, forget what that was about. The "GpsMid has been stopped" messages I've seen seem to be cased by out of memory condition. (Hmm, though now I begin to wonder if reporting of crashes has changed with the ICS upgrade of the Note for "force close" to ".. stopped", not sure about this). Occasionally I think I've seen routing == null messages.

"Also very irritating is that when in icon menu or e.g. in "Enter waypoint" you press the Home button and then returning to GpsMid the map will be shown. This is especially irritating because the calculated route is still there, i.e. GpsMid is just resumed. " Also happened when an incoming phone call came in. Fixed for the case when GpsMid is not killed - probably covers most typical cases when user does something else smallish from home screen or a call comes in. However, depending on memory available, etc, Android might also kill GpsMid, and to keep the form info in that case would require storing it in recordstore or somewhere else. Or maybe calling wakelock or something to try and keep active, will probably have to look into that sometime.

It would be nice for Android to have Osm2GpsMid output for Android in addition to the zipped map also the .apk file and tell the user what to do with it (or of course instead bundle the map data to the apk). This could be done if the user generates a GpsMid with e.g. "GpsMid-Generic-Android" as phone capability template in the wizard. Regarding ZIP maps it would be probably be preferable for resource and maybe performance reasons to read them with native Android API http://developer.android.com/reference/java/util/zip/ZipFile.html . Also no more need for package net.sourceforge.util.zip on Android with this.

An update on Android stuff: * almost all of the list in the first post of this thread is done; some UI & documentation improvements could still be done, but what we have fulfills the criteria set in that post for moving to release status * Osm2GpsMid can now create .apk's (bundled maps), though there are some complications with signing, which is required to install an .apk on a real Android device * good and bad news about the performance-related area outlines feature ** Good news is that it seems to work well for small objects, and there's hole support now. ** Bad news is that many of the bigger map objects (lakes) are malformed and sea tiles are not useful, so if the area has big lakes and sea, the outline map is quite a lot uglier than the triangulated version. Not sure of the reason, might be a bug not found yet or a missing feature, but I suspect it's difficulty with lake being too big for a tile, as currently there's no way to properly split outline areas, as there's for triangles. One problem currently still with the outline format is that Osm2GpsMid currently can't produce a map both with triangle format and area format. The map format supports this, but triangulation mucks with the area paths so that outline areas are corrupted.

Map formats work now (though both have to be produced, no possibility for area format only for now), and map is generated and shown correctly for both formats. @sk750, you mentioned something about NMEA errors. I can't find it now however, was it a HTC Desire device? I fixed one NMEA parse error issue with the old HTC Desire which matched how I recall your report.

NMEA parsing errors were on a HTC Wildfire S device, not on HTC Desire Z but can't test for about 1 - 2 weeks on the Wildfire S. Outline map format seems a great performance improvement on both Android devices. Both Android devices play the voice instructions a lot faster than on Nokia 5800.

Some outdoor experiences with Android: Compass rotate immediately is the false default, sorry. It makes the map too unstable when walking. - base zoom level should be higher on Android by default, e.g. 25, on big displays maybe even 26 - The mobile does not get so hot with the map in outline format. I suggest a toast or alert on map start to warn the user if he uses a map in triangle format on Android. - There are issues with GuiSearch: at the start favorites are shown, when typing some numbers on virtual keyboard, the search results show up. However, when deleting the typed letters, the favorites are not shown again like on j2me. Second issue with GuiSearch is that when tapping a favourite the virtual keyboard is toggled between cursor and letter mode.

Hard to say anything about zoom level numbers, as I don't grasp how it matches to map scale. Seems that GpsMid expects the user to know the concept of "Base Zoom Level" in settings, maybe zoom level should be shown on the map (near the scale bar? in the "tile number" field?) to make user familiar with the concept if it matters. Though "zoom level" seems a bit strange from UI point of view good concept to have for a vector map display with pinch zoom (zoom with no steps). But to introduce raster maps it could be useful, so as it's used so far, good to keep too.

Seems that mostly maps use zoom levels 0..19, see http://wiki.openstreetmap.org/wiki/Zoom_levels and http://www.globalnerdy.com/2008/11/09/universal-zoom-levels-for-google-maps-live-search-maps-and-yahoo-maps/ - looking at the descriptions, apparently the GpsMid zoom levels are something different from OSM or Google? Any particular reason if this is so?