Improve Android Load Speeds when using Contingent Values

[NoMonkey]

Hi, 

We recently created a FieldMaps map for recording bird observations on reserves. For our surveyors it was key that we limited the data they could see to make data entry as quick as possible. To do this, we used contingent values to limit which observations got assigned to which datasets available to that person and also if you had a certain bird count unit then this limited the selectable behaviours the bird was exhibiting that you could pick (e.g. a 'recently fledged' bird shouldn`t have a behaviour of 'hunting' available to it). 

We piloted it and it went well. Looking to release it across the ~8,000 strong staff and volunteers in  our organisation and there was a FieldMaps update which changed the form load time from ~1 second to ~15 seconds. With testing 25.3.1 we're now seeing form load times of ~25 seconds. The ~15 seconds increase has made the map unusable for surveying.   It is only affecting Android not Apple, but we are very much more an Android organisation. It doesn`t matter whether you're connected or not either. 

There's a logged bug https://support.esri.com/en-us/bug/there-is-a-performance-issue-when-loading-a-long-list-o-bug-00015... and we've logged one here:  https://earlyadopter.esri.com/project/forum/thread.html?cap=e55aef78a95143e7a5fb72583c20e4d4&forid={...  and one logged with the support desk. 

However, we do really need to get our work out so have started thinking about removing the contingent values which will lower user experience and data quality and try and change the process elsewhere to cater for it. However,  all suggested ideas seems unpalatable, forcing the user to revisit their work after they've captured it or we just let lower quality data into our database and clean it afterwards. 

Any suggestions about how we can replace the contingent values and ensure data is validated when collecting would be great....

[MErikReedAugusta]

If you're already in workaround territory, we're currently using Subtypes & differentiated domains to handle this, since we're currently unable to deploy Contingent Values in our data, yet.

We are only able to do 1 level of control with that, however, and I believe Contingent Values can nest within each other.  So depending on how far down the rabbit hole in successive Contingent Value lists we're talking, I suspect this might not be as workable for you.

It might help to know what your Contingent Value lists look like, in brief, to try to figure out workarounds.