ODK Collect Widget Functionality

Greetings,

We are using ODK Collect and Aggregate in conjunction with two external
apps to attach numerous files to a form as a user goes through it. To do
this, we were planning to place instance attributes of type binary in the
form (initially unfilled/blank), modify the .../odk/.cache save file upon
attachment to wrap the correct file name, and make sure that the physical
files are moved to the correct instance directory (similar to how I assume
the camera widget operates).

We were wondering if there is a standardized way for external apps to make
these small, widget updates/insertions to the cached save file, and if so
where in the Collect source code or the JavaRosa source code is a good
reference for this process so that we could do something similar.

I will continue to look through the Collect source, but any help or
guidance regarding this would be greatly appreciated.

Thank you for your time,
Isaac

Your terminology is somewhat confusing.

The binary data type (where binary data is stored embedded in the XML) is
not supported within ODK Collect. To keep the size of the XML file small,
binary data should be stored as file attachments (what you are talking
about doing).

The standard way to do this would be with an upload control with a
mediatype attribute.

The system currently provides controls to handle these mediatype categories:

image/*
audio/*
video/*
osm/*

What media type do you need? (e.g., text/* or application/* or something
else??)

If you want to add support for text/* or application/* (e.g.,
application/octet-stream -- arbitrary files), this requires a modification
to javarosa to define a new control type.

Then you would be able to use that control type within ODK Collect to
configure a widget that handles that media type.

··· ================= The .cache file is only written, and is not read unless ODK Collect force closes (crashes).

On Thu, Mar 24, 2016 at 2:16 PM, Isaac Long isaacglong@gmail.com wrote:

Greetings,

We are using ODK Collect and Aggregate in conjunction with two external
apps to attach numerous files to a form as a user goes through it. To do
this, we were planning to place instance attributes of type binary in the
form (initially unfilled/blank), modify the .../odk/.cache save file upon
attachment to wrap the correct file name, and make sure that the physical
files are moved to the correct instance directory (similar to how I assume
the camera widget operates).

We were wondering if there is a standardized way for external apps to make
these small, widget updates/insertions to the cached save file, and if so
where in the Collect source code or the JavaRosa source code is a good
reference for this process so that we could do something similar.

I will continue to look through the Collect source, but any help or
guidance regarding this would be greatly appreciated.

Thank you for your time,
Isaac

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

Sorry for the confusing terminology, I am somewhat new to ODK. I will try
to be more explicit.

We are attempting to attach two text files (files which are the ‘output’ of
the two external applications that are opened while filling out our form).

We first investigated the standard way of doing the file upload as you
suggest, with the upload element and media type attribute. However, due to
the nature of our project (which is admittedly a bit niche), we need the
files to be attached:

a) automatically, without form-user interaction, and ideally without the
user seeing the output

b) with file types other than image, audio, video, osm

I would be happy to look into what it takes to add support for a new
control type in javarosa and develop a widget for the project that
satisfies the above constraints, this is definitely the most complete
solution. Do you have any additional information on how we could go about
doing this/starting this, and approximately how long it would take to do?

Keeping in mind that we would like to get something working (perhaps not
elegant, but functional) relatively soon, what would you suggest is the
best way to do the following (which is what we are trying to do):

user begins a form —> fills out a few questions —> form launches external
app —> app generates a text file and puts it into instance dir —> user
returns to form and fills out a few questions —> form launches another
external app that puts another output file into the instance dir —> user
returns and fills out a few questions —> form is ended and saved —> upload
to Aggregate, which should include the output files, let’s assume they are
.txt.

(As of now we have a work-around where we just hardcode file names into the
form, e.g.

 <instance>

      ...

      <processedDataFile>processed_data.txt</processedDataFile>

...

obviously not ideal or robust).

I appreciate any help/guidance Mitch!

Thanks,

Isaac

··· On Friday, March 25, 2016 at 10:33:46 AM UTC-7, Mitch wrote: > > Your terminology is somewhat confusing. > > The binary data type (where binary data is stored embedded in the XML) is > not supported within ODK Collect. To keep the size of the XML file small, > binary data should be stored as file attachments (what you are talking > about doing). > > The standard way to do this would be with an upload control with a > mediatype attribute. > > The system currently provides controls to handle these mediatype > categories: > > image/* > audio/* > video/* > osm/* > > What media type do you need? (e.g., text/* or application/* or something > else??) > > If you want to add support for text/* or application/* (e.g., > application/octet-stream -- arbitrary files), this requires a modification > to javarosa to define a new control type. > > Then you would be able to use that control type within ODK Collect to > configure a widget that handles that media type. > > ================= > The .cache file is only written, and is not read unless ODK Collect force > closes (crashes). > > > > On Thu, Mar 24, 2016 at 2:16 PM, Isaac Long <isaac...@gmail.com > wrote: > >> Greetings, >> >> We are using ODK Collect and Aggregate in conjunction with two external >> apps to attach numerous files to a form as a user goes through it. To do >> this, we were planning to place instance attributes of type binary in the >> form (initially unfilled/blank), modify the .../odk/.cache save file upon >> attachment to wrap the correct file name, and make sure that the physical >> files are moved to the correct instance directory (similar to how I assume >> the camera widget operates). >> >> We were wondering if there is a standardized way for external apps to >> make these small, widget updates/insertions to the cached save file, and if >> so where in the Collect source code or the JavaRosa source code is a good >> reference for this process so that we could do something similar. >> >> I will continue to look through the Collect source, but any help or >> guidance regarding this would be greatly appreciated. >> >> Thank you for your time, >> Isaac >> >> -- >> You received this message because you are subscribed to the Google Groups >> "ODK Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to opendatakit-developers+unsubscribe@googlegroups.com >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Mitch Sundt > Software Engineer > University of Washington > mitche...@gmail.com >