When building an Android application based on ODK, is there a recommended
approach for getting data out of stored records without uploading them to a
server? I see two approaches:
-
Just read the ODK data out of the XML into an SQLite or JSON datastore
on the phone, and reference the fields from there for other parts of the
app.
-
Somehow load the stored instances and code against the JavaRosa data
model to get at the stored data. ODK doesn't seem to provide a
straightforward way of doing this.
ODK is primarily concerned with collecting data and sending it off to a
server. That's great, but some apps want to make use of the collected data
locally on the device. Looking for thoughts on this in the ODK ecosystem.
w.
Hi Wyler,
ODK Tables, which is under active development (source at
https://code.google.com/p/opendatakit/wiki/SourceTab?tm=4), is one
approach to do much of what you describe. Perhaps you can take a look?
Yaw
···
--
Need ODK help? Go to http://nafundi.com for custom features, form
design, implementation support, and user training for ODK.
On Tue, Jun 11, 2013 at 4:28 PM, Wyler Yerrachione foundationservices@gmail.com wrote:
When building an Android application based on ODK, is there a recommended
approach for getting data out of stored records without uploading them to a
server? I see two approaches:
-
Just read the ODK data out of the XML into an SQLite or JSON datastore on
the phone, and reference the fields from there for other parts of the app.
-
Somehow load the stored instances and code against the JavaRosa data
model to get at the stored data. ODK doesn't seem to provide a
straightforward way of doing this.
ODK is primarily concerned with collecting data and sending it off to a
server. That's great, but some apps want to make use of the collected data
locally on the device. Looking for thoughts on this in the ODK ecosystem.
w.
--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Ah right, I've looked at this a few times in the course of working through
my ODK integration needs. It never seemed to do the trick for me, but
maybe it's going to be more helpful this time around.
Correct me if I'm wrong, but ODK tables is, essentially, the option (1)
where you have one representation of the data in SQLite, and then another
in your stored instance. Up until about 15 minutes ago this was seeming
like not such a great design, but then I remembered that I believe the
stored instance will contain the full form used to enter the data, which
means that editing old forms is never a problem.
The way we've been addressing our needs so far is similar to ODK tables,
except that we are reading the data out of the the FormEntryController into
a JSON data store, and then uploading to our own API.
One thing that seems to be missing from using ODK as a full featured app
building library is the ability to easily populated blank forms with data
on the fly, which would allow new forms to be prepopulated using older or
location dependent data. Am I right?
···
from my original post, right? So you basically end up with a situation
Wyler,
You can populate forms with data on the fly. That's exactly how Tables
launches form filling sessions with data from its database. I haven't
looked at that part of the code in while, but I think if you pass
Collect a path to a form and a path to the instance, it will do the
right thing and preload the form with that instance data. Then all
your app has to do is to generate an instance from the data you wish
to load.
Send an email to the dev list at
opendatakit-developers@googlegroups.com if you want to discuss the
details.
Yaw
···
--
Need ODK help? Go to http://nafundi.com for custom features, form
design, implementation support, and user training for ODK.
On Tue, Jun 11, 2013 at 4:45 PM, Wyler Yerrachione foundationservices@gmail.com wrote:
Ah right, I've looked at this a few times in the course of working through
my ODK integration needs. It never seemed to do the trick for me, but maybe
it's going to be more helpful this time around.
Correct me if I'm wrong, but ODK tables is, essentially, the option (1) from
my original post, right? So you basically end up with a situation where you
have one representation of the data in SQLite, and then another in your
stored instance. Up until about 15 minutes ago this was seeming like not
such a great design, but then I remembered that I believe the stored
instance will contain the full form used to enter the data, which means that
editing old forms is never a problem.
The way we've been addressing our needs so far is similar to ODK tables,
except that we are reading the data out of the the FormEntryController into
a JSON data store, and then uploading to our own API.
One thing that seems to be missing from using ODK as a full featured app
building library is the ability to easily populated blank forms with data on
the fly, which would allow new forms to be prepopulated using older or
location dependent data. Am I right?
--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Cool, thanks for the direction, this is certainly useful. It's looking
like for the unit I'm working on we'll just store and relaunch instances to
edit, but as we implement other features later in the week I'll be delving
more deeply into your suggestions.
With ODK Tables and ODK Survey, the data is ONLY stored in SQLite
(excluding media attachments).
ODK Survey provides a content provider to return the XML serialization of
the data needed for submission via the legacy collect path.
···
On Tue, Jun 11, 2013 at 5:14 PM, Wyler Yerrachione < foundationservices@gmail.com> wrote:
Cool, thanks for the direction, this is certainly useful. It's looking
like for the unit I'm working on we'll just store and relaunch instances to
edit, but as we implement other features later in the week I'll be delving
more deeply into your suggestions.
--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
Wait - so ODK Survey is open data kit 2.0, and the XML OpenRosa stuff is
going away? In all my reading about ODK I haven't heard much mention of
this at all... Can you provide more detail, I'm very interested, and might
even become a contributor as it seems the project is still in Alpha? Where
can I read more?
···
On Tuesday, June 11, 2013 5:54:53 PM UTC-7, Mitch Sundt wrote:
>
> With ODK Tables and ODK Survey, the data is ONLY stored in SQLite
> (excluding media attachments).
>
> ODK Survey provides a content provider to return the XML serialization of
> the data needed for submission via the legacy collect path.
>
>
>
No. The XML tools, ODK Collect 1.x, ODK Briefcase 1.x, ODK Aggregate 1.x
will all still continue to evolve and live a long life.
The newer 2.0 tools demand beefier mobile devices, are more customizable
(most all of the presentation layer is in javascript/html), but more
complex, than the 1.x tools.
The developers site is http://code.google.com/p/opendatakit/
You can download and play around with an early ODK Survey alpha APK from
there. The software is all checked in on that site, but we have no
documentation on how to build it, and the versioning of the Java code with
the javascript code is 'tribal knowledge' right now.
Mitch
···
On Tue, Jun 11, 2013 at 8:15 PM, Wyler Yerrachione < foundationservices@gmail.com> wrote:
Wait - so ODK Survey is open data kit 2.0, and the XML OpenRosa stuff is
going away? In all my reading about ODK I haven't heard much mention of
this at all... Can you provide more detail, I'm very interested, and might
even become a contributor as it seems the project is still in Alpha? Where
can I read more?
On Tuesday, June 11, 2013 5:54:53 PM UTC-7, Mitch Sundt wrote:
With ODK Tables and ODK Survey, the data is ONLY stored in SQLite
(excluding media attachments).
ODK Survey provides a content provider to return the XML serialization of
the data needed for submission via the legacy collect path.
--
--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com