AnsweredAssumed Answered

Collector iOS bug - Related Tables

Question asked by jthoene on May 13, 2015
Latest reply on Jun 9, 2015 by SPrindle-esristaff

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:

 

<URL>/FeatureLayer1/FeatureServer/0

<URL>/FeatureLayer1/FeatureServer/1

<URL>/FeatureLayer2/FeatureServer/0

<URL>/FeatureLayer2/FeatureServer/1

 

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.

Outcomes