Latest Contributions by ReedHunter

Thanks Ryan for taking a look.  It would have taken me a lot longer to have that confirmed and filed for your team. ... View more

It will be close to a month from now before the upgrade to 100.4 will be scheduled for my project, and it will be another week or two before I can take time off from other tasks to try again to configure the Sdk samples from 100.4.  I'll eventually have a chance to test on 100.4. ... View more

Just to expand on Divesh's response:    "Q2 - I think same layer instance cannot exist in two maps. Either remove it from the first map before adding it to the new one, or make a copy of it." On line 16 you declared    var map = mobileMapPackage.maps[0]   But then on line 18 that map was not assigned to MapView.map    self.mapView.map = AGSMap(basemap:AGSBasemap.lightGrayCanvasBasemap())   Depending on when/whether mobileMapPackage.maps[0] ever loads its layers, you may have a race condition on your hands between your line 18 AGSMap and the AGSMap at mobileMapPackage.maps[0] for which one gets to claim the layers in the operationalLayers property. You can avoid this by using the AGSMap at mobileMapPackage.maps[0] instead of the created one from line 18, meaning make line 18 into     self.mapView.map = mobileMapPackage.maps[0] You could then add the grey basemap in manually as an AGSArcGISTiledLayer, inserting it either at index 0 of the .operationalLayers array, or in the basemap.basemapLayers array of the AGSMap.   I ran into similar problems in my app when I first switched from the Runtime SDK 10.2.x .geodatabase files over to the 100.x SDK's MMPKs, and found that a layer coming from an MMPK can only be assigned/used in one AGSMap at a time.  If it's already assigned to an AGSMap's operationalLayers (or manually assigned to basemap.basemapLayers), it couldn't be used in another AGSMap.  But wait, you think to yourself, I'm only assigning the layers to the map I created once - like on line 22 of the code above.  The trick is with MMPKs that they already come with an AGSMap, the one you grab them from at mobileMapPackage.maps[0].  That means your layers are already being claimed.    And yet, your map successfully loaded those layers anyway.  What gives?  The layers after line 22 existed in the .operationalLayers array of both your mapView.map.operationalLayers and in mobileMapPackage.maps[0].operationalLayers.  The answer I believe is in the async nature of the 100.x SDK.  Just to muddy things up further the 100.x SDK is asynchronous for faster startup times.  Objects like the AGSMap and the AGSLayers are only partially initialized at first (you can check this in debug during startup on the .loaded property of these objects).  Loading GIS data can be slooow, and to keep that from killing your startup time for big datasets the new SDK gives you more power to create objects before you load them with data.  One of the tripwires to tell the SDK it's time to load the data is to assign a map to the MapView.map object, which you do on line 18.  That means your created map is starting to lay claim to its AGSLayers first (probably loading your grey basemap layer first), and then getting first crack at the AGSLayers you assign to it on line 22.  The early bird gets the worm, and I think your created AGSMap gets the operationalLayers even if they're already assigned to mobileMapPackage.maps[0].  The part I can't advise you on is when the mobileMapPackage.maps[0] AGSMap starts to contend for those layers.  I can only say that in my app the MMPK object won the race instead and I couldn't load my layers in the mapView.map until I removed them from the MMPK's operationalLayers array. One more thought that crosses my mind is whether the spatial reference of your operational layers can play nice with web mercator of the light grey basemap.  That's probably not it, but bears mention as part of our mental checklist as GIS developers. I realize this is an old post I'm responding to, but I hope this helps in case others run across this problem. -Reed ... View more

Lucas,  I encountered your question while researching a similar problem.  I was able to use the following solution after upgrading to ArcGIS Pro version 2.12. In ArcGIS Pro's contents panel where the map and layers are listed ... right click the map's name and select "Properties" In the Map Properties dialog, select the "General" section on the left, => "Background Color" dropdown => No Color -Reed ... View more

We've had this problem as well in 10.2.5.  After migrating to 100.3 this problem thankfully went away, but it could be the result of some lingering file or layer references you need to set to nil. I follow the pattern of downloading a pregenerated .geodatabase in a zip file, overwriting the previous file during the unzip, and then registering it with the server for sync support.  During testing of my migrated app, 100.3 registration of the .geodatabase file with the server for sync support proved more finicky than 10.2.5, failing with an error about trying to write a read only file.   I found that my code had all sorts of leftover layer and file references into the previous .geodatabase file that needed to be set to nil, and then sync registration ran smoothly.  I also had to implement the singleton pattern for the .geodatabase so that load from file was only ever executed in one place rather than various modules.  That was how I had multiple references to the file - each module had its own module level variable rather than reusing a static shared instance.    The old 10.2.x Sdk didn't care about those variables so I never cleaned mine up.  It also didn't care if you had multiple loads from file for the .geodatabase (100.3 will let you run the load from file command more than once, but then the duplicated layers can't reach a loaded state).  I can't help but wonder if this problem you're having would have gone away for me back at 10.2.x had I implemented the singleton pattern and cleaned up my variables. ... View more

I had tried this approach before using the AGSPolylineBuilder and AGSPolygonBuilder without success, but just writing it straight out as an AGSPolyline and AGSPolygon constant did the trick, it's working now. Minor caveat, I'm working in a hybrid project with both swift and Objective-C modules.  In this case the translation to Objective-C was as follows: NSArray<AGSPoint *> * pointArray = [NSArray<AGSPoint*> arrayWithObjects: mapPoint, nil]; [self.sketchEditor replaceGeometry: [AGSPolyline polylineWithPoints:pointArray]]; Thanks Mark, the quest for a production release can now continue. -Reed ... View more

I have, and the respondToGeomChanged event is not triggered. The line after the call to insertVertexAfterSelectedVertexWithPoint, a debug po of the geometry shows nothing new:    po self.sketchEditor.geometry    AGSPolyline: [], sr: 3857 I have also tried calling clearGeometry right before insertVertexAfterSelectedVertexWithPoint just to be sure, but aside from triggering respondToGeomChanged in that case, there is no difference. The point passed to insertVertexAfterSelectedVertexWithPoint is confirmed having the same spatial reference as the target line layer. ... View more

I had the identical error when migrating an app from 10.2.5 to the 100.2 SDK.  Apparently a layer already owned by the operationalLayers of an AGSMap cannot be added to the operationalLayers of another AGSMap, and MMPKs provide layers only within a loaded AGSMap. I previously used two .geodatabase files, one for stable offline basemap data that is never synced, and another with more volatile operational layers that can be synced by many users at any time.  I encountered this error after migrating my offline basemap data to be loaded from a mobile map package.  I resolved the error by making my own array variable holding the layers and then clearing them from the AGSMobileMapPackage.maps[0].operationalLayers. I have requested that the SDK docs be updated to mention restrictions on access to layers owned by another AGSMap.  As an aside, I ran into this working with the iOS SDK, not the .Net SDK.  I suspect this will be common across platforms. I hope this helps anyone else with this problem. -Reed ... View more

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. ... View more

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. ... View more