*I had just posted this on the Formhub Developers group, then realized it
may be a better topic for the ODK community... *
Hey guys, I'm working on a fairly complex project (details below) for
collecting agricultural data from fields using ODK Collect. A major concern
would be the potential for losing data if a form is not saved. It looks
like ODK Collect is able to recover a partially completed form if, for
instance, your battery dies... but I'd like a way to actually save the form
automatically as entries are added. I'd really appreciate any ideas or
solutions to this!
Additional details:
So this idea might be pushing the limits of XLSForms, but I'm working on a
form setup which would collect a fairly large amount of data regarding a
field of crops. Because this is several rows of crops, the data collected
would be based on a grid rather than linearly, so the hard part is making
the form progress dynamically. I'm going to have to setup some pretty fancy
navigation so that whoever is collecting data can treat the form as if it
were 2-dimensional, like a spreadsheet where each cell is a plant. Because
there could be upwards of 500 entries which would be filled in a non-linear
way, the whole thing would be pretty useless if there were any chance of
losing data, hence the need to save progressively.
I know there are probably better ways of going about this, but several
features of formhub and ODK Collect actually work out better than anything
else I've found in regards to collecting data using a touchscreen device.
If I'm able to get this grid navigation working as intended, I'll be sure
to share a generic version for anybody else who'd be interested.
Edit: I'm working with the 1.3 expirimental GUI now, and it certainly makes
things a bit easier.
ODK Collect saves a checkpoint of the form data every time the user pages
forward or backward, and every time the app's onSaveInstanceState() method
is called.
We don't save after changes to every question within a screen.
We expect forms to NOT have 10's or 100's of questions on a single screen.
For readability, we expect the form to be split across multiple screens,
each having a smaller number of questions, so the data loss for questions
within a single screen should be minimal.
If you need to save more frequently,
SaveToDiskTask.blockingExportTempData();
writes the checkpoint file. Note that different phones and Android OS
versions have different event handling, so you may get many or a few change
events for a given user interaction. You should carefully test with the
devices being deployed to ensure you understand exactly how frequently you
are getting change notifications.
Note also that calling this during the handling of an event will write to
the SDCard on the UI thread. On cheaper and slower phones, or with very
large forms, or with slower SDCards, or if you don't understand the
frequency of these update notifications, this can cause your UI to become
unresponsive and Android may then kill it (and your users may find the app
'sluggish' and non-responsive).
Mitch
···
On Wed, Jul 10, 2013 at 10:30 AM, Nicholas Goken wrote:
*I had just posted this on the Formhub Developers group, then realized it
may be a better topic for the ODK community... *
Hey guys, I'm working on a fairly complex project (details below) for
collecting agricultural data from fields using ODK Collect. A major concern
would be the potential for losing data if a form is not saved. It looks
like ODK Collect is able to recover a partially completed form if, for
instance, your battery dies... but I'd like a way to actually save the form
automatically as entries are added. I'd really appreciate any ideas or
solutions to this!
Additional details:
So this idea might be pushing the limits of XLSForms, but I'm working on a
form setup which would collect a fairly large amount of data regarding a
field of crops. Because this is several rows of crops, the data collected
would be based on a grid rather than linearly, so the hard part is making
the form progress dynamically. I'm going to have to setup some pretty fancy
navigation so that whoever is collecting data can treat the form as if it
were 2-dimensional, like a spreadsheet where each cell is a plant. Because
there could be upwards of 500 entries which would be filled in a non-linear
way, the whole thing would be pretty useless if there were any chance of
losing data, hence the need to save progressively.
I know there are probably better ways of going about this, but several
features of formhub and ODK Collect actually work out better than anything
else I've found in regards to collecting data using a touchscreen device.
If I'm able to get this grid navigation working as intended, I'll be sure
to share a generic version for anybody else who'd be interested.
Edit: I'm working with the 1.3 expirimental GUI now, and it certainly
makes things a bit easier.
Thanks Mitch, this pretty much answers my question. It's looking like I
should be safe as far as data loss is concerned, but we'll be doing plenty
of test runs on various devices to see if anyone can manage to mess
something up.
What I'm working on would be hundreds of entries, but generally only 1
entry per screen, which would then automatically advance to the next
screen. I guess the tough part now is figuring out the best way to navigate
those hundreds of entries as if they were cells in a grid, but it shouldn't
be difficult once I'm a bit more familiar with the software and form
design.
···
On Wednesday, July 10, 2013 5:01:23 PM UTC-4, Mitch Sundt wrote:
>
> ODK Collect saves a checkpoint of the form data every time the user pages
> forward or backward, and every time the app's onSaveInstanceState() method
> is called.
>
> We don't save after changes to every question within a screen.
> We expect forms to NOT have 10's or 100's of questions on a single screen.
> For readability, we expect the form to be split across multiple screens,
> each having a smaller number of questions, so the data loss for questions
> within a single screen should be minimal.
>
> If you need to save more frequently,
>
> SaveToDiskTask.blockingExportTempData();
>
> writes the checkpoint file. Note that different phones and Android OS
> versions have different event handling, so you may get many or a few change
> events for a given user interaction. You should carefully test with the
> devices being deployed to ensure you understand exactly how frequently you
> are getting change notifications.
>
> Note also that calling this during the handling of an event will write to
> the SDCard on the UI thread. On cheaper and slower phones, or with very
> large forms, or with slower SDCards, or if you don't understand the
> frequency of these update notifications, this can cause your UI to become
> unresponsive and Android may then kill it (and your users may find the app
> 'sluggish' and non-responsive).
>
> Mitch
>
>
>
> On Wed, Jul 10, 2013 at 10:30 AM, Nicholas Goken <neverfa...@gmail.com wrote:
>
>> *I had just posted this on the Formhub Developers group, then realized
>> it may be a better topic for the ODK community... *
>>
>> Hey guys, I'm working on a fairly complex project (*details below*) for
>> collecting agricultural data from fields using ODK Collect. A major concern
>> would be the potential for losing data if a form is not saved. It looks
>> like ODK Collect is able to recover a partially completed form if, for
>> instance, your battery dies... but I'd like a way to actually save the form
>> automatically as entries are added. I'd really appreciate any ideas or
>> solutions to this!
>>
>> *Additional details:*
>> So this idea might be pushing the limits of XLSForms, but I'm working on
>> a form setup which would collect a fairly large amount of data regarding a
>> field of crops. Because this is several rows of crops, the data collected
>> would be based on a grid rather than linearly, so the hard part is making
>> the form progress dynamically. I'm going to have to setup some pretty fancy
>> navigation so that whoever is collecting data can treat the form as if it
>> were 2-dimensional, like a spreadsheet where each cell is a plant. Because
>> there could be upwards of 500 entries which would be filled in a non-linear
>> way, the whole thing would be pretty useless if there were any chance of
>> losing data, hence the need to save progressively.
>>
>> I know there are probably better ways of going about this, but several
>> features of formhub and ODK Collect actually work out better than anything
>> else I've found in regards to collecting data using a touchscreen device.
>> If I'm able to get this grid navigation working as intended, I'll be sure
>> to share a generic version for anybody else who'd be interested.
>>
>> Edit: I'm working with the 1.3 expirimental GUI now, and it certainly
>> makes things a bit easier.
>>
>> Also, a link to my original thread over in the Formhub Developer group:
>> https://groups.google.com/forum/#!topic/formhub-dev/7_Onhj4l8Cw
>>
>> --
>> --
>> Post: opend...@googlegroups.com
>> Unsubscribe: opendatakit...@googlegroups.com
>> Options: http://groups.google.com/group/opendatakit?hl=en
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "ODK Community" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to opendatakit...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>
>
> --
> Mitch Sundt
> Software Engineer
> University of Washington
> mitche...@gmail.com
>
Just one note on this: the current system of saving save-points is
sometimes thwarted by Android's write-caching behavior, wherein writes to
the SD card do not take place right away. So, for example, one of our
clients discovered that if they yanked their device's battery out
mid-survey, the save-point file would actually be corrupted and Collect
would crash rather than resuming on the next attempt to fill out the form.
We then confirmed this behavior on several other devices, old and new. So
the current Collect is good at recovering from Collect crashes, but hard
Android failures can pose problems.
We have found a safer method of writing save-points (and form definitions,
etc.) to the SD card, so that you can properly resume even after hard
Android failures. There may be some performance cost to this new method,
though, so we have also re-worked save-points to save in the background
rather than in the foreground. This means that, when you swipe forward, it
will go to the next question immediately, saving the save-point in the
background (while the user is looking at the next question); this has the
advantage of dramatically improving the swipe speed for long surveys.
We plan to contribute these changes to the ODK community, but haven't quite
gotten there yet. We're still performing QA and haven't released widely to
SurveyCTO clients yet. But these improvements should be coming to ODK
Collect at some point. Until then, just be aware that there are some limits
to the save-point safety net.
Best,
Chris
···
On Wed, Jul 10, 2013 at 6:17 PM, Nicholas Goken wrote:
Thanks Mitch, this pretty much answers my question. It's looking like I
should be safe as far as data loss is concerned, but we'll be doing plenty
of test runs on various devices to see if anyone can manage to mess
something up.
What I'm working on would be hundreds of entries, but generally only 1
entry per screen, which would then automatically advance to the next
screen. I guess the tough part now is figuring out the best way to navigate
those hundreds of entries as if they were cells in a grid, but it shouldn't
be difficult once I'm a bit more familiar with the software and form
design.
On Wednesday, July 10, 2013 5:01:23 PM UTC-4, Mitch Sundt wrote:
ODK Collect saves a checkpoint of the form data every time the user pages
forward or backward, and every time the app's onSaveInstanceState() method
is called.
We don't save after changes to every question within a screen.
We expect forms to NOT have 10's or 100's of questions on a single screen.
For readability, we expect the form to be split across multiple screens,
each having a smaller number of questions, so the data loss for questions
within a single screen should be minimal.
If you need to save more frequently,
SaveToDiskTask.**blockingExportTempData();
writes the checkpoint file. Note that different phones and Android OS
versions have different event handling, so you may get many or a few change
events for a given user interaction. You should carefully test with the
devices being deployed to ensure you understand exactly how frequently you
are getting change notifications.
Note also that calling this during the handling of an event will write to
the SDCard on the UI thread. On cheaper and slower phones, or with very
large forms, or with slower SDCards, or if you don't understand the
frequency of these update notifications, this can cause your UI to become
unresponsive and Android may then kill it (and your users may find the app
'sluggish' and non-responsive).
*I had just posted this on the Formhub Developers group, then realized
it may be a better topic for the ODK community... *
Hey guys, I'm working on a fairly complex project (details below) for
collecting agricultural data from fields using ODK Collect. A major concern
would be the potential for losing data if a form is not saved. It looks
like ODK Collect is able to recover a partially completed form if, for
instance, your battery dies... but I'd like a way to actually save the form
automatically as entries are added. I'd really appreciate any ideas or
solutions to this!
Additional details:
So this idea might be pushing the limits of XLSForms, but I'm working on
a form setup which would collect a fairly large amount of data regarding a
field of crops. Because this is several rows of crops, the data collected
would be based on a grid rather than linearly, so the hard part is making
the form progress dynamically. I'm going to have to setup some pretty fancy
navigation so that whoever is collecting data can treat the form as if it
were 2-dimensional, like a spreadsheet where each cell is a plant. Because
there could be upwards of 500 entries which would be filled in a non-linear
way, the whole thing would be pretty useless if there were any chance of
losing data, hence the need to save progressively.
I know there are probably better ways of going about this, but several
features of formhub and ODK Collect actually work out better than anything
else I've found in regards to collecting data using a touchscreen device.
If I'm able to get this grid navigation working as intended, I'll be sure
to share a generic version for anybody else who'd be interested.
Edit: I'm working with the 1.3 expirimental GUI now, and it certainly
makes things a bit easier.
You received this message because you are subscribed to the Google
Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit...@**googlegroups.com.