Has anyone successfully accessed the .serviceURL property of an offline .geodatabase file in the 100 or 100.1 iOS SDK? I have a file confirmed (in the 10.2.5 SDK version of my app) to have a Url in this property, but from the 100.1 SDK this same file's property is reading as an empty string.
A little background:
- The geodatabase contains operational layers generated from a feature service.
- The geodatabase is made by another program we wrote in house about a year and a half ago, confirmed to produce offline geodatabases containing this property.
- I normally expect the .serviceURL property to point to the feature service from which the offline geodatabase was generated.
- My test case showing this property as empty is
let featuresGeodatabase = AGSGeodatabase(fileURL: URL(fileURLWithPath: geodatabasePath))
po featuresGeodatabase.serviceURL
The result looks like ...
(lldb) po featuresGeodatabase.serviceURL
Optional<URL>
some :
On another machine running the previous 10.2.5 app, the result is
"http:/< our host server name>/geoservices/arcgis/rest/services/HATS_2_5_Qa_20170606/FeatureServer"
Thanks
-Reed
Solved! Go to Solution.
Have you loaded the geodatabase instance by calling load() on it prior to checking the syncEnabled property?
At 100.x, we have changed the gdb to follow the loadable pattern, which means that it doesn't initialize all of its state simply on instantiation. It must be explicitly loaded by calling load()
Hmmm, that is odd.
Is it a syncEnabled geodatabase? Can you check the "syncEnabled" property and tell us what it reports. It's possible that if it isn't syncEnabled we disregard the URL.
Can you give us some more details about how the gdb was generated? Was the gdb generated from runtime based client? Or directly through some GP tools or the server REST API?
It is sync enabled, and we've been using this successfully to sync hundreds of field devices for about two years. I now think that SDK version consistency is the issue. The nightly automation we use to generate and then zip these sync enabled offline geodatabases (which we then can download faster, unzip, and then register on our field devices) is done using the ArcGIS SDK for .Net 10.2.7. I ran into this problem then using a 10.2.7 .Net generated offline geodatabase on a 100.1 iOS SDK client, but had no problem with a 10.2.5 iOS SDK client.
Project deadlines for this release have pushed me back to the ArcGIS SDK for iOS 10.2.5, but we must revisit this and upgrade the SDK for our next release cycle. At that time I'll try upgrading my .Net automation's ArcGIS SDK to 100.1 to see if consistency between server and client side ArcGIS SDKs is the issue.
In answer to your questions, a .Net runtime client made the offline geodatabase with these calls:
var options = new GenerateGeodatabaseParameters(layerIds,new Envelope(xmin, ymin, xmax, ymax, SpatialReference.Create(wkid)))
{
SyncModel = SyncModel.PerLayer, AttachmentsSyncDirection = AttachmentsSyncDirection.Bidirectional, ReturnAttachments = true
};
await syncTask.GenerateGeodatabaseAsync(options, completionAction,
TimeSpan.FromSeconds(10), generationProgress, CancellationToken.None);
Right afterward this automation queries an unrelated database to populate some attribute fields in the local offline geodatabase, and then syncs those attribute changes up to the enterprise geodatabase. In this way we both generate an up to date geodatabase nightly for our users to download if they need to, and nightly true up some attributes generated outside our GIS for our users to access when they sync during the day. Every offline geodatabase is thus confirmed to support syncs.
Have you loaded the geodatabase instance by calling load() on it prior to checking the syncEnabled property?
At 100.x, we have changed the gdb to follow the loadable pattern, which means that it doesn't initialize all of its state simply on instantiation. It must be explicitly loaded by calling load()
That was it. After a call to
someAGSGeodatabaseVariable.load(completion: { error in
<access the .serviceURL property somewhere in here>
})
the .serviceURL property was populated.
Thanks Divesh.