Obsolete
Status Update
Comments
ra...@google.com <ra...@google.com> #2
Surely this is something that the developer can handle themselves. If they just have a reference to the Marker then add a custom property to the marker and use that as the id, I don't think we need to start adding more info to Marker objects for everyone.
I would need more use cases where this is out of the developers hands before I would consider putting this in the API.
I would need more use cases where this is out of the developers hands before I would consider putting this in the API.
ra...@google.com <ra...@google.com> #3
If there was a property name that was guaranteed to be safe - then sure. Theoretically any property name longer than three characters won't conflict with a closure-compiler renamed property, but this could break things:
myMarker.a = "test".
This would also be fixable by having a sub-property for objects that was designated for developers to add to.
myMarker.a = "test".
This would also be fixable by having a sub-property for objects that was designated for developers to add to.
ra...@google.com <ra...@google.com> #5
I'll re-open the bug. I agree and I can see the utility.
In the past, I've used MVC properties (marker.set('id', 1)) to make sure my custom properties aren't compiled down to names that may conflict with internal properties. You could use 'data' as a generic property that holds a generic data object.
In the past, I've used MVC properties (marker.set('id', 1)) to make sure my custom properties aren't compiled down to names that may conflict with internal properties. You could use 'data' as a generic property that holds a generic data object.
pa...@gmail.com <pa...@gmail.com> #6
New developers tend to have a hard time using MVC property syntax. And while it's a great solution, it's not exactly obvious. Just to illustrate the point, your suggestion is the first time I'd even thought about solving the problem in that manner.
I think "data" is a great name for this.
I think "data" is a great name for this.
ra...@google.com <ra...@google.com> #7
It's not perfect, though. As you said, we could start using any name in the API in the future (there are no reserved names)
For example, we use 'data' as a property name on HeatmapLayer.
For example, we use 'data' as a property name on HeatmapLayer.
Description
To avoid the possibility of sharing private information, please share bugreports and screenshots from Google Drive. Share files withandroid-bugreport@google.com and include only Google drive links in your bug. If attaching bug reports or other sensitive data directly to issues, please mark the attachment(s) as “Restricted ( https://developers.google.com/issue-tracker/concepts/restricted-content)” when creating a bug or adding a comment. Restricting or deleting your comment or attachment can also be done using the overflow menu after submitting.
Disclaimer: Please note, by submitting this bug report, you acknowledge that Google may use information included in the bug report to diagnose technical issues and to improve our products and services, in accordance with our Privacy Policy (https://policies.google.com/privacy ), and you agree that we may share it with engineering partners potentially impacted by your issue.
Bug reports include personal information logged on your device or by apps, such as: File names Installed apps and usage Email addresses of the profiles on the device Device identifiers, such as phone number Web history information, including URLs / URIs Location information, including limited location history Network information, such as IP/SSID/MAC addresses and saved or scanned APNs System or device information, such as memory and processes