Routing without options from GuiSearch doesn't work
Brought to you by:
james22
Menu
▾
▴
#594 Routing without options from GuiSearch doesn't work
On Nokia 5800:
1) Deactivate the ask for route options in Setup/Routing
2) Use GuiSearch, select a result
3) From virtual keyboard select "Route"
About every second time doing this the map will not be rendered again - GpsMid seems to be in the foreground (just recognizable from the title bar) but there's no map displayed, not even the map background, just seeing e.g. the Nokia Home screen. However, at least the initial route instruction is given.
This looks strange in GuiRoute:
logger.info("Search selected: " + positionMark);
if (!parent.isShowingSplitSearch()) {
parent.show();
destroy();
}
if (c == ROUTE1_CMD || c == ROUTE2_CMD) {
parent.performIconAction(Trace.ROUTING_START_WITH_OPTIONAL_MODE_SELECT_CMD, null);
}
return;
If we're not showing splitscreen, we first call .show() in Trace, and then call performIconAction() which also calls show() in Trace. Could be the race or related.
Found a way to repeat this on Android - it's the (nonexistent/wrongly interpreted on 5800, real on Android) long tap which triggers this - can route properly on android with single tap on virtual kb route, but with lang tap when route options asking is off, GpsMid remains in the search screen and search for "e" destinations.
But considering that the long tap timer is required on 5800 to detect normal pointer release and the 5800 doesn't give pointerrelease to distinguish between short tap and long tap, it seems we can't have the functionality to long tap on virtual kb on the 5800, right? (I think this was your idea originally). Hmm, though I added it for Android only, so I've noticed this already then, nevermind.
Anyway, needs to be fixed and it's in autopointerrelease.
Just when I got confident after several tries that it would have helped to comment out parent.show(); in the code piece below, the issue occured again. Will commit anyway.
Given that there's no way to change travel mode from virtual keyboard - the most important route option - we should now consider showing the route options from GuiSearch always.
I think we must not do that. It makes destination searching & routing slower and more difficult, we shouldn't force that on the user.
But then would be much more user-friendly to have instead of X in the choose virtual keyboard a toggle to select the travel mode.
To make your wish of easy routing to work on the 5800, I suggest we replace the X for closing the virtual keyboard in the search screen with "route to" or however it's named, mean the function now on '3' on the second screen of virtual kb. Also swap the X and '3' in the second screen to have routing be in the same place.
Not sure how useful the '<' / '>' arrows are for touch screen, maybe replace them with something also - I find '>* useful on a keyboard device to "paint" a name, but on touch screen we could have other means for that. Don't remember if '<' does anything useful or if it's just to pair with '>*.
Not sure, we can leave for the release like it is. The map not reappearing is annyoing of course but does not happen frequently.
Regarding < and > , they are for editing your input by moving the cursor. Maybe we should have in addition to abc, two virtual keypads, cursor AND choose, thus gaining new keys.
Well, just an idea, not for the release.
"Regarding < and > , they are for editing your input by moving the cursor."
Yes, but are they really useful? At least for touch-only Android, I don't think they're very useful.
"Maybe we should have in addition to abc, two virtual keypads, cursor AND
choose, thus gaining new keys.
Well, just an idea, not for the release."
With windows and virtual kb screens converted to windows, could let users rearrange & resize them.
> Yes, but are they really useful? At least for touch-only Android, I don't
think they're very useful.
Using them very seldom just like ^ and v. < > would become a bit more useful on Android if typed letters where shown.
Hmm, apparently for the 5800, almost all of the code execution path is the same as for the Android long tap on '3' shortcut. (as there's apparently often no pointer release event on the 5800). Meaning that this goes via auto pointer release.
For Android, the bug was that show() or some other UI code was needed to be called from UI thread, and using runonuithread solved it.
I know that in other places where runonuithread is needed on Android, nothing special is needed on J2ME. But maybe there's still something similar going on here as was with Android.
I added immediate rewdraw code for startRouting() where the '3' press ends in, please check if it solves the issue.
Which commit? I did not experience the issue for a while.
Forgot to push, commit c1066e0c6de52e9b38761683896ee4fcfbaf6876
No, this can't be the solution, there was no map at all, not even TraceLayout.
As your commit contains synchronized() it might cause dead locks in my experience, can you please revert?
Reverted. The same code snippet is in stopRouting(), maybe look over if there's also deadlock risk
synchronized (this) {
if (imageCollector != null) {
imageCollector.newDataReady();
}
}
Hmm... never saw one, but then, mostly after routing I just exit GpsMid.
Lowering priority, as you say can be left like this for release, and I think this hits only the S60v3 devices.