Manage Geojson sources (Android Bug, all-SDK opportunity)

[nitrag]

Please find a better name for this title!

This is an Android issue but I have a proposal for all platforms for the best long-term solution.

In Android we start with an empty GeoJsonSource (Why is this not a ShapeSource like iOS?) As the user pans the map, API requests fetch new GeoJSON to add to this source.

In Android, we are running into an issue where we have manage a JSONObject which API responses get merged to. Eventually we will get a TransactiontooLargeException triggered during a screen rotation onResume() "where it pulls the parcel from onSaveInstance()"

In iOS, we don't have to manage a global object because it is possible to extract the shape source's data live, modify it, and set it to the new object, then memory is then released.

For parity in Android we need a getGeoJSON function.

Or, the better yet, it would be best if all platforms had anappendGeoJSON()/appendShape function

Android

//current
...
newGeoJSONData = Utils.mergeGeoJSON(oldGeoJSONdata, APIresponse);
String geoJSONString = String.valueOf(newGeoJSONData);
myDataSource.setGeoJson(geoJSONString);

//proposed
...
String geoJSONString = String.valueOf(newGeoJSONData);
myDataSource.appendGeoJson(geoJSONString);

iOS

//current
...
if let newData = mergeGeoJSONfeatures(old: self.campsiteData?.shape?.geoJSONData(usingEncoding: String.Encoding.utf8.rawValue), new: APIresponse) {
    if let shape = try? MGLShape(data: newData, encoding: String.Encoding.utf8.rawValue) {
        DispatchQueue.main.async {
            self.campsiteData?.shape = shape
        }
    }
}
//proposed
if let newShapes = try? MGLShape(data: APIresponse, encoding: String.Encoding.utf8.rawValue) {
    DispatchQueue.main.async {
        self.campsiteData?.appendShapes = newShapes
    }
}

It would be best managed at the C++/SDK level for best performance and memory management.

[1ec5]

Or, the better yet, it would be best if all platforms had anappendGeoJSON()/appendShape function

Tracking for iOS and macOS in #7458.

It would be best managed at the C++/SDK level for best performance and memory management.

Tracking in #7376.

[stale]

This issue has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions.