I'm having trouble with a long survey that may be interrupted. Most of
the questions are required simply to prevent accidentally skipping them.
However this means that it's impossible to save the form, even as
"incomplete".
although that appears to be in the context of skipping around in the
questionnaire. I'm not interested in that, I just want people to be able
to save a form if not all the constraints are satisfied, but force it to
be "incomplete".
I'm not familiar with the code, and not really with Android development,
but I'm guessing I could change FormEntryActivity.saveDataToDisk:
private boolean saveDataToDisk(boolean exit, boolean complete, String updatedSaveName) {
// save current answer
if (!saveAnswersForCurrentScreen(EVALUATE_CONSTRAINTS)) {
to not evaluate the constraints before saving? I think this will already
mark the form as incomplete, is that correct? Does it seem like the right
thing to do? Something that might be useful in general, at least as a
preference?
Cheers, Chris.
···
--
Aptivate | http://www.aptivate.org | Phone: +44 1223 760887
The Humanitarian Centre, Fenner's, Gresham Road, Cambridge CB1 2ES
Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.
I just want people to be able to save a form if not all the constraints
are satisfied, but force it to be "incomplete"...
I'm not familiar with the code, and not really with Android development, but
I'm guessing I could change FormEntryActivity.saveDataToDisk:
private boolean saveDataToDisk(boolean exit, boolean complete, String
updatedSaveName) {
// save current answer
if (!saveAnswersForCurrentScreen(EVALUATE_CONSTRAINTS)) {
to not evaluate the constraints before saving? I think this will already mark
the form as incomplete, is that correct? Does it seem like the right thing to
do?
It seems to work, as far as I can tell
Relatedly, I noticed that there's a text box at the end of the survey to
set the "name" of the form, which is useful in identifying it for
submission or later continuation.
Since in my version it's possible to save the form even if it's
incomplete, this name will not have been completed by the user when saving
an incomplete form for later submission.
I was wondering whether it might be possible to fill this in at the
beginning of the survey instead of at the end? Or to base it on a value in
the instance data, selected by the form designer (such as the household ID
in our case), at least as a default value?
Cheers, Chris.
Aptivate | http://www.aptivate.org | Phone: +44 1223 760887
The Humanitarian Centre, Fenner's, Gresham Road, Cambridge CB1 2ES
Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.
The default behavior of Collect is to let you save a form as incomplete,
even if required questions have not been answered. It may be the case that
if you're on a required question and try to save/exit as incomplete, it
will try to evaluate the constraint, but I'll need to look into that.
As for giving the instance a name when saving at the end-- the default
value for the name is "[form title] data". If you're modifying the code,
that can be set to pretty much anything. Letting the form designer specify
a field to be the save-name is on our list of things to do, but we haven't
had time to implement it, yet.
-Carl
···
On Tue, Nov 15, 2011 at 11:29 PM, Chris Wilson wrote:
Hi all,
On Tue, 15 Nov 2011, Chris Wilson wrote:
I just want people to be able to save a form if not all the constraints
are satisfied, but force it to be "incomplete"...
I'm not familiar with the code, and not really with Android development,
but I'm guessing I could change FormEntryActivity.**saveDataToDisk:
private boolean saveDataToDisk(boolean exit, boolean complete, String
updatedSaveName) {
// save current answer
if (!saveAnswersForCurrentScreen(**EVALUATE_CONSTRAINTS)) {
to not evaluate the constraints before saving? I think this will already
mark the form as incomplete, is that correct? Does it seem like the right
thing to do?
It seems to work, as far as I can tell
Relatedly, I noticed that there's a text box at the end of the survey to
set the "name" of the form, which is useful in identifying it for
submission or later continuation.
Since in my version it's possible to save the form even if it's
incomplete, this name will not have been completed by the user when saving
an incomplete form for later submission.
I was wondering whether it might be possible to fill this in at the
beginning of the survey instead of at the end? Or to base it on a value in
the instance data, selected by the form designer (such as the household ID
in our case), at least as a default value?
Cheers, Chris.
Aptivate | http://www.aptivate.org | Phone: +44 1223 760887
The Humanitarian Centre, Fenner's, Gresham Road, Cambridge CB1 2ES
Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.
carl is mostly correct. we change things so often it's hard for us to
keep track...
in 1.1.7, when you first start form filling and save in the middle of
the form, the form is saved as incomplete. it's only when you get to
the last screen that we save as complete, which is by default (and an
option available in the prefs). after a form is saved, if you re-open
it and save it in the middle of the form, we save it as whatever
status it was saved as earlier (incomplete or complete). you have to
go to the end to save it as complete.
as always, if anyone has developer resources, these are small bits of
functionality that we'd be glad to patch into the core.
yaw
···
On Thu, Nov 17, 2011 at 07:53, Carl Hartung wrote:
> Hi Chris,
> The default behavior of Collect is to let you save a form as incomplete,
> even if required questions have not been answered. It may be the case that
> if you're on a required question and try to save/exit as incomplete, it will
> try to evaluate the constraint, but I'll need to look into that.
> As for giving the instance a name when saving at the end-- the default value
> for the name is "[form title] data". If you're modifying the code, that can
> be set to pretty much anything. Letting the form designer specify a field
> to be the save-name is on our list of things to do, but we haven't had time
> to implement it, yet.
> -Carl
>
>
>
> On Tue, Nov 15, 2011 at 11:29 PM, Chris Wilson wrote:
>>
>> Hi all,
>>
>> On Tue, 15 Nov 2011, Chris Wilson wrote:
>>
>>> I just want people to be able to save a form if not all the constraints
>>> are satisfied, but force it to be "incomplete"...
>>>
>>> I'm not familiar with the code, and not really with Android development,
>>> but I'm guessing I could change FormEntryActivity.saveDataToDisk:
>>>
>>> private boolean saveDataToDisk(boolean exit, boolean complete, String
>>> updatedSaveName) {
>>> // save current answer
>>> if (!saveAnswersForCurrentScreen(EVALUATE_CONSTRAINTS)) {
>>>
>>> to not evaluate the constraints before saving? I think this will already
>>> mark the form as incomplete, is that correct? Does it seem like the right
>>> thing to do?
>>
>> It seems to work, as far as I can tell :)
>>
>> Relatedly, I noticed that there's a text box at the end of the survey to
>> set the "name" of the form, which is useful in identifying it for submission
>> or later continuation.
>>
>> Since in my version it's possible to save the form even if it's
>> incomplete, this name will not have been completed by the user when saving
>> an incomplete form for later submission.
>>
>> I was wondering whether it might be possible to fill this in at the
>> beginning of the survey instead of at the end? Or to base it on a value in
>> the instance data, selected by the form designer (such as the household ID
>> in our case), at least as a default value?
>>
>> Cheers, Chris.
>> --
>> Aptivate | http://www.aptivate.org | Phone: +44 1223 760887
>> The Humanitarian Centre, Fenner's, Gresham Road, Cambridge CB1 2ES
>>
>> Aptivate is a not-for-profit company registered in England and Wales
>> with company number 04980791.
>>
>> --
>> Post: opendatakit@googlegroups.com
>> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
>> Options: http://groups.google.com/group/opendatakit?hl=en
>
> --
> Post: opendatakit@googlegroups.com
> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> Options: http://groups.google.com/group/opendatakit?hl=en
>
The default behavior of Collect is to let you save a form as incomplete,
even if required questions have not been answered. It may be the case
that if you're on a required question and try to save/exit as
incomplete, it will try to evaluate the constraint, but I'll need to
look into that.
Yes, that might explain it, as almost all of our questions are required so
I didn't try that.
As for giving the instance a name when saving at the end-- the default
value for the name is "[form title] data". If you're modifying the
code, that can be set to pretty much anything. Letting the form
designer specify a field to be the save-name is on our list of things to
do, but we haven't had time to implement it, yet.
I'd like to give the user the opportunity to set this name as early as
possible, to help identify saved forms, and/or have it default to a field
in the form itself, but I haven't figured out how to achieve that yet.
I'm also thinking about modifying the Collect code so that it can be built
as a Java appication with no dependency on Android libraries, for filling
in and checking forms on a desktop computer, by mocking the Android
interfaces that it uses.
I've had several cases today where a form that passes validation causes
the Collect application to force quit when you actually try to use it. The
main one seems to be creating an empty group in XLS2Xform by disabling or
making irrelevant all questions within a group, rather than the group
itself; and it would be much easier to debug this if I could run a desktop
app in the Eclipse debugger.
Cheers, Chris.
···
On Thu, 17 Nov 2011, Carl Hartung wrote:
--
Aptivate | http://www.aptivate.org | Phone: +44 1223 760887
The Humanitarian Centre, Fenner's, Gresham Road, Cambridge CB1 2ES
Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.
The default behavior of Collect is to let you save a form as incomplete,
even if required questions have not been answered. It may be the case that
if you're on a required question and try to save/exit as incomplete, it
will try to evaluate the constraint, but I'll need to look into that.
modifying collect to run as a desktop java app is going to be a fair
bit of work. i don't want to discourage you, because plenty of people
would use it, but it's not going to be a weekend project. one
alternative is to use http://www.android-x86.org/. the other is to
figure out a way to do form filling in a web browser -- search the
mailing list for implementation approaches.
odk validate can't catch everything. there are plenty of (mostly
runtime) bugs within the form that will crash odk collect. please file
a bug at http://code.google.com/p/opendatakit/issues/list with the
form that is giving you problems. with that bug report, we should be
able to prevent xls2xform from generating forms that crash the phone.
···
On Thu, Nov 17, 2011 at 09:54, Chris Wilson wrote:
> Hi Carl,
>
> On Thu, 17 Nov 2011, Carl Hartung wrote:
>
>> The default behavior of Collect is to let you save a form as incomplete,
>> even if required questions have not been answered. It may be the case that
>> if you're on a required question and try to save/exit as incomplete, it will
>> try to evaluate the constraint, but I'll need to look into that.
>
> Yes, that might explain it, as almost all of our questions are required so I
> didn't try that.
>
>> As for giving the instance a name when saving at the end-- the default
>> value for the name is "[form title] data". If you're modifying the code,
>> that can be set to pretty much anything. Letting the form designer specify
>> a field to be the save-name is on our list of things to do, but we haven't
>> had time to implement it, yet.
>
> I'd like to give the user the opportunity to set this name as early as
> possible, to help identify saved forms, and/or have it default to a field in
> the form itself, but I haven't figured out how to achieve that yet.
>
> I'm also thinking about modifying the Collect code so that it can be built
> as a Java appication with no dependency on Android libraries, for filling in
> and checking forms on a desktop computer, by mocking the Android interfaces
> that it uses.
>
> I've had several cases today where a form that passes validation causes the
> Collect application to force quit when you actually try to use it. The main
> one seems to be creating an empty group in XLS2Xform by disabling or making
> irrelevant all questions within a group, rather than the group itself; and
> it would be much easier to debug this if I could run a desktop app in the
> Eclipse debugger.
>
> Cheers, Chris.
> --
> Aptivate | http://www.aptivate.org | Phone: +44 1223 760887
> The Humanitarian Centre, Fenner's, Gresham Road, Cambridge CB1 2ES
>
> Aptivate is a not-for-profit company registered in England and Wales
> with company number 04980791.
>
> --
> Post: opendatakit@googlegroups.com
> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> Options: http://groups.google.com/group/opendatakit?hl=en
>
modifying collect to run as a desktop java app is going to be a fair
bit of work. i don't want to discourage you, because plenty of people
would use it, but it's not going to be a weekend project.
I figured it wouldn't be easy, but I think it might be very useful and I'm
prepared to invest some limited effort into making it work.
Thanks, I have been using that for development, it's not much faster than
a real device and not intuitive for end users (to test their form changes
and modify saved forms), but works well for development.
the other is to figure out a way to do form filling in a web browser --
search the mailing list for implementation approaches.
Will look into that, thanks.
odk validate can't catch everything. there are plenty of (mostly
runtime) bugs within the form that will crash odk collect. please file a
bug at http://code.google.com/p/opendatakit/issues/list with the form
that is giving you problems. with that bug report, we should be able to
prevent xls2xform from generating forms that crash the phone.
