Open 1ec5 opened 4 years ago
Actually, calling mbgl::DatabaseFileSource::listOfflineRegions()
afterward returns exactly the same offline regions as before, as though the database write failed silently.
Edit: Never mind, PEBKAC.
It looks like we have a unit test for mbgl::OfflineDatabase::updateMetadata()
, but not for mbgl::DatabaseFileSource::updateOfflineMetadata()
. As far as I know, the iOS/macOS map SDK has easy access to the DatabaseFileSource
but not to the OfflineDatabase
.
cc @mapbox/maps-android @zugaldia
mapbox/mapbox-gl-native-ios#289 worked around this issue so that developers don’t need to work around it themselves. However, the workaround may not perform as well as if mbgl would return the updated region.
The
mbgl::DatabaseFileSource::updateOfflineMetadata()
method added in #6338 updates the offline region’s associated metadata in the offline database, but calling it effectively invalidates anymbgl::OfflineRegion
the SDK has previously obtained and wrapped in a platform-specific object. Getting that region’s metadata continues to return the same old value without reflecting the change that has taken place in the offline database.It’s very awkward for the iOS/macOS map SDK to tell developers that calling
-[MGLOfflinePack setContext:completionHandler:]
, as in mapbox/mapbox-gl-native-ios#289, would cause theMGLOfflinePack.context
property to become stale and that the only way to get the current context would be to reload the entire set of offline packs by calling-[MGLOfflineStorage reloadPacks]
(which callsmbgl::DatabaseFileSource::listOfflineRegions()
under the hood).The
mbgl::DatabaseFileSource::updateOfflineMetadata()
method’s callback should accept a replacementmbgl::OfflineRegion
with the updated metadata. The SDK could then update the MGLOfflinePack’s internal pointer to thembgl::OfflineRegion
with its replacement, and the SDK would remain internally consistent./cc @mapbox/gl-native @mapbox/maps-ios