Form Drop Down List population - Options Workflow run on demand for user (after initial form load)?
I have a form with several drop down lists that query a REST endpoint to populate with coded domain values. For example,
I found that the performance suffers badly on mobile devices. So, I started moving to using the manual configuration for the drop down lists that are common to all of our clients. For example,
There are a two drop down lists remaining that contain client-specific values: street name and cross street name for locating purposes.
The performance on mobile is improved with using manual configuration, and is acceptable for now since I only have to create the workflow once. I still see a significant performance hit when loading the form to populate those last two via REST query.
Are there recommendations for boosting performance of Mobile and Workflow?
Is there a way that I can trigger the REST query once the section has been expanded, like from being collapsed? Can we break out the "load form" behavior is some way like this to save some load time until the user wants the drop down list?
-
There are probably ways to improve your performance here, make smaller queries, more performant services, process just the data you need type things, but the Coded Values are already fairly slim operations.
Something that will probably help you would be to preprocess your most resource-expensive lists in a separate WF on application load, then place the list into the app state with Set App Data.
I recommend stopping just short of the form element items for this, because if you keep them in the app state then you are going to be reusing the same items each time the workflow runs which might preserve things like checked items that you don't want. So create the collection, place it in the app, then when the actual workflow you need to speed up runs it can Get App Data for the collection and just run the Create Element Items on it.
If the data being queried (or domains) for your element lists needs to be kept up-to-date, you'll need to re-run your background collection generator workflow on a timed loop. This is of no concern if the data doesn't update much.
Nearly forgot to mention: only hold onto the data you need in the app state! Be sure not to keep, say, 10000 road geometries in there. It'd slow down the app.
0 -
I will give the App Data method a try soon. Thank you!
0 -
Zack Robison The Set and Get Application Data method is showing some improvement for loading form behavior. The Studio Go desktop app showed full improvement and the form populates in an instant.
On any mobile device, I am still getting a lot of grey-out-blinking and the "loading wheel", making it unclear to the user when the form is finished loading and ready for input. I can watch it populate field by field, pretty slowly, whether it is a value fetched from query or setting a default value.
For reference,
I use For Each to loop through $getApplicationData.value, and then Add Item to a collection with dictionary syntax
={"name":$forEach.item.name, "code":$forEach.item.code}
Then Get Form Element Items From Collection and Set Form Element Items finish the dropdown population.
Note that the collection is initialized with Create Value as a list of dictionaries =[{"name":"", "code":null}] or =[], depending on whether the dropdown has a default value or not.
1 -
Glad to hear it Alex St. John!
Edit: Oh no, not so glad about the update.
0 -
Alex, I'm curious whether you know what the resource usage on the mobile device is. I'm also curious whether you are able to view console logs to indicate where the slowdowns might be (use timestamps on the logged .debugger messages). It the whole app slow, or is it just one particular WF?
Anyway, it sounds like you have some processing that can be done before Set App Data instead of after. I'd place the entire collection in the app state, so you don't need to run those ForEach loops more than one time for each collection.
I'd also take a careful look at what data your WF is holding on to that you don't need. Make sure you don't query superfluous feature geometries and attributes, delete large objects (feature sets, images, etc) when you're done using them, and if possible simplify the map itself which uses a ton of resources.
On top of that, I'm wondering why you're creating that collection this way. It may be more efficient to place the CV domain itself in app state and run Get Elmnt Items from CV Domain, though it would be more space efficient for you to keep using a collection.
If you want to keep using the collection, it may be a little bit faster (or may not, I haven't run tests but assume there's avoidable overhead in WF activities) to use the vanilla Javascript Array.map() method. The expression might be a lot for some folks so there's a judgement call to be made here, but something like $getCvDomain.domain.map( ([k,v]) => { return {name: k, code:v} } ).
0 -
Thank you for the follow-up Zack!
I only see activities like that for Get Form Element Items From Collection or Features. Am I missing something?The "Get Elmnt Items from CV Domain" activity would get around the need to create a collection, right?
Is the setback here that we can't set the collection directly to the drop down list options and must go item-by-item?
0 -
I think I understand better now and am seeing significant boost when I do not use the For Each on each drop down list element.
Using the Get Form Element Items From Collection directly from the app state data cuts down a lot of load for the form - very nice!
The app takes ~> 15 seconds to load, but that is a much better problem to have than the form taking about the same time.
0
Comments
7 comments