Fixed
Status Update
Comments
al...@gmail.com <al...@gmail.com> #2
Im not talking about markers. Im talking about map itself.
to...@gmail.com <to...@gmail.com> #3
In our case, we are using a clustering algorithm which will be invoked, if user stopps dragging around.
Because "onCameraChange()" is getting called very often, clustering happens very often. So this is not a valuable solution for us.
Because "onCameraChange()" is getting called very often, clustering happens very often. So this is not a valuable solution for us.
to...@gmail.com <to...@gmail.com> #4
Here is a possible workaround:
You have to extend SupportMapFragment or MapFragment. In onCreateView you have to wrap your MapView in a customized FrameLayout (in example below it is the class "TouchableWrapper"), in which you intercepts touch events and recognizes whether the map is tapped or not. If your "onCameraChange" gets called, just check whether the map view is pressed or not (in example below this is the variable "mMapIsTouched").
Example code:
Customized FrameLayout:
private class TouchableWrapper extends FrameLayout {
@Override
public boolean onInterceptTouchEvent(MotionEvent ev) {
switch (ev.getAction()) {
case MotionEvent.ACTION_DOWN:
mMapIsTouched = true;
break;
case MotionEvent.ACTION_UP:
mMapIsTouched = false;
break;
}
return super.onInterceptTouchEvent(ev);
}
}
}
In your MapFragment:
@Override
public View onCreateView(LayoutInflater arg0, ViewGroup arg1, Bundle arg2) {
final FrameLayout view = (FrameLayout) super.onCreateView(arg0, arg1, arg2);
mTouchView = new TouchableWrapper(getActivity());
mTouchView.addView(view);
return mTouchView;
}
In your camera change callback method:
private final OnCameraChangeListener mOnCameraChangeListener = new OnCameraChangeListener() {
@Override
public void onCameraChange(CameraPosition cameraPosition) {
if (!mMapIsTouched) {
refreshClustering(false);
}
}
};
You have to extend SupportMapFragment or MapFragment. In onCreateView you have to wrap your MapView in a customized FrameLayout (in example below it is the class "TouchableWrapper"), in which you intercepts touch events and recognizes whether the map is tapped or not. If your "onCameraChange" gets called, just check whether the map view is pressed or not (in example below this is the variable "mMapIsTouched").
Example code:
Customized FrameLayout:
private class TouchableWrapper extends FrameLayout {
@Override
public boolean onInterceptTouchEvent(MotionEvent ev) {
switch (ev.getAction()) {
case MotionEvent.ACTION_DOWN:
mMapIsTouched = true;
break;
case MotionEvent.ACTION_UP:
mMapIsTouched = false;
break;
}
return super.onInterceptTouchEvent(ev);
}
}
}
In your MapFragment:
@Override
public View onCreateView(LayoutInflater arg0, ViewGroup arg1, Bundle arg2) {
final FrameLayout view = (FrameLayout) super.onCreateView(arg0, arg1, arg2);
mTouchView = new TouchableWrapper(getActivity());
mTouchView.addView(view);
return mTouchView;
}
In your camera change callback method:
private final OnCameraChangeListener mOnCameraChangeListener = new OnCameraChangeListener() {
@Override
public void onCameraChange(CameraPosition cameraPosition) {
if (!mMapIsTouched) {
refreshClustering(false);
}
}
};
al...@gmail.com <al...@gmail.com> #5
Thanks Andreas, I will look into that. Ho
cy...@gmail.com <cy...@gmail.com> #6
This is pretty much a hack :s. Changes are it won't work in future releases of the framework.
1. You're casting the returned to FrameLayout. This is unsafe and you actually don't need to.
2. Doing so will imply getView() returns a TouchableWrapper which is not the original View returned by MapFragment. Let's hope MapFragment is not internally using getView() to access to its supposed View... A proper way would be to override MapView instead and create you're own Fragment.
3. You're using onInterceptTouchEvent(MotionEvent) which may not be called if requestDisallowInterceptTouchEvent(boolean) (http://developer.android.com/reference/android/view/ViewGroup.html#requestDisallowInterceptTouchEvent(boolean) ) by a child View. Prefer using dispatchTouchEvent(MotionEvent).
1. You're casting the returned to FrameLayout. This is unsafe and you actually don't need to.
2. Doing so will imply getView() returns a TouchableWrapper which is not the original View returned by MapFragment. Let's hope MapFragment is not internally using getView() to access to its supposed View... A proper way would be to override MapView instead and create you're own Fragment.
3. You're using onInterceptTouchEvent(MotionEvent) which may not be called if requestDisallowInterceptTouchEvent(boolean) (
to...@gmail.com <to...@gmail.com> #7
#5
Thank you for your comments. I've made some changes to the code.
1. This is really unnecessarsy.
2. One solution to this issue is to hold a reference to the original content view which was generated by the MapFragment. Furthermore you then have to override getView() and to return the reference to the original content view.
3. good tip!
changed code:
@Override
public View onCreateView(LayoutInflater inflater, ViewGroup parent, Bundle savedInstanceState) {
mOriginalContentView = super.onCreateView(inflater, parent, savedInstanceState);
mTouchView = new TouchableWrapper(getActivity());
mTouchView.addView(mOriginalContentView);
return mTouchView;
}
added code:
@Override
public View getView() {
return mOriginalContentView;
}
Thank you for your comments. I've made some changes to the code.
1. This is really unnecessarsy.
2. One solution to this issue is to hold a reference to the original content view which was generated by the MapFragment. Furthermore you then have to override getView() and to return the reference to the original content view.
3. good tip!
changed code:
@Override
public View onCreateView(LayoutInflater inflater, ViewGroup parent, Bundle savedInstanceState) {
mOriginalContentView = super.onCreateView(inflater, parent, savedInstanceState);
mTouchView = new TouchableWrapper(getActivity());
mTouchView.addView(mOriginalContentView);
return mTouchView;
}
added code:
@Override
public View getView() {
return mOriginalContentView;
}
cy...@gmail.com <cy...@gmail.com> #8
[Comment deleted]
to...@gmail.com <to...@gmail.com> #9
In my opinion there are many reasons why it is helpful to have dedicated dragging / panning events:
- dragging or panning events are always published after an user interaction. For example the camera position can be changed programmatically without the interaction of the user.
- If a dragging / panning event occurs, the geographic center position must have changed. This is different to a camera change event as I can change the zoom level without changing the geographic position. This is the same for camera rotation or changes to the view angle.
- Usually dragging / panning events are ongoing events published as long as the user interacts with the map view. With such an event you can track the movement.
- dragging or panning events are always published after an user interaction. For example the camera position can be changed programmatically without the interaction of the user.
- If a dragging / panning event occurs, the geographic center position must have changed. This is different to a camera change event as I can change the zoom level without changing the geographic position. This is the same for camera rotation or changes to the view angle.
- Usually dragging / panning events are ongoing events published as long as the user interacts with the map view. With such an event you can track the movement.
cy...@gmail.com <cy...@gmail.com> #10
>> dragging or panning events are always published after an user interaction. For example the camera position can be changed programmatically without the interaction of the user.
I don't see the difference between a manual and programmatic change. I mean, in 99% of the cases they will have the same consequence: loading some information about the current camera target/visible are, right ?
>> If a dragging / panning event occurs, the geographic center position must have changed. This is different to a camera change event as I can change the zoom level without changing the geographic position. This is the same for camera rotation or changes to the view angle.
As I said, this is a subset of a camera change. It you want to know the map has been scrolled, just look at the current Camera target. In case it is different from the previous one, it means the map has been scrolled.
>> Usually dragging / panning events are ongoing events published as long as the user interacts with the map view. With such an event you can track the movement.
I'm OK with that. Personally, I don't see the need here but this is clearly something impossible right now as long as onCameraChanged will be fired as "un-predictably".
I don't see the difference between a manual and programmatic change. I mean, in 99% of the cases they will have the same consequence: loading some information about the current camera target/visible are, right ?
>> If a dragging / panning event occurs, the geographic center position must have changed. This is different to a camera change event as I can change the zoom level without changing the geographic position. This is the same for camera rotation or changes to the view angle.
As I said, this is a subset of a camera change. It you want to know the map has been scrolled, just look at the current Camera target. In case it is different from the previous one, it means the map has been scrolled.
>> Usually dragging / panning events are ongoing events published as long as the user interacts with the map view. With such an event you can track the movement.
I'm OK with that. Personally, I don't see the need here but this is clearly something impossible right now as long as onCameraChanged will be fired as "un-predictably".
to...@gmail.com <to...@gmail.com> #11
>> I don't see the difference between a manual and programmatic change. I mean, in 99% of the cases they will have the same consequence: loading some information about the current camera target/visible are, right ?
>> As I said, this is a subset of a camera change. It you want to know the map has been scrolled, just look at the current Camera target. In case it is different from the previous one, it means the map has been scrolled.
I think this is a question of programming style / taste. I personally like not to declare helper variables just to know whether the map center has changed or an action was performed programmatically or manual. It is nice to have. It is very welcome if a framework supports such niceties like the OnSeekBarChangeListener does (http://developer.android.com/reference/android/widget/SeekBar.OnSeekBarChangeListener.html ).
But besides the programming styles or questions of taste I had a look into Google Maps Javascript client framework and I've found that theframework supports dragging events (https://developers.google.com/maps/documentation/javascript/reference ).
Personally, I feel a need to have such kind of events. And why not to have both type of events, dragging and camera change events, in the map library?
>> As I said, this is a subset of a camera change. It you want to know the map has been scrolled, just look at the current Camera target. In case it is different from the previous one, it means the map has been scrolled.
I think this is a question of programming style / taste. I personally like not to declare helper variables just to know whether the map center has changed or an action was performed programmatically or manual. It is nice to have. It is very welcome if a framework supports such niceties like the OnSeekBarChangeListener does (
But besides the programming styles or questions of taste I had a look into Google Maps Javascript client framework and I've found that theframework supports dragging events (
Personally, I feel a need to have such kind of events. And why not to have both type of events, dragging and camera change events, in the map library?
al...@gmail.com <al...@gmail.com> #12
Googlers, please give you feedback =)
al...@gmail.com <al...@gmail.com> #13
Any updates on the timeline for this feature?
ba...@gmail.com <ba...@gmail.com> #14
>> I don't see the difference between a manual and programmatic change.
In our case there is a pretty big change. By default the map follows the users current location (whenever there is a a new location update from the gps we move the map programmatically). However, we want the following to stop if the user scrolled somewhere manually.
In our case there is a pretty big change. By default the map follows the users current location (whenever there is a a new location update from the gps we move the map programmatically). However, we want the following to stop if the user scrolled somewhere manually.
ro...@gmail.com <ro...@gmail.com> #16
Any update on the feature yet ?
ba...@gmail.com <ba...@gmail.com> #17
any updates on this? im working on a project that needs to have grayscale maps
ro...@gmail.com <ro...@gmail.com> #18
Any update of this map customization feature?
db...@gmail.com <db...@gmail.com> #19
Dear Google, should we wait on you or we have to go with www.mapbox.com or another alternatives? Our game can wait max till Feb 2014, but not any longer :(
ex...@gmail.com <ex...@gmail.com> #20
[Comment deleted]
db...@gmail.com <db...@gmail.com> #21
please make it possible to customize maps style.
ex...@gmail.com <ex...@gmail.com> #22
Thanks a lot. That's helpful!
ep...@gmail.com <ep...@gmail.com> #24
PLEEEEEEASE make it possible to customize maps style.
bs...@gmail.com <bs...@gmail.com> #25
I would also like to vote for this bug. Most times we just need polylines above a pure black background. Making everything not related to the track black would be the perfect solution.
ep...@gmail.com <ep...@gmail.com> #26
Want this!
mi...@gmail.com <mi...@gmail.com> #27
please make it possible to customize google maps via the api
st...@gmail.com <st...@gmail.com> #28
Yes Please make it possible
ne...@gmail.com <ne...@gmail.com> #29
yeah pls
bd...@gmail.com <bd...@gmail.com> #30
Google, we have a problem....
bl...@gmail.com <bl...@gmail.com> #31
The only workaround (while sticking with Google Maps) is to use a webview, which is extremely glitchy and performs poorly. This feature needs to be added to the SDK.
es...@gmail.com <es...@gmail.com> #32
Any official solution?
ed...@gmail.com <ed...@gmail.com> #33
Seriously, this is a 3-year-old issue and nothing has changed ...
an...@gmail.com <an...@gmail.com> #34
Why is this not a standard feature anyway???????
js...@gmail.com <js...@gmail.com> #35
I agree, I'm developing an iOS app with a GMSMapView and I was hopping to be able to change the map colors to match my app theme colors ... I think its an important feature to add to the SDK, please Google =D
st...@gmail.com <st...@gmail.com> #36
this needs to happen.
an...@gmail.com <an...@gmail.com> #37
we need it!
[Deleted User] <[Deleted User]> #38
please make it happen!
bl...@gmail.com <bl...@gmail.com> #40
I need this to happen as well! 8-)
sj...@gmail.com <sj...@gmail.com> #41
[Comment deleted]
lu...@gmail.com <lu...@gmail.com> #42
We would have used the Google Maps API instead of the native one if this had been implemented.
sk...@gmail.com <sk...@gmail.com> #43
Please add styled map feature in google map ios sdk
pk...@gmail.com <pk...@gmail.com> #44
Please please do this :(
da...@google.com <da...@google.com> #45
This is really important to us for accessibility reasons.
Description
In api v1 release i was able to handle this event manually using custom overlay that handles onTouch and onDraw.
Typical use case:
Geocode address according to center of the map. I can't just use "setOnCameraChangeListener" because i need to ensure that user has put finger up and animation was completed. "setOnCameraChangeListener" will on every animation has completed.
I have tried to implement that by myself. But you don't provide access to onTouch event. I even tried to handle event on parent layout, but map handles onTouch event and doesn't pop it up in view hierarchy.