Status Update
No update yet.
Comments
gr...@gmail.com
Argh....with this bug there is absolutely no way to determine if the user has changed changed the panning of the map....I need a way to determine this so that i can allow the user to reset the map to it's original view. Please fix this ASAP.
gr...@gmail.com
I have another example regarding the problematic accuracy of moveCamera/animateCamera.
When you use CameraUpdateFactory.newLatLngBounds(), moveCamera and animateCamera result in different values in map.getProjection().getVisibleRegion().latLngBounds.
LatLngBounds bounds = new LatLngBounds(new LatLng(40.70798493778415, -74.01434069136418), new LatLng(40.72072004852845, -73.99760391411343));
if (animate) {
map.animateCamera(CameraUpdateFactory.newLatLngBounds(bounds, 0),
} else {
map.moveCamera(CameraUpdateFactory.newLatLngBounds(bounds, 0));
}
map.getProjection().getVisibleRegion().latLngBounds :
after animateCamera -
LatLngBounds{southwest=lat/lng: (40.70711197865251,-74.01539381593466), northeast=lat/lng: (40.72159253556309,-73.99655096232891)}
after moveCamera -
LatLngBounds{southwest=lat/lng: (40.70798500292429,-74.01539381593466), northeast=lat/lng: (40.72071968970514,-73.99655096232891)}
This is pretty important for my design as im calculating a search radius (Vincenty’s formula) by the bounds of the map. appreciate if you could confirm the accuracy of those 2 APIs.
When you use CameraUpdateFactory.newLatLngBounds(), moveCamera and animateCamera result in different values in map.getProjection().getVisibleRegion().latLngBounds.
LatLngBounds bounds = new LatLngBounds(new LatLng(40.70798493778415, -74.01434069136418), new LatLng(40.72072004852845, -73.99760391411343));
if (animate) {
map.animateCamera(CameraUpdateFactory.newLatLngBounds(bounds, 0),
} else {
map.moveCamera(CameraUpdateFactory.newLatLngBounds(bounds, 0));
}
map.getProjection().getVisibleRegion().latLngBounds :
after animateCamera -
LatLngBounds{southwest=lat/lng: (40.70711197865251,-74.01539381593466), northeast=lat/lng: (40.72159253556309,-73.99655096232891)}
after moveCamera -
LatLngBounds{southwest=lat/lng: (40.70798500292429,-74.01539381593466), northeast=lat/lng: (40.72071968970514,-73.99655096232891)}
This is pretty important for my design as im calculating a search radius (Vincenty’s formula) by the bounds of the map. appreciate if you could confirm the accuracy of those 2 APIs.
en...@gmail.com
any news regarding this issue ?
da...@gmail.com
I can share my thoughts about it.
LatLng is keeping doubles, when these are sent via IPC, they are flattened to floats, because there is no writeDouble:http://developer.android.com/reference/android/os/Parcel.html#writeFloat%28float%29 .
When going back, you lose precision and thus errors on 4-5th decimal place.
If I'm correct here, this can be hard (if possible) to fix without breaking compatibility.
LatLng is keeping doubles, when these are sent via IPC, they are flattened to floats, because there is no writeDouble:
When going back, you lose precision and thus errors on 4-5th decimal place.
If I'm correct here, this can be hard (if possible) to fix without breaking compatibility.
gd...@gmail.com
If you're right then compatibility doesnt have to be broken in order to pass a more accurate LatLng value in many other parcelable types which are not float. This option can be added and not replace the current one.
I any case this issue is really annoying and i hope someone from google can take a look at it. Thanks.
I any case this issue is really annoying and i hope someone from google can take a look at it. Thanks.
Description
MY PHONE AND SOME RELEVANT HISTORY ON THE PROBLEM
I have a new Samsung Galaxy S2 in Australia and I have the same problem I note has been raised repeatedly since Android version 1.6 over 2 years ago. Presumably it has been progated from version to version since and no one has bothered to fix it.It is disgracefull that you have let this problem go on for so long.
THE PROBLEM
If you include the country code with a contacts phone number (eg +61. .... ....) then incoming calls from that contact are not recognised as coming from that contact and the contact's name is not displayed.
If you omit the country code from the contacts phone number (eg 02 .... ....) then text messages are not identified as coming from the contact.
NO IT'S NOT A CARRIER ISSUE
My previous phone was an old Sony Ericson K750 from 2005/2006 and it did not and still does not have this problem. Same Carrier, so 100% definetly not a carrier issue.
MY TEMPORARY AND VERY UNSATISFACTORY FIX
I have had to start storing all home, business and mobile (Cell for you Yanks) numbers twice each for every contact. With several huindred phone numbers this is very time consuming to do and a waste of phone memory. Worse this fix affects my synchronised outlook contact details so all my contacts now have phone numbers coming out their ears.
HOW SHOULD IT WORK
1. When/If the country code IS NOT included in the CID number supplied
by the carrier for an incoming call or text message the current
country code (i.e. the country you are in) should be assumed.
2. When/If the area code IS NOT included in the CID number supplied by
the carrier for an incoming call or text message the current area
code (i.e. the area of the country where the phone currently is)
should be assumed.
3. When/If the country code IS included in the CID number supplied by
the carrier for an incoming call or text message but no matching
number is found in the contacts list the country code should be
stripped off and a search done for the remaining number. Pre-pending
a zero to the trimmed number may be required.
4. When/If the Area code IS included (obviously this would mean
without the country code) in the CID number supplied by
the carrier for an incoming call or text message but no matching
number is found in the contacts list the leading 0 (or whatever the
convention is in other countries - if any different) and the country
prefix pre-pended and a search done on this complete number. Should
this also fail to find a match the country code and area code should
then both be stripped off the CID number and a search done for the
local number.
Points 3 and 4 above could probably be simplified by doing a right to left search of the numbers until a conflicting character is reached or a complete match is found or one of the numbers runs out of digits with no conflicting digits.
Seems simple enough.
Even simpler would be to always append the current country code and the current area code to a number if not specifically inserted by the user. Alternativel ask the users to select a default country and area code for all phone numbers entered. Attach these countrya nd area prefixes if others are not specifically entered for the contact.
Please FIX IT ASAP.