The Mobile Get Workflow Inputs and Drop Down List behave differently than Web and Sandbox
I've noticed that the Workflow Sandbox and Web have nicer behavior for drop down lists and database context values than Mobile.
These should all do the same thing, but, currently, good accurate debugging impossible in some cases and Sandbox is much less useful.
Sandbox and Web will automatically provide a "Select..." or Blank option to a drop down list, along with what I provide it from a coded value domain with a subworkflow, where Mobile only provides what I populate.
How can I utilize this behavior in Mobile so my drop down list has a "default" option that properly binds NULL values from the database, for example in an Edit Feature override workflow?
-
Hi Alex,
Thank you for your post. There are some differences to be expected, as Sandbox & Web are both running on the Javascript/Typescript API, whereas Mobile uses .NET. We have made many efforts to try make the experience as similar as possible between the two, but due to the coding difference, and the fact that Web is browser-based whereas Mobile makes use of the 3 native OS implementations, perfect harmony between the two isn't fully possible.
For debugging Workflows in Mobile, are you familiar with the debugger built into the log viewer? It's a very powerful tool which allows you to inspect inputs & outputs between activities. You can find it in the Settings panel, at the bottom ('Log Viewer' blue text). On Windows, F12 is a keyboard shortcut to open it immediately. Simply enable debugging logs, run your Workflow, and then you can inspect each activity as it fires. You'll see two instances of each activity: one for the attempt to fire it (which will have inputs but not outputs), and a second if the activity is successful (with both inputs and outputs).
Doing a little testing with the drop down list in Mobile, if I don't specify a default, I'm seeing the same blank option as what Web provides:
Whereas if I make use of the selected index property in Workflow Designer:
I indeed get one of my populated options:
If again I don't pre-select an option, and use the Placeholder text property in Workflow Designer:
That too shows up in Mobile:
One last piece - we've just recently added support for a null option with our out of the box add/edit tools, which will be included in our upcoming 5.22 release, as described in this post:
https://community.vertigis.com/hc/en-us/community/posts/8140909746066-Field-Domain-null-option
I hope that helps,
Phil MacIntyre
0 -
Oh, thank you Phil!
That is very helpful, since I hadn't clicked on the filters in the log viewer to turn on debug logs. That also makes sense why they can not fully replicate each other's behavior.
I will try some fresh drop down lists to try and replicate that default behavior, not sure where mine is going wrong.
1 -
Something wrong is happening.
Even with fresh DDL and defining options manually or with the coded value domain, I don't get the blank option.
Coded value domain
Manual configuration
My DDL configuration
The subworkflow
The Set Form Element Items configuration.
Same behavior with Reset set to true or false. I wondered if the blank option was being overwritten if Reset was true, but that does not seem to be the case.
Any other ideas?
0 -
Hi Alex,
At a quick glance, I can at least get blank options with a manual population approach:
Simply by blanking the label for the option. Populating it via subworkflow dynamically harvesting values from a feature layer, I can get the blanks there too:
So it's definitely possible, we're probably just approaching it from different angles. Those screenshots are from apps opened in our 5.21 store build version of Go. Is that what you're using as well?
As well, how do you have your query or get layer activities configured to target that specific layer you're working with?Cheers,
Phil
0 -
Yes, I am using build version 5.21.0.360
Here is my Get Coded Value Domain activity configuration
The feature layer URL is passed as an input argument to the workflow.
0 -
Another approach I had tried is to use the Add Item activity but got an error about the Coded Value Domain being read-only
(Some more details that I posted here: https://community.vertigis.com/hc/en-us/community/posts/4416579556370/comments/9978706318994)
The problem is that the Add Items and Add Item activities expect a System.Collections.IList, but I can not figure out how to initialize one and create an empty collection in Workflow.
0 -
Hi again Alex,
Sorry for the delay, I'm just tied up with our next release. I'll try to find some time next week to dig into this further. If you need assistance more quickly, our Support team may be able to provide you with some guidance.
Phil
0 -
Alex St. John Maybe you solved this already, but here's a solution anyway:
Use a Create Value with expression =$getCodedValueDomain1.domain.codedValues
Using Add Item, add a new item at index 0 to that value, for instance ={ "name": "EMPTY", "code": null }
Create items using Get Form Element Items From Collection, setting label to name, and value to code
0 -
Berend, thank you, but that is causing the same errors on the Add Item activity.
Collection =$value1
Collection =$value1.result
Is there a different way to call the value $value1 to make it valid input as a collection for Add Item?
0 -
Sorry, I see it now. What works in mobile is to do it the other way around, i.e. create an array with the empty value, and add all coded values to that:
- Create Value (value1) with expression: =[{"code":"", "name":"EMPTY"}]
- For Each with items: =$getCodedValueDomain1.domain.codedValues
- Inside the For Each an Add Item with collection: =$value1.result and item: ={"code":$forEach1.item.code, "name":$forEach1.item.name}
- Use =$value1.result in the Get Form Elements from Collection
(I also tried to use Add Items for performance reasons, but couldn't get that to work)
0 -
Same on my side, the Add Items activity failed with the same error "collection is read-only".
But this sequence seems to be working and it is correctly binding data between the form and database.
This should only apply to drop down lists that I have that do not have default database values, but hopefully this bug can work itself out, unless others start to notice similar behavior.
0
Du måste logga in om du vill lämna en kommentar.
Kommentarer
11 kommentarer