1. What is the general goal of the feature?
File question type in XLSform is very useful as it allows you to attach any file type to an ODK form.
The default behaviour is to open a chooser and allow the user to select a file from their device.
I propose a new attribute similar to
media::image which allows form to predefine the target file
Further to this, an
appearance option to autodelete the target file.
This new feature would allow the following behaviours
- choose a file and attach it to the form [default behaviour]
- choose a file and attach it to the form, deleting the original
- attach a pre-specified file to the form
- attach a pre-specified file to the form, deleting the original
2. What are some example use cases for this feature?
Behaviour (1) is default behaviour
Behaviour (2) use case
- I use an external app to make an audio-recording of an interview with a study participant. The original file is unencrypted.
- ODK collect add the file to a form, deleting the original and encrypting the attached file
Behaviour (3) use case
I have an app running in the background which captures the current temperature and humidity and refreshes a single line file
/root/sdcard/foo.txtwith text such as
When I want to take a reading from my sensor, I open an ODK form and press the
attach filebutton. ODK pulls the current version of
/root/sdcard/foo.txtand adds it to the form.
This behaviour allows provision for an ad hoc framework that facilitates direct collection of data from third party apps and sensors which have no in-built
intent.actionstructure, but which do have predictable behaviours such as saving a file to a specific path
Behaviour (4) use case
I have a USB fingerprint reader which exports a fingerprint template to file
/storage/emulated/0/FingerData/ANSItemplate.ansi. This filename does not change between exports. Each time the scanner is used the file is overwritten with data from the last scanned fingerprint.
I use an ODK
filetype question to pull the template file in to a form, deleting the original file in the process.
By removing the original, we ensure that there is no chance that a previously saved fingerprint could accidentally be added to someone else's form (i.e. due to scanner failing to overwrite a previous file.
The overall benefit of these changes are that there is increased flexibility in how files from other sources can be attached to ODK forms. The fingerprint reader is a good example of why this is necessary. There are many fingerprint readers on the market but most come with simple example apps as part of the SDKs, but which would require extended coding of apps to get them to talk to ODK. We have been asked by many groups how to use fingerprint readers, but there's no single answer to this as it is device specific. Agencies such as Simprints offer solutions but these require direct collaboration with the agency as well as use of specific devices so there's no easy to use solution that non-specialists can affordably set up. The simplicity of the proposed behaviour (4) is that it allows users to implement custom interactions with third party apps, sensors and bluetooth peripherals with absolutely minimal specialist coding skills and no need to involve app developers.
3. What can you contribute to making this feature a reality?**
- Very happy to field test.