wazamog / opendatakit

Automatically exported from code.google.com/p/opendatakit
0 stars 0 forks source link

patch: implicit intent for FormEntryActivity so that external applications can invoke a form and autopopulate it with data #72

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Hello,

first of all, congratulations and thanks for this great framework.

I think that making intents implicit will help to easily integrate odk
collect in other apps. Enclosed a patch to open odk to external
applications for creating a new form data and autopopulating some fields.
Maybe there is a better way of doing this, especially autopopulating would
be probably better if done through a map instead of xml.

also solves an array out of bounds exception, i encountered, when deleting
data files.

-- Ron

Original issue reported on code.google.com by rzo12...@googlemail.com on 13 May 2010 at 7:01

Attachments:

GoogleCodeExporter commented 9 years ago
thanks for the patch. we'll take a look.

Original comment by yanokwa on 13 May 2010 at 7:53

GoogleCodeExporter commented 9 years ago
I added the intent information to androidmanifest.xml so that other 
applications can call ODK.  

To load a form use:
String formPath = [path to form];
 formPath = intent.getStringExtra("formpath");
 i = new Intent("org.odk.collect.android.action.FormEntry");
 i.putExtra(GlobalConstants.KEY_FORMPATH, formPath);
 startActivity(i);

To load an already saved instance use:
String formPath = [path to form];
String instancePath = [path to saved instance];
i = new Intent("org.odk.collect.android.action.FormEntry");
i.putExtra("formpath", formPath);
i.putExtra("instancepath", instancePath);
startActivity(i);

Original comment by carlhart...@gmail.com on 13 May 2010 at 11:12

GoogleCodeExporter commented 9 years ago
Hello,

thanks for the fast update.

Q: what about auto-populating fields in the form by an external app ? Or, 
changing
fields in existing form instances ?

Q: I would also propose to have an intent with result, so in case of new 
instances we
have as return value the folder of the instance.

Another idea: allow some generic way to associate form field types with intents 
and
intent results. This is currently hard coded for camera, voice, etc.. The form
designer could thus change how geolocation fields are edited by providing an 
activity
which will also show the recorded location on a map. Thus users will not have 
to edit
odk code, but will just provide their own activities and from within the xforms 
map
field types to the activity.

-- ron

Original comment by rzo12...@googlemail.com on 15 May 2010 at 8:40

GoogleCodeExporter commented 9 years ago
can you file these three as separate issues? the first two are likely coming 
soon. the lsat one requires a bit of 
thinking to do intelligently.  

Original comment by yanokwa on 15 May 2010 at 2:03

GoogleCodeExporter commented 9 years ago
Good issues you bring up.

Re your first question:
Currently, the only way to auto-populate fields is by loading a saved instance 
(basically what happens when 
you click 'Review Saved Data' on the main menu and choose a form).  Other 
applications can now load Collect 
with a saved instance with the intent changes that were recently made to the 
manifest.  

Relating to the patch you submitted, the filePath argument for the importData() 
method in 
FormLoaderTask.java has to point at a well formed instance of a specific form; 
it can't just be a file with 
answers in it.  In the patch you submitted the newInstanceData variable is 
actually exactly duplicating the 
functionality of the instancePath variable.  

Off the top of my head, the cheap way to auto-populate fields would be to 
include an array of strings in the 
bundle passed to the activity and run through it with FormEntryController.  The 
hard part about that is you'd 
need to know when each question comes up in a form, and that can be incredibly 
difficult based on branching 
and the size of your form.

Probably the right way to do it would be to include a list of key-value pairs 
in the bundle where the key was 
the instance variable found in the original form (something like <person_name>) 
, and ignore keys not in the 
form.

2) Agreed with the return value from the intent.  I'll look into that.

3) We've been in discussion with the javarosa guys about how to do custom 
intents in Xforms that won't brake 
the spec.  I think we've got a solution, we just need time to implement it.

Also agreed with Yaw, please file separate issues for 2 and 3.
Thanks!

Original comment by carlhart...@gmail.com on 15 May 2010 at 6:35