Collect v1.7.0
We use a custom Android app to launch ODK Collect. We have the user enter his username and password in our app, and then we save this along with the correct url and some other project-default settings to a collect.settings file, which is then automatically loaded by ODK Collect the next time it is launched (existing Collect functionality).
This greatly reduces the complexity of getting Collect set up for our (mostly non-technical) users.
Each time an update is done to ODK Collect (now monthly, which is great!) we have to check that no changes have been made to the settings mechanism which affects the serialization/structure of that file.
Now that JSON settings are supported (#781), would it be possible to add functionality to automatically import settings from a JSON file as well?
Perhaps collect.settings.json, to distinguish from serialized collect.settings files?
This will mean that we can be confident that our settings-mechanism is unlikely to break with future Collect releases, and will make it easy for others wanting to implement a similar use-case.
This seems like a good idea!
@acawood777 if you have capacity for it, we would welcome a pull request. I think a lot should be reusable from #781 with perhaps some refactoring.
One thing that we punted on and that we should probably review is versioning the settings json in some way so that we can ensure continued compatibility as the settings change. Additionally, for the QR code, only non-default values are included in the json. Having a version number would make it more easily possible to change defaults but still have things behave as expected. This should probably be filed as a separate issue.
@shobhitagarwal1612 worked on the QR code feature and will likely have some good ideas to share!
@lognaturel I'm allocating a team member (@jovaee) to this to have a look.
Would all the new JSON code be found in this commit?
@shobhitagarwal1612 Do you have any comments/pointers as we climb into this?
@lognaturel On the version number, I'm assuming you're referring to this comment?
Do I understand correctly - your proposal was that the Collect version number of the Collect instance generating the QR code should be included in the JSON for the QR code?
Then the Collect instance loading the settings from JSON can check that it is a compatible version (e.g. in case there were breaking changes implemented at a certain point in time)?
No promises on implementing the version number, but will take a look at it. (And agree that it should probably be a new issue).
Would all the new JSON code be found in this commit?
Yes, (check out this piece of code for importing settings from json)
Basically, the format of the json file should be something like this:
{
"admin" : {
PREFERENCE_KEY1 : value1,
PREFERENCE_KEY2 : value2
} ,
"general" : {
PREFERENCE_KEY3 : value3,
PREFERENCE_KEY4 : value4
}
}
We are planning to give the JSON file preference over the normal collect.settings file in the case that both are present. Any comment on this?
@shobhitagarwal1612 Thanks for the help
@jovaee I would like to know why are you planning to additionally import from a json file as well given that collect.settings file already exists. Is there a specific purpose?
@shobhitagarwal1612 See the Background and Problem description in my first post above. We're generating our own settings files (not generated in Collect).
The JSON route will make our implementation cleaner and more robust than using the serialisation route at present.
We particularly prefer JSON for the fact that field order doesn't matter, whereas for a serialised object this is not always the case.
@acawood777 I do feel that the problem that you are facing can be solved by adding a version check while importing the settings file. But if you think that using JSON file would be better for the longer term benefits then that's great too.
@lognaturel @shobhitagarwal1612
@jovaee has submitted a PR for this :thumbsup:
Closed in #1125
Most helpful comment
@shobhitagarwal1612 See the Background and Problem description in my first post above. We're generating our own settings files (not generated in Collect).
The JSON route will make our implementation cleaner and more robust than using the serialisation route at present.
We particularly prefer JSON for the fact that field order doesn't matter, whereas for a serialised object this is not always the case.