Although street names are flashing on hardware rendering, while there are shown constantly on software rendering on my Xperia Active.
Interestingly hardware rendering seem to be much more stable on my old Xperia Active rather than on my (in comparison to the Xperia Active) more modern Asus tablet K004.
One question for @mdx Why android project was removed from crowdin? I think that if project is more available, than translations will have more time for fixes.
first thanks Natalie we did look at crowdin and there was some activity at the beginning, but after that it died off we are examining other possibilities
@tomas There is no activity because probably no one knows about it. I found information about translations by chance in this topic. Shame that currently I cannot correct some text after first android alpha release.
@Tomas: You don't seem to have a talent in motivating your committed users in this community. Please note that a number of us, as @chattiewoman already mentioned, spent hours in translating the sentences. Both for the Windows phone version as well as the Android version where most users do not even have a windows phone.
The fact that a number of other languages were not touched, doesn't mean that the translators didn't spend a lot of hours. Yes, we are using a "free" app with openstreet maps and didn't donate (me not anyway), but please note that the hours we spend and have spent on this project are worth a lot of money if we would have done it as paid job.
Note also that the second step of the translation was voting for and judging the correctness of the translations. As translator you can't do that for your own language and mostly neither for other languages as you don't master them enough.
please understand that crowdin is not free we looked at activity and, considering price, it was decided that it was not worth the price we are looking at alternatives please note that we all appreciate your help
2.0.16 - improved route recalculation with several waypoints - fixed jump to detail for two finger gesture - smaller dynamic vector data cache - better threading during autozoom - GLES: corrected arrow position in 2D - bugfixes (navigate from contacts, show maneuver on map during route recalculation) - improved GPX statistics info
... it should hopefully fix problem with several waypoints and route recalucation - if not please let us know p.s. GP beta link is also updated
08-21 09:03:12.561 E/AndroidRuntime(20420): FATAL EXCEPTION: main 08-21 09:03:12.561 E/AndroidRuntime(20420): java.lang.NoSuchMethodError: android.widget.ImageView.setX 08-21 09:03:12.561 E/AndroidRuntime(20420): at com.mapfactor.navigator.map.MapFragment$1.onSingleTapConfirmed(MapFragment.java:214) 08-21 09:03:12.561 E/AndroidRuntime(20420): at android.view.GestureDetector$GestureHandler.handleMessage(GestureDetector.java:271) 08-21 09:03:12.561 E/AndroidRuntime(20420): at android.os.Handler.dispatchMessage(Handler.java:99) 08-21 09:03:12.561 E/AndroidRuntime(20420): at android.os.Looper.loop(Looper.java:130) 08-21 09:03:12.561 E/AndroidRuntime(20420): at android.app.ActivityThread.main(ActivityThread.java:3806) 08-21 09:03:12.561 E/AndroidRuntime(20420): at java.lang.reflect.Method.invokeNative(Native Method) 08-21 09:03:12.561 E/AndroidRuntime(20420): at java.lang.reflect.Method.invoke(Method.java:507) 08-21 09:03:12.561 E/AndroidRuntime(20420): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:839) 08-21 09:03:12.561 E/AndroidRuntime(20420): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:597) 08-21 09:03:12.561 E/AndroidRuntime(20420): at dalvik.system.NativeStart.main(Native Method) 08-21 09:03:12.595 W/ActivityManager( 8694): Force finishing activity com.mapfactor.navigator/.map.MapActivity
also I see some error message in log (not related to crash)
08-21 09:20:33.640 I/dalvikvm( 2304): Failed resolving Lcom/mapfactor/navigator/NavigatorApplication$MpfcActivityLifecycleCallbacks; interface 22 'Landroid/app/Application$ActivityLifecycleCallbacks;' 08-21 09:20:33.640 W/dalvikvm( 2304): Link of class 'Lcom/mapfactor/navigator/NavigatorApplication$MpfcActivityLifecycleCallbacks;' failed 08-21 09:20:33.640 E/dalvikvm( 2304): Could not find class 'com.mapfactor.navigator.NavigatorApplication$MpfcActivityLifecycleCallbacks', referenced from method com.mapfactor.navigator.NavigatorApplication.onCreate
Some points of my productiv testing of hardware renderer on my Xperia Active (ICS).
A couple of days ago I had sound output at the speeker of the device as well as on the car audio connected via bluetooth, while the car audio was approx. one second behind the speaker ...
Reaction to tapping the screen or hardware (volume) buttons takes often many seconds (this may be due to the old hardware of the phone).
Hardware renderings look is nice (beginning with the more modern position arrow), I like it much more than the software rendering. On the other hand look should not do it over functionality.
Crossing streets are shown the same way as the street is shown on which I am driving. If the street name is set to a crossing, I do not know, if the name shows to the crossing street or the street I am on. May be MFN could indicate crossing streets within arrows as <streetname> and not |streetname|.
The 2.0.19 version works fine so far. However, I still think the zoom is a bit too far out. It could be my older eyes or the fact that my dashboard is so long and my windscreen about 300 meters away from my face, but the map is rather small. (I had an eye check recently and my eyes are slightly worse but still OK. Thanks for asking :) )
Feature request: Make the zoomfactor configurable: -30%, -20%, -10%, 0% (default), +10%, +20%, +30%.
I don't know if these zoomfactors are correct, as I can't see them of course, or that it should be like +25%, +50%, +75% or whatever magnification/shrink factor.
And thanks for enabling the "- fixed POI info description (removed restriction to 3 lines)" again and putting a slider bar as well. I will pick up where I left.
Edit: Forgot one "bug". Open MNF, goto to RouteInfo (already having a 3 point "pre" route), second tab, calculate a route, Display on Map => Screen jumps to "World Wide" view showing the entire world map instead of the route full screen. On "back" tap and redisplay it functions OK.
Hi Dmytrio and hvdwolf, thanks for reports - the easy one should be fixed. It is hard to say if "playing with icon zoom levels" is related to memory, imports, or some other bug :(. In meantime there is version 2.0.21: - fixed show route on map from itinerary - fixed toolbar timing for click on map - other bugfixes thanks Martin
logcat has stacktrace of C++ crashes(this is missing in navigator logs because it needs extra permissions). Logcat has same level as debug level in navigator settings. I personaly prefer reading our logs on high level(there are missing important things on medium level)
Up to now I‘ve tested the GLES-version with a Nexus 7, today I tried it the first time with a Moto G (4,5"). After a short while I switched to software rendering mode because I could hardly see the highlighted route. The route is too small / too narrow for me or too far zoomed out, especially in areas with buildings ot lots of roads. Configurable zoomfactors as suggested by hvdwolf could be a good way to handle different tastes.
The speed limit symbol even on the smalI 4,5“ display is in a perfect size now, but I am having difficulties reading the displayed informations like distance to next event, speed info etc, no matter which rendering method (no problem on Nexus 7).
I had a terrible navigation last weekend with hardware rendering on my Xperia Active (with ICS). I just wanted to travel to a village near Zschopau, which is about 17 km from Chemnitz. The map zoomed out and out and out, so there was Chomutov at one point indicated on the map, which is approx. 60 km away beeline and at a second point, there was Usti nad Labem indicated, which is approx. 80 km beeline. The full route was compressed to a couple of millimeters length on normal navigation view (not tapping show the full route on the display). Every tap on the screen took approx. 30 seconds to be answered from the phone.
A day or two later I navigated with the next GLES version (I think that was 2.x.20) and problems seemed to be gone.
Navigator 2.00.21 on my Asus K004 still crashes after less than one km simulation with hardware rendering. Simulation seems okay on software rendering on the same device though (I did not check to the finish, just stopped simulation after a couple of minutes).
Road before turn has turn:lanes="left|left;through|through|right" and if you want to turn left Navigator suggests "left;through" and "trough" lanes however correct lanes are "left" and "left;through". The reason of issue is road on which you cannot drive, because it is opposite lane. That is should be considered by Navigator.
This is a very long running bug by now. MNF does indeed not consider "separate roads". In all of these cases MNF wants you to go straight on and then (almost immediately) go left.
I assume in left-driving countries it is the opposite way. I can't remember I noticed that last holiday.
Fix should be easy. When Lane Assistance determines lanes, it should discard lanes which are forbidden by Turn restrictions or have opposite direction.
Also road with "turn:lanes" tag can be split into several parts (like in the case I provided).
I agree with you that "it should be easy" :) , but I'm not a programmer. What seems easy for the non-programmer, might not be so easy for the programmer.
Is there a relation between the split roads?
How far are they apart? does 30 meter means that it is a totally different road, like you have in cities?
The fact that some other nav apps do it correctly, means that is is solvable.