You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we return the Tangram MapData object when a developer adds a polyline, polygon, or marker using MapzenMap#addPolyline(Polyline) etc. This is problematic when combined with MapzenMap#setPersistMapData(true) because updating of internal state is not balanced. In the above example, when the Polyline is added and the developer is persisting map data (ie. letting our SDK handle MapData state restoration across orientation changes), we update an internal object to add the polyline as geometry to restore on orientation changes however the polyline is never removed from this internal object because developers call MapData#clear() on the returned Tangram object.
Now that we support MapData restoration, we need to wrap these objects so that calls to NewWrappedMapData#clear() update internal restoration state. When completing this work, consider a generic object which can abstract underlying implementation (so that developers don't have to worry about Tangram MapData vs Tangram Marker)
The text was updated successfully, but these errors were encountered:
Currently, we return the Tangram
MapData
object when a developer adds a polyline, polygon, or marker usingMapzenMap#addPolyline(Polyline)
etc. This is problematic when combined withMapzenMap#setPersistMapData(true)
because updating of internal state is not balanced. In the above example, when thePolyline
is added and the developer is persisting map data (ie. letting our SDK handle MapData state restoration across orientation changes), we update an internal object to add the polyline as geometry to restore on orientation changes however the polyline is never removed from this internal object because developers callMapData#clear()
on the returned Tangram object.Now that we support MapData restoration, we need to wrap these objects so that calls to
NewWrappedMapData#clear()
update internal restoration state. When completing this work, consider a generic object which can abstract underlying implementation (so that developers don't have to worry about Tangram MapData vs Tangram Marker)The text was updated successfully, but these errors were encountered: