We're developing an Android application (targeting API 19 and up) using C# and the Xamarin framework. A central component is a map which lives inside a WebViewClient - that map is Here Maps which is rendered using the Here Maps JS API v3 (not the Here Maps mobile Android SDK).
The issue: map.getZoom() returns 0 after a user pinch-to-zoom action
As a test we wired-up the following events: 'mapviewchangestart', 'mapviewchange', 'mapviewchangeend', 'sync' and then in the handler called map.getZoom() - except for 'sync' where we referenced e.newValue.zoom. Also the app can call map.getZoom() directly w/o any related map event. In each case however after a pinch-to-zoom action, getZoom() returns 0.
Thinking it could be async issue, we waited several secs (apx 30) for all events/handlers to complete before calling map.getZoom() - it returned 0.
However when tapping the map controls on the map (i.e. + -) to zoom or setting the zoom level programmatically, getZoom() functions as expected returning the correct zoom level. A possible clue: When pinching-to-zoom and the max zoom level is reached (i.e. 20), map.getZoom() correctly reflects 20.
Has anyone experienced something similar? Any thoughts or ideas (however minor) would be appreciated - thanks.
After working with our mapping partner and reviewing some sample code which they provided, we were able to ascertain that the issue was due to an incorrect assumption on our part:
getZoom() does NOT return an integer but rather a float
In our C# wrapper we incorrectly assumed it returned an integer and so whenever the value was not implicitly convertible to an integer (e.g. when it wasn't 3.0, 4.0, 5.0 etc) and instead had a decimal portion (such as 3.462) it was converted to zero(0) by C#.
Interesting to note is that whenever the map zoom control (+ -) UI buttons are used, the value appears to always increase/decrease to the next whole number integer (e.g. 3.462 would become 3.0 or 4.0) but when a pinch-to-zoom event occurs, the values generally contain a decimal portion.
We also assumed that there were 21 zoom levels (0 to 20) but this also appears to be an incorrect assumption - if anyone knows of some documentation elaborating on this that would be helpful.
In any event I guess this is essentially a case of needing to more closely RTFM and reassessing assumptions.