I am using a hosted feature service that has a subtype field and several other fields whose domain depends on the subtype choice. Generally, data entry goes as expected as long as I don't change my mind about the subtype choice mid-edit. However, if I change the subtype choice in mid-edit, Collector does not clear the dependent fields, and does not present the domain choices that correspond to the new subtype choice I've made. I have to close the record and then re-open it in order to have the correct domains presented when I edit the subtype-dependent fields.
The funny thing is that the popups within the AGOL webmap that the Collector project is based on work perfectly...which is to say that as soon as I change a subtype choice, the other dependent fields go blank, and their domain choices correspond to the current subtype choice.
Is this a limitation of Collector, or am I being stupid about something? I'm running Collector 10.4.2 on Android 5.1.
Thanks...
Hi Carl,
Thank you for that explanation. I have a few questions for you:
1. Could you please elaborate on what you mean by mid-edit? i.e. You selected a feature > started editing it > then changed the subtype field. Is that correct?
2. I am assuming that you're using the subtype field for the symbology with the unique value renderer. Is that correct?
3. How many subtypes do you have?
4. When you configured each subtype prior to publishing, are each of the defaults/domains unique for each subtype template?
5. When you say that you have to close the record for the correct domains to appear, do you mean that you have to stop editing and start again for the same feature?
What you might be running into is that, in general regarding the subtype/domain behavior on Android, with the current 10.4.2 version we had addressed a critical software bug at 10.4.1 regarding the behavior when changing subtypes and domains that are based off the layer symbology and it clearing out all existing values from all fields without warning. Although we had successfully addressed that issue, it created additional issues with the messaging that would ordinarily be received when editing.
For example, if I am changing from subtype1 to subtype2, where subtype2 has completely different/unique default values and domains applied to it, ordinarily you'd be prompted to either 'Keep existing values' or 'Reset default values'. However that message is not working in Android 10.4.2. We are working to address further subtype/domain issues that should be resolved in our next update for 10.4.3.
Thank you.
-Kevin
Thanks for your speedy reply, Kevin.
So, returning to item 4...When I went back and set a default value for each of the domains and republished the service, I did observe the behavior that I expected to see...which is to say that I received the "Reset to default/Keep current values" message each time that I changed the subtype, and all domains refreshed to correspond to the current subtype. I'd rather have those fields repopulate to a NULL awaiting a valid choice from the domain, but I can live with the default value.
So, my mistake for not setting a default value for each of the domains. Problem solved, crisis averted!
Thanks...
cB
@Kevin, Thanks for the information, I just ran into this. The message "Reset to default/Keep current values" pops up in ArcMap but doesn't in collector or the web map in portal. Also once the subtype is changed it doesn't want to change back to the original value. Any idea when the 10.4.3 update will be out?
I am attempting to use collector for a sign maintenance application. The subtypes are for the class of sign ,Regulatory, Warning, Guide, and Other. The domains are the MUTCD codes for the appropriate class. When service is required the subtype is changed to "Service", and hopefully the values would be unchanged. I went this way because it is an easy way so I identify the service class as the symbology changes, and it also whittles the number of MUTCD codes down to a manageable level in each subtype. Once the service is complete the subtype would be changed back to the appropriate value. Works great in ArcMap, but it's not real useable in the field!
If the update will be awhile I may have to rethink the issue.
Thanks,
Bill