Offline geodatabase being cached somewhere?

[MichaelDavis3]

I'm experiencing some strange behavior trying to implement a feature in our apps to "reset" the offline geodatabase.  Basically if we need to push out schema changes (new domain items, different field names, additional fields, etc...) I want the app to archive the current offline geodatabase, download a new one, and refresh the mapView and associated list views.

The process of doing this is working fine.  The geodatabase is moved to a folder in the documents directory, a new download is initiated, and the replacement is loaded successfully.  However despite triggering a complete ViewDidLoad on the MapView (which re-initializes the MapView and AGSGDBGeodatabase objects) everything still act like they are pointed at the old database. 

Is it possible that the SDK is caching the geodatabase in memory somewhere and it isn't being cleared out? 

If so, is there a way to trigger a reset or clearing of this cache?

I suspect this is what's happening because after the reset process if I force-quit the app and re-open it all the newly downloaded data is in place and displayed correctly.

[MichaelDavis3]

Potentially related to this but not sure - when collecting new features in the offline geodatabase added features do not show up in the MapView until the map is zoomed in or out, despite kicking off a refresh on the AGSGDBFeatureLayer in the MapView when the new item is saved to the database.

[GagandeepSingh]

Hi Michael Davis​,

Can you explain what you mean by ViewDidLoad on the MapView? And if any of the tables from the old geodatabase are being used to render any layer in the map view?

Gagan

[MichaelDavis3]

Yes - our mapView loads several featureTableLayers from a local geodatabase (named msm.geodatabase).  When a user triggers the Reset command we throw out an NSNotification, the mapView listens for this and when it receives a reset notification it does the following:

• archive the existing local geodatabase (and -shm, -wal files) to a folder in the user directory, and rename to archive.geodatabase (-shm, -wal)
• Initiate a new download of a geodatabase from the feature service and save it with msm.geodatabase name.
• Trigger a [mapView reset] to clear all contents of the map
• Rebuild the mapView layers from newly downloaded geodatabase

The last step we've tried by both kicking off the specific function to add the basemap and local layers to the map, as well as triggering the viewDidLoad function, which pretty much does the same with plus some extra configuration.

Either way the mapView (and our list views connected to the same featureTableLayers act like they are still connected to the old database... which has been moved, renamed, and replaced by a new one.  If we kill the app and re-start it layers display data from the new database as expected.

[GagandeepSingh · Accepted solution]

Before initiating a new download, make sure you remove the featureTableLayers from the map view. This will ensure that there are no references to the old geodatabase and it can be released.

Right now, when you move the geodatabase to a new location, its not fully released from the old location. And when you download the new geodatabase, the handle or pointer may not be updated.

Let me know if this helps.

Gagan

[MichaelDavis3]

This solved the issue - move the archive of the original database to execute after the [mapView reset] is run in the completion block for the new database download.

Thanks!

Still trying to figure out why a new feature created in the listViews isn't reflected in the mapView until the user zooms in/out though...

Matt Cooper​