I've come upon what I believe is a bug in the 10.3 iOS Collector App. Background on my project - I'm setting up a field application where I have a GDB with related feature classes and tables that will be collected in the field, and I have another GDB full of background 'static' data (project boundary, roads, NHD, etc.) If I publish both databases to AGO as one feature layer and service definition, everything is A-OK. I then decided that I want my 'static' data as its own feature layer and service definition so I can change the project boundary or if another layer is desired, I don't have to redo the entire map. Here's where the problem begins:
Looking at my map on the web, the relates are fine, as well as if I look at the map through an Android OS. When I look at and try to add data through the iOS app, the relates are pointing to the wrong feature class or table. I believe I know why:
Looking at the URLs for my feature layers, I think that iOS is only looking at the array number and not at the feature layer part of the URL. For example, if I have two feature layers with two features in my map:
If FeatureLayer1/0 is related to FeatureLayer1/1, iOS will show FeatureLayer1/0 being related to FeatureLayer2/1. This is not the case in the Android OS or through the web map.
Anyone else run into this problem? It really messes up the efficiency you should have from using multiple feature layers in a map.
I am having the same issue, I created a map that contains features from two different services, one service has all of my editable features and one of those features has three related tables. The other service is simply base data that is just used for reference. If I open the map in collector all of the related tables work fine as long as I am online. When I download the map 2 of the three related tables show up but the third is replaced with a feature from my other service. I tested the map out on an android device and everything works great but on our ipads the third related table is always replaced.
I've found a workaround for this until the bug is fixed. For my map, I'm using a collection database and a background database. If I add a bunch of 'dummy' feature classes to the background database and publish the service with those dummy feature classes at the top of the TOC, those dummy feature classes are assigned the first numbers in the feature service. If you have enough of the dummy feature classes such that the first background layer you want has a number higher than those in the collection database, you can remove the dummy datasets from your map, leaving a unique number for each of your layers within the map. Relates work then.
Any thoughts from Esri on fixing this bug?
Thank you for posting this issue as well as posting the workaround you've devised to get your related tables working in Collector on iOS. I was unable to find an existing bug for this behavior, would you be able to contact Esri Support Services to get one logged? Please send me a message if you need assistance opening a case with support.