Is anyone else experiencing extreme frustration with implementing this new version of collector (v18.1.0 IOS) into production? I am literally pulling my hair out here. So many random and unexplained glitches...a few of which are listed below...
About the only thing that works as promised in this latest bug ridden headache is the labels...Congrats ESRI, you've finally gotten something that should have been in place from the beginning, to work...at the expense of pretty much everything else it appears.
Thoughts, suggestions, rants, ideas...all welcome!
Jan 28 2019 update:
After much anguish, I have a working collector webmap that now downloads and seems to sync with no issues. I haven't done extensive data collection and syncing yet...ie two to three hundred new spatial elements with attribution, related tables, attachments etc to sync so that may be an issue yet...will see.
The cause of no edit symbol when opening in collector turned out to be not having at least one of the editable layers turned on when the webmap was saved...no idea why but the map simply won't load into collector as editable (even in online mode) without this little detail. I have been in the habit of saving collector maps with only a basemap and read only polygon boundaries layer turned on so the user does not have to wait for all layers in map to draw before picking a work area, resolution and downloading...this was an issue in classic collector. Fortunately one only needs a single editable layer turned on to get around this...but still.
Next issue and this is the big stinker...download failed...with no reason. After a bit of research I learned how to turn the developer mode on in collector to capture error messages. This led to the recurring message of "The item to be created already exists in the database." or something to that effect. Amongst the some 21 data collection feature layers in this particular collector map, two of them are feature layers with 4 related tables attached to each by a unique numeric ID number at the parent level. Both of these parent datasets and the child tables within are controlled heavily with field domains and yes...there are some field names in the child tables that are identical to the parent table fields...using the same domain names. I finally deduced after some reading on here and deciphering the developer log from collector that this fantastic new collector will not allow the creation of child tables with identical field names as the parent. I still have classic collector installed on a couple of androids, and they have no problem downloading and editing these two datasets, so this is clearly something that is only applicable to the new collector. Anyways as you can probably figure by now, I had to purge my related tables from the two datasets, delete the relationships and rename all fields that were duplicated from parent table to a unique field name, then recreate the relationships to parent, reload data and republish. In theory one only has to do this where there are common domains involved in both fields...I can't verify this though as I was taking no chances at this point and renamed all the related table fields to be unique. I did however try to edit the domain for one field on both datasets after I had the map downloading and working properly....and immediately lost the ability to download again...same duplicate object message in the log. Had to go back to arcgis, make my minor edits the domain values, republish those two layers and redo all the popups, field ordering, formatting etc. so note to self - do not to mess with domains on layers that are already saved into existing collector maps!
I have not gotten into the map areas feature on my latest working version...sort of scared to now...it's working and I would like to keep it that way!
And Yes, the labels still work...yay, we finally have labels on our collector maps! Although I did discover that the new scripting language for AGOL labels still cannot create a nice, neat stacked label for collector...just one line labels for now I guess. Really like the side loading of basemap tpk's onto the ipads and the fact that they cannot be deleted in collector accidentally. We can now download our work area at world resolution very efficiently and switch to one of the side loaded high res basemaps after opening in collector...makes for a minimal download footprint that will be beneficial when wifi connectivity is less than par. The opportunity to view sync edits before syncing is pretty cool...although with a hundred or more edits in a day, I can't see anyone really going through that list of pending syncs too seriously.
That's all I've got for now...happy collecting!
I'm having a similar issue with the map failing to download. It turns out that i had two layers based on the same feature service to show different things (different names, symbologies, queries, etc). Removing one of them solved the problem. It's just frustrating considering the "Classic" Collector didn't have this issue.
Hi Kyle,
Thanks for posting this! I've been pulling my hair out about my offline areas failing to download. As soon as I went into my web map and removed the duplicate layers, it downloaded fine.
Kylie Donia is there a specific reason this causes an offline area to fail to download? In Classic this is not a problem. It's useful to have layers added to a web map multiple times - for example, if I have drainage structures I want to see them all, but then I can also add a copy of this layer to draw on top with a different symbology to show which have been inspected in this calendar year.
Is this going to be fixed?
Thanks!
Erica
Hi Erica -- Although in Classic the map still downloads, it doesn't behave as expected. You'll only get one copy of the layer offline due to how offline maps work. The workaround is to use hosted feature layer views: You can take multiple hosted feature layer views that are based on that same layer offline. Here is a blog that shows this workflow: Take the same layer offline twice in Collector using feature layer views
Hi Kylie,
Thanks for the workaround. For some projects, Views work well, but for others we have instances where data is downloaded, QA/QC'd and re-published at regular intervals as data is collected. Since it isn't possible to overwrite a hosted feature layer that has a View created from it, using a View isn't always ideal.
In the case I described above, we have a regular QA/QC procedure where data is downloaded/republished, which is why being able to add duplicate copies of a layer into a web map is nice.