Assigned
Status Update
No update yet.
Comments
mf...@gmail.com
that way will be cool and user friendly.
en...@google.com
Also having the option to either pan or zoom with the scroll wheel would be useful.
di...@android.com
"Add the ability to scroll using the mouse wheel, add it to default UI, and
let developers disable it."
that way will help user for zoom in & zoom out easier..
let developers disable it."
that way will help user for zoom in & zoom out easier..
en...@google.com
I need mouse wheel to operate zooming in and out.
I have wait for several weeks already.
develop from Beijing China
I have wait for several weeks already.
develop from Beijing China
ph...@gmail.com
Mousewheel zooming please! :)
an...@gmail.com
I can see that this issue is "Acknowledged", but is there any way to see when it
will be released?
will be released?
op...@gmail.com
When an issue in this tracker changes status (like from Acknowledged->Fixed), you'll
receive an email saying so. We generally don't reveal timelines for feature requests.
receive an email saying so. We generally don't reveal timelines for feature requests.
ph...@gmail.com
Pamela, for being fair: this is not feature request. This is backward compatibility
issue.
I think this is the only one blocking issue for migrating from GMap API v2 to v3.
issue.
I think this is the only one blocking issue for migrating from GMap API v2 to v3.
ia...@gmail.com
#9, this is definitely not the only feature missing in v3. The overview page states
"The initial launch has a smaller feature set than that available in the V2 API."
"The initial launch has a smaller feature set than that available in the V2 API."
[Deleted User] <[Deleted User]>
#8 I appreciate the quick answer, right now I'm about to choose to either develop a
new site on the old v2 or the new v3 api, the site is scheduled to be in production
within this year, what are the pros and cones i have to consider?
new site on the old v2 or the new v3 api, the site is scheduled to be in production
within this year, what are the pros and cones i have to consider?
ia...@gmail.com
I'd recommend going with v2 API for now. It is the safer choice. I recently strated a
project with v3 and had to port back to v2 in a hurry because I ran into compatibility
issues with IE.
project with v3 and had to port back to v2 in a hurry because I ran into compatibility
issues with IE.
ke...@auxbrain.com
pleeeeaaaaassseeeeeeeee!!! ;)
en...@google.com
en...@google.com
Is it ready yet? This is a great feature you must include it!
en...@google.com
Nianwei created an open-source scroll wheel zoom implementation, you may want to try it
out:
http://groups.google.com/group/google-maps-utility-library-
v3/browse_thread/thread/f421e075eb63d2ba
out:
v3/browse_thread/thread/f421e075eb63d2ba
Description
The problem was observed while developing a native app using ndk-r8b.
The symptom is: AStorageManager_getMountedObbPath() randomly returns corrupt strings. In my case, i would estimate about 1/5 of every invocation of the function fails.
1.1) Relevant sample code (my app):
static void obbCallback(const char* filename, const int32_t state, void* data)
{
switch( state ) {
case AOBB_STATE_MOUNTED:
PrefixDir = strdup(AStorageManager_getMountedObbPath(engineGlobal->storageManager, filename));
LOGI("obbCallback mounted as %s\n", PrefixDir);
1.2) Output from logcat
I/OPPP ( 895): obbCallback mounted as /mnt/obb/ee81fba48478bfaf8edcb00f605a8e22
(this is the good one)
I/OPPP ( 895): obbCallback mounted as /mnt/obb/ee81fba48478bfaf8edcb00f605a8e2@
(last "2" replaced for "@")
I/OPPP ( 895): obbCallback mounted as /mnt/obb/ee81fba48478bfaf8edcb00f605a8e2P
(last "2" replaced for "P")
I/OPPP ( 913): obbCallback mounted as /mnt/obb/ee81fba48478bfaf8ed
(string truncated)
1.3) Architectures affected
Bug has been seen under Android 2.3.3 (emulator) and Android 2.3.6 (samsung phone). Evidence (below) is that it is still present in latest versions as well.
2) Bug analysis
2.1) Relevant Android code:
2.2) Analysis
AStorageManager_getMountedObbPath is just a proxy:
const char* AStorageManager_getMountedObbPath(AStorageManager* mgr, const char* filename) {
return mgr->getMountedObbPath(filename);
}
The real function is AStorageManager::getMountedObbPath:
const char* getMountedObbPath(const char* filename) {
String16 filename16(filename);
String16 path16;
if (mMountService->getMountedObbPath(filename16, path16)) {
return String8(path16).string();
} else {
return NULL;
}
}
2.3) The problem is:
- String8() object is constructed from path16.
- String8(const String16&) constructor uses allocFromUTF16() to allocate from SharedBuffer.
- string() method just returns the pointer of String8::mString.
- The object gets out of scope. Destructor will call SharedBuffer::release()
- The returned pointer now refers to an object that has just been freed.
- Results are unpredictable. Any new allocation will cause string corruption.
3) Fixes? Workarounds?
I can't thing of any. Suggestions?