The purpose is to get the current settings in the ODK Collect app so that the external app can easily interact with the ODK Collect app ensured that both apps point to the same server & ODK Aggregate account.
Any errors that might have been encountered due to different server settings can be easily prevented and communicated to the user.
IMPLEMENTATION
Any different thoughts & improvements on this are welcome
I am thinking of calling a service with the request, the service will then send out a broadcast with the server type selected & all server settings.
I am not sure if we need this?
For a bit more security, the intent filter action for responses can be provided by the external app thus dynamic and only known by the external app
This feels odd to me, can you say more about the scenario you are trying to address? Can the external app possibly use one of the existing mechanisms for changing collect settings (https://docs.opendatakit.org/collect-import-export/)? Alternately, can the settings sharing that currently exists be expanded to share via intent?
This feels odd to me, can you say more about the scenario you are trying to address?
Sorry, tried to make it brief. Not too long I hope
@LN In a case where the end-users are using ODK Collect to fill in forms from different organisations, they end up having multiple settings that they use. Therefore, if there is an external app that they also use which kinda wraps around ODK Collect, these settings will change frequently and any operations on the external app interacting with ODK Collect will end up failing. If the external app was able to confirm/verify the settings on ODK Collect before performing operations such as downloading forms & uploading forms, it would be able to warn the user to change the settings for them to perform the operations.
Example, John Doe performs data collection work for 3 organisations. All organisations require him to use ODK Collect, but each organisation has its own deployment. Therefore the settings for ODK Collect provided by the 3 organisations are different. Organisation B has a mobile app that wraps around ODK Collect to collect other information and surveys are done using ODK Collect. John Doe tends to switch between the 3 organisations depending on the work available & survey requirements. He might end up forgetting to change the settings when switching from organisation C's work to organisation B's work. Organisation B's mobile app tends to fail downloading form in such a case without any error message. Submitting forms sometimes also fails to wrong settings.
The external app needs to verify settings every time before performing form downloads & uploads which need the URL, username, password & endpoints to be correctly set. The external app also performs some of these functions without switching to the ODK Collect app.
Alternately, can the settings sharing that currently exists be expanded to share via intent?
Seems like you have an idea here . How would this fit in the scenario above?
Can the external app manage the server selection? It could either allow free text or have a dropdown for different profiles. Then it could write the collect.settings file on change. When Collect was opened, the settings would be read in.
Alternately, can you specify the submission URL in the form (http://xlsform.org/#encrypted -- it's not just for encryption) and turn auto-send on in Collect? That way the form will just be submitted to the correct destination after filling and the user will be prompted for credentials if needed. That way the user doesn't have to think about organizations.
It would be helpful to understand more about why this app is needed and what it does to figure out the best way to enable the functionality in a generally-useful way in Collect.
The collect.settings idea works when Collect is launched directly but it's not reloaded when specific activities are launched through external intents.
The current proposed direction is to add optional credential extras to the newly-added download service and to an upcoming submission intent. This will allow external app to specify credentials if needed without changing the state of Collect.
So far we haven't come up with any dangers or downsides to that approach. Please share any concerns or alternative ideas you may have!
One potential danger with the intents approach is that you can now more easily overwrite blank forms with the same ID. Once you do that, you can't open any saved forms that use that blank forms. We could add a pref in Collect to see if we want to allow external apps to do that.
. How would this fit in the scenario above?