As an example, imagine a form that has a
body::intent on a group like so (from the example in the docs):
org.mycompany.myapp(my_text='Some text', uuid=/myform/meta/instanceID)
This will send an intent to an external app with the extras "my_text" set to "Some text" and "uuid" set to the value of
/myform/meta/instanceID. The current values of sub-fields in the group will also be sent in the extras:
The external app is launched with the parameters that are defined in the intent string plus the values of all the sub-fields that are either text, decimal, integer, or binary (filename is sent). Any other sub-field is invisible to the external app.
This means that if I had a field named
foo with the value
bar, I'd also set an extra "foo" to "bar". However, if I have field named
uuid we end up with a clash: the "uuid" extra will now be set to the field "uuid" rather than
/myform/meta/instanceID as Collect overrides the parameters set in
body::intent if they clash with field names.
There is a risk of accidentally introducing these clashes for any form/external app, but it's especially problematic if the external app's interface lets you specify which return values you want. Imagine an external app that returns "name" and/or "age". It might make sense to design an interface that allows us to pass in true/false for the values we want back (or specify the return names). For instance:
The danger here would be that if the group contains a field named "name" (which would be likely), we'd end up overriding "true" with the value of the field.
For my use case, I don't need to pass current field values into the external app, but I imagine that happening by default probably very useful for a lot of folks. It would however make sense to me for this to work the other way around: Collect sets extras for the fields in the group, but parameters specified in
body::intent would override them.