Extended use features for xlsform "File" type question

Ideas
1

1. What is the general goal of the feature?

The 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

  1. choose a file and attach it to the form [default behaviour]
  2. choose a file and attach it to the form, deleting the original
  3. attach a pre-specified file to the form
  4. 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.txt with text such as 2019-09-12\t37.2\t76.5

  • When I want to take a reading from my sensor, I open an ODK form and press the attach file button. ODK pulls the current version of /root/sdcard/foo.txt and 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.action structure, 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 file type 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.
2

Just FYI that we have to be a bit careful about (ab?)using appearances for enabling/disabling distinct functionality. In principle, appearances are meant to be optional; that is, if a client doesn't support a particular appearance option then it can still provide a base widget to capture the necessary data (ie 'equivalent functionality'). For example, Enketo supports several select_one/select_multiple appearances that Collect does not, Collect supports an optional 'bearing' appear on decimal to bring up a compass which Enketo lacks (but you can still enter a compass bearing), etc. See https://xlsform.org/en/ref-table/ for full list.

So triggering an auto-delete based on a optionally supported appearance may or may not be appropriate... :thinking: eg if the form indicates I should (may? must? preferably?...) autodelete the file, but my client doesn't/cant support that, what do I do?

3

mmm, interesting and I see the problem.

So a lot of the reason to enable this type of functionality is to support interaction between ODK Collect and the Android system, which is very black box to most people. Deleting a file on a PC is pretty easy to do for anyone, but on device requires all sorts of swipes and sometimes moving between several apps to achieve it.

In my mind that suggests that there could be grounds to introduce a new set of android specific controls [i.e. a new optional column on survey sheet] for a limited set of low level interactions with the operating system. Would creating a new column (that enketo etc could just ignore) have the same issues as including these options in the appearance column?

4

There are certainly other mechanisms - besides appearances - that can be used to effectively convey additional (optional?) ‘settings’ to a control widget. For example, the max-pixels=1024 parameter for images/photos, which gets expressed in the control’s associated binding in an XForm. It may be in this case defining a further explicit new such (Boolean) parameter, say delete=yes, may be more appropriate than defining a new (and optionally supported?) appearance. Thoughts @LN?

To be fair, none of this is cut-n-dry, and the distinction between what constitutes an appearance vs binding parameter vs even a binding type for that matter (eg barcode vs string) is rather open to debate. Hence my excessive use of the word “may”... :slightly_smiling_face:. But I usually use the benchmark that I should be able to ignore an appearance but still be able to acquire equivalent data that in the end is indistinguishable. Deleting a file or not falls into a bit of a grey area ‘cause its more a side-effect (the acquired data - the file - remains the same)...