I'm currently customizing the ODK Collect application for downloadable field worker listings. One of the functionalities we want to incorporate is a list of participants to be visited. Once the field worker clicks on one of the items in this list, ODK Collect will open up the associated form and automatically populate the form with name, address and other pertinent information from the list.
Instead, a simpler mechanism would use the
retrieve-string-from-3rd-party-app functionality within the form:
In that case, you would open the form; the first question would use that
feature to launch your selection app. That app would present the user with
the selection list.
Once clicked, a long string would be returned and stored in the string
field.
This would then be picked apart via calculate expressions to populate the
other fields in the form (name, address, etc.).
Mitch
···
On Thu, Jul 25, 2013 at 9:26 AM, wrote:
Hi there,
I'm currently customizing the ODK Collect application for downloadable
field worker listings. One of the functionalities we want to incorporate is
a list of participants to be visited. Once the field worker clicks on one
of the items in this list, ODK Collect will open up the associated form and
automatically populate the form with name, address and other pertinent
information from the list.
Ah, so you write out the form instance XML file in code and then open it in FormEntryActivity as a form instance to be edited. That makes a lot of sense - thanks for that!
Best,
Lu
···
On Thursday, July 25, 2013 6:31:31 PM UTC+1, Mitch Sundt wrote:
> In general, doing this requires rather tight coupling between the launching app and the form definition.
> You can look at the ODK Tables code, specifically http://code.google.com/p/opendatakit/source/browse/src/org/opendatakit/tables/utils/CollectUtil.java?repo=tables#818
>
>
>
> Instead, a simpler mechanism would use the retrieve-string-from-3rd-party-app functionality within the form: http://opendatakit.org/help/form-design/examples/#string_3rd_party
>
>
> In that case, you would open the form; the first question would use that feature to launch your selection app. That app would present the user with the selection list.
>
> Once clicked, a long string would be returned and stored in the string field.
>
> This would then be picked apart via calculate expressions to populate the other fields in the form (name, address, etc.).
>
> Mitch
>
>
>
>
>
> On Thu, Jul 25, 2013 at 9:26 AM, wrote:
>
> Hi there,
>
>
>
> I'm currently customizing the ODK Collect application for downloadable field worker listings. One of the functionalities we want to incorporate is a list of participants to be visited. Once the field worker clicks on one of the items in this list, ODK Collect will open up the associated form and automatically populate the form with name, address and other pertinent information from the list.
>
>
>
>
> I know the code
>
>
>
> startActivity(new Intent(Intent.ACTION_EDIT, formUri));
>
>
>
> opens up the FormEntryActivity, but how do we pass information onto the form that we are calling, e.g. name of interviewee?
>
>
>
> Thanks so much for your help!
>
>
>
> Best,
>
>
>
> Lu
>
>
>
> --
>
> --
>
> 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
FYI: Questions like these are best asked on the opendatakit-developers@list.
The gotcha with the ODK Tables mechanism is that you need to write out
every field of the filled-in instance or else that field will be marked as
not relevant by javarosa when the instance is read in.
Mitch
···
On Thu, Jul 25, 2013 at 12:56 PM, wrote:
Ah, so you write out the form instance XML file in code and then open it
in FormEntryActivity as a form instance to be edited. That makes a lot of
sense - thanks for that!
Best,
Lu
On Thursday, July 25, 2013 6:31:31 PM UTC+1, Mitch Sundt wrote:
In that case, you would open the form; the first question would use that
feature to launch your selection app. That app would present the user with
the selection list.
Once clicked, a long string would be returned and stored in the string
field.
This would then be picked apart via calculate expressions to populate
the other fields in the form (name, address, etc.).
I'm currently customizing the ODK Collect application for downloadable
field worker listings. One of the functionalities we want to incorporate is
a list of participants to be visited. Once the field worker clicks on one
of the items in this list, ODK Collect will open up the associated form and
automatically populate the form with name, address and other pertinent
information from the list.
if (newChildren.size() == 0) {
child.setRelevant(false)
}
at the end of the function, I've changed it to
if (newChildren.size() == 0) {
child.setNullValues();
}
and setNullValues is a short recursive function
public void setNullValues() {
if (this.isLeaf())
this.setAnswer(null);
else
for (int i = 0; i < this.getNumChildren(); i++)
this.getChildAt(i).setNullValues();
}
As far as I can tell the other functionality of javarosa is unaffected and this makes sure you don't have to mention every variable in your form definition in the instance xml that you load.
Best,
Lu
···
On Thursday, July 25, 2013 9:06:30 PM UTC+1, Mitch Sundt wrote:
> FYI: Questions like these are best asked on the opendatakit-developers@ list.
>
> The gotcha with the ODK Tables mechanism is that you need to write out every field of the filled-in instance or else that field will be marked as not relevant by javarosa when the instance is read in.
>
>
> Mitch
>
>
>
>
>
> On Thu, Jul 25, 2013 at 12:56 PM, wrote:
>
> Ah, so you write out the form instance XML file in code and then open it in FormEntryActivity as a form instance to be edited. That makes a lot of sense - thanks for that!
>
>
>
>
> Best,
>
>
>
> Lu
>
>
>
>
> On Thursday, July 25, 2013 6:31:31 PM UTC+1, Mitch Sundt wrote:
>
> > In general, doing this requires rather tight coupling between the launching app and the form definition.
>
> > You can look at the ODK Tables code, specifically http://code.google.com/p/opendatakit/source/browse/src/org/opendatakit/tables/utils/CollectUtil.java?repo=tables#818
>
>
> >
>
> >
>
> >
>
> > Instead, a simpler mechanism would use the retrieve-string-from-3rd-party-app functionality within the form: http://opendatakit.org/help/form-design/examples/#string_3rd_party
>
>
> >
>
> >
>
> > In that case, you would open the form; the first question would use that feature to launch your selection app. That app would present the user with the selection list.
>
> >
>
> > Once clicked, a long string would be returned and stored in the string field.
>
> >
>
> > This would then be picked apart via calculate expressions to populate the other fields in the form (name, address, etc.).
>
> >
>
> > Mitch
>
> >
>
> >
>
> >
>
> >
>
> >
>
>
> > On Thu, Jul 25, 2013 at 9:26 AM, wrote:
>
> >
>
> > Hi there,
>
> >
>
> >
>
> >
>
> > I'm currently customizing the ODK Collect application for downloadable field worker listings. One of the functionalities we want to incorporate is a list of participants to be visited. Once the field worker clicks on one of the items in this list, ODK Collect will open up the associated form and automatically populate the form with name, address and other pertinent information from the list.
>
>
> >
>
> >
>
> >
>
> >
>
> > I know the code
>
> >
>
> >
>
> >
>
> > startActivity(new Intent(Intent.ACTION_EDIT, formUri));
>
> >
>
> >
>
> >
>
> > opens up the FormEntryActivity, but how do we pass information onto the form that we are calling, e.g. name of interviewee?
>
> >
>
> >
>
> >
>
> > Thanks so much for your help!
>
> >
>
> >
>
> >
>
> > Best,
>
> >
>
> >
>
> >
>
> > Lu
>
> >
>
> >
>
> >
>
> > --
>
> >
>
> > --
>
> >
>
> > 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
>
>
>
>
>
> --
>
> --
>
> 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
I don't think that is quite the right code snippet. It will likely have
problems with repeat groups and, perhaps, elements that have attributes.
I would first look at what happens when a brand-new instance is created,
and also when a brand-new repeat group is added; we need to make sure that
those actions are done for any of the missing entries.
And I am hesitant to make sweeping changes to this area of the code, as it
would make it harder to merge our fork back with the commcare fork.
Mitch
···
On Sat, Jul 27, 2013 at 4:03 PM, wrote:
Thanks for that Mitch. I've fixed the issue you mentioned where
unmentioned fields in the XML are automatically marked not relevant by
changing the
if (newChildren.size() == 0) {
child.setRelevant(false)
}
at the end of the function, I've changed it to
if (newChildren.size() == 0) {
child.setNullValues();
}
and setNullValues is a short recursive function
public void setNullValues() {
if (this.isLeaf())
this.setAnswer(null);
else
for (int i = 0; i < this.getNumChildren(); i++)
this.getChildAt(i).setNullValues();
}
As far as I can tell the other functionality of javarosa is unaffected and
this makes sure you don't have to mention every variable in your form
definition in the instance xml that you load.
Best,
Lu
On Thursday, July 25, 2013 9:06:30 PM UTC+1, Mitch Sundt wrote:
FYI: Questions like these are best asked on the opendatakit-developers@list.
The gotcha with the ODK Tables mechanism is that you need to write out
every field of the filled-in instance or else that field will be marked as
not relevant by javarosa when the instance is read in.
Ah, so you write out the form instance XML file in code and then open it
in FormEntryActivity as a form instance to be edited. That makes a lot of
sense - thanks for that!
Best,
Lu
On Thursday, July 25, 2013 6:31:31 PM UTC+1, Mitch Sundt wrote:
In general, doing this requires rather tight coupling between the
launching app and the form definition.
In that case, you would open the form; the first question would use
that feature to launch your selection app. That app would present the user
with the selection list.
Once clicked, a long string would be returned and stored in the string
field.
This would then be picked apart via calculate expressions to populate
the other fields in the form (name, address, etc.).
I'm currently customizing the ODK Collect application for downloadable
field worker listings. One of the functionalities we want to incorporate is
a list of participants to be visited. Once the field worker clicks on one
of the items in this list, ODK Collect will open up the associated form and
automatically populate the form with name, address and other pertinent
information from the list.