Bug: Calling Marker.showInfoWindow() in onMarkerClick(Marker) and returning true causes Marker.isInfoWindowShown to still return false on subsequent marker clicks [35823077]

WAI

Bug

Status Update

No update yet.

Description

[Deleted User]

created issue #1

May 17, 2013 08:30PM

What steps will reproduce the problem? Please provide a link to a
demonstration page if at all possible, or attach code.

Example code:
public class MainActivity extends Activity implements OnMarkerClickListener {

private static final String TAG = "InfoWindowsBug";

@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
GoogleMap map = ((MapFragment)getFragmentManager().findFragmentById(R.id.map)).getMap();
map.setOnMarkerClickListener(this);
map.addMarker(new MarkerOptions().position(new LatLng(0d, 0d)).title("something"));
}

@Override
public boolean onMarkerClick(Marker marker) {
Log.v(TAG, "before: " + marker.isInfoWindowShown());
if(marker.isInfoWindowShown()) {
marker.hideInfoWindow();
} else {
marker.showInfoWindow();
}
Log.v(TAG, "after: " + marker.isInfoWindowShown());
return true;
}
}

I realize this probably looks like I'm needlessly re-implementing the default behavior of toggling info window visibility when a marker is clicked, but this is needed for a more complex scenario (which would be inappropriate to post in full here) to implement a user's feature request in my clustering library, see

https://github.com/twotoasters/clusterkraf/issues/10

Steps to repeat issue
1. Run the above example code
2. Tap the only marker on the map
3. Tap the only marker on the map again

Expected results
Logcat output
InfoWindowsBug: before: false
InfoWindowsBug: after: true
InfoWindowsBug: before: true
InfoWindowsBug: after: false

User experience
After #2, info window shown
After #3, info window not shown

Actual results
Logcat output
InfoWindowsBug: before: false
InfoWindowsBug: after: true
InfoWindowsBug: before: false
InfoWindowsBug: after: true

User experience
After #2, info window shown
After #3, info window shown

*********************************************************
For developers viewing this issue: please click the 'star' icon to be
notified of future changes, and to let us know how many of you are
interested in seeing it resolved.
*********************************************************

Comments

ga...@gmail.com <ga...@gmail.com> #2Nov 11, 2013 09:32PM

A link to another sample project demonstrating that the leak only happens when using: LocationServices.FusedLocationApi.requestLocationUpdates but does not happen using a deprecated method: googleMap.setOnMyLocationChangeListener.

https://github.com/fernandospr/android-maps-userlocation

ma...@googlemail.com <ma...@googlemail.com> #3Jan 9, 2014 02:39PM

Hello, I'm also experiencing the memory leak in my activity responsible for the location service.

The implementation of my project is not different from the example project attached by fernando.

ob...@gmail.com <ob...@gmail.com> #4May 26, 2014 08:03PM

FYI this memory leak also seems to exist when using the new FusedLocationProviderClient. I took Fernano's sample from

comment #2

and hacked it up to use the FusedLocationProviderClient and was still able to observe the leak upon exiting the activity.

ro...@gmail.com <ro...@gmail.com> #5Oct 12, 2014 02:00AM

Leak still present in 2019 on latest play-services-location 16.0.0. 3+ years since first reported via linked Github issue, no fix or hint of acknowledgment. Clown college grade software engineering.

va...@gmail.com <va...@gmail.com> #6Apr 14, 2015 11:21AM

I am also still experiencing this!

du...@gmail.com <du...@gmail.com> #7May 3, 2015 09:43PM

Still present in 'com.google.android.gms:play-services-location:17.0.0'

As an alternative I am using FusedLocationProviderClient with PendingIntent:

IntentFilter intentFilter = new IntentFilter(ACTION_LOCATION);
registerReceiver(locationReceiver, intentFilter);
mFusedLocationClient.requestLocationUpdates(mLocationRequest, locationPendingIntent);
and
unregisterReceiver(locationReceiver);
mFusedLocationClient.removeLocationUpdates(locationPendingIntent)

Here is forked LocationUpdates repo with LeakCanary installed and an option to switch between LocationCallback and PendingIntent. LeakCanary not reporting anything when using PendingIntent.

https://github.com/dejandobnikar/location-samples/tree/master/LocationUpdates

kl...@gmail.com <kl...@gmail.com> #8Jul 8, 2015 01:43PM

Thank you for your feedback. We assure you that we are doing our best to address all issues reported. For now, we will be closing the issue as won't fix obsolete. If this issue currently still exists, we request that you log a new issue along with the bug report here

https://goo.gl/TbMiIO and reference this bug for context.

fl...@googlemail.com <fl...@googlemail.com> #9Jul 13, 2015 04:40PM

Comment #8

, the one thing that would matter to address is how to *actually* get this issue fixed. It appears pointless to file a new issue, and unclear where to do so, as this issue has not received attention from Google's side throughout the years despite quite a few people starring it and bug reports in different places. The continued existence of the bug was confirmed not long ago in prior comments by different people. I've just confirmed it again myself on R Beta 3.

ka...@gmail.com <ka...@gmail.com> #10Jul 13, 2015 04:41PM

According to some Google DevRel it might soon be fixed, see the answer (from 8 days ago) here:

https://github.com/googlecodelabs/while-in-use-location/issues/7

ar...@gmail.com <ar...@gmail.com> #11Sep 29, 2015 10:25AM

This issue still exists, how can this be prioritized?

ar...@gmail.com <ar...@gmail.com> #12Sep 29, 2015 10:33AM

There is an issuetracker Component available these days for Play Services Location: https://issuetracker.google.com/components/1065160

Maybe move this issue to that Component to track it better?

ob...@gmail.com <ob...@gmail.com> #13Sep 29, 2015 10:43AM

I can't move it right now, but I think it's ok to stay here.

As I wrote in the code lab issue, I misunderstood when the rewrite went out (which should fix the issue).

It goes live in version 20 (current version location 19.0.1). The engineer who wrote the rewrite checked and wasn't seeing the same issue, i.e., it should be resolved.

However, that does mean we have to wait until 20 is released. I can check in again here when it's live for you to double check.

da...@gmail.com <da...@gmail.com> #14Sep 29, 2015 11:50AM

8 ram

ar...@gmail.com <ar...@gmail.com> #15Sep 29, 2015 01:31PM

I haven't been on location in awhile, but I wanted to follow up on this.

The issue should be resolved with the play-services-location:20.0.0 release from my understanding.

ar...@gmail.com <ar...@gmail.com> #16Sep 29, 2015 02:48PM

That's not the bug according to the documentation!
We may consider that as bug from usage perspective.

@Override
public boolean onMarkerClick(Marker marker)
From business logic this is not the proper place to call marker.isInfoWindowShown() function because it's always false as supposed to be. When OnMarkerClickListener call this function any opened InfoWindow have been already hidden by Map framework itself (so status 'false' technically is correct).

You can check that by example modifying overridden 'onMarkerClick' method
to open InfoWindows on even cliks only. On odd cliks - do nothing and see InfoWindows closes automatically by framework without explicit call to marker.hideInfoWindow();

To get actual InfoWindow status you should call 'marker.isInfoWindowShown' from another events or functions by keeping local references to any markers on map.

[Deleted User] <[Deleted User]> #17May 17, 2016 12:36AM

[Comment deleted]

[Deleted User] <[Deleted User]> #18May 17, 2016 01:10AM

I agree this seems like expected behavior. All the correct callback are fired: IE the close listener for the InfoWindow. Seems like a good framework.

lm...@google.com <lm...@google.com> #19Oct 25, 2016 02:39AM

Status: Won't Fix (Intended Behavior)

Thanks for the reports of this issue. We've looked into this closely and we believe that this is working as intended.

As #12 mentions, the second click on the same marker is handled the same as a click on any other marker. First, the currently showing info window is hidden and the onInfoWindowClose listener is called, causing isInfoWindowShown to return false from that point onwards. Next, the onMarkerClick listener is fired. Depending on the return value from the onMarkerClick listener the API will either move the map to centre the marker and show it's info window if it has one, or not. If an info window is shown then the isInfoWindowShown method will start returning true again, from that point onwards.

We've updated the documentation about info windows to make this behavior more explicit. See

https://developers.google.com/maps/documentation/android-api/infowindows#introduction.

We've also submitted a change to the javadoc for the OnMarkerClickListener which points out that calling Marker.isInfoWindowShown from this listener will return false. This javadoc update will be made with a future release.

It seems that some of you want the info window to close if the currently selected marker is tapped again. We cannot change the API to implement this behavior as the default, as that would break other apps which rely on the behavior as it currently is. Instead, we've added a new demo activity which shows how to implement that behavior. See that demo here:

https://github.com/googlemaps/android-samples/blob/master/ApiDemos/app/src/main/java/com/example/mapdemo/MarkerCloseInfoWindowOnRetapDemoActivity.java

The correct way to know which marker is currently showing an info window (if any) at the point the OnMarkerClickListener is fired is to keep a local reference to the Marker and update this reference at the appropriate times, as #16 mentioned. The demo above shows how to do this as well.