Instructions/Training Material for Android: Open Data KIT

Table of Contents

Background

How to Create a form and Deploy it

Creating a form

Option A: Open Data Kit Build

Option B: Building a form in Notepad ++

Validating a form

Troubleshooting a form

Deploying the validated xml form on an Android device#

Glossary

References

Annex: LLIN COVERAGE AND DURABILITY SURVEY

Background

In November 2010, UNHCR Public Health Section was interested in piloting an Android based Long Lasting Insecticide Treated Net (LLIN) Coverage and Durability Survey in Dagahaley camp, Kenya. The objective was to have a direct comparison with the paper surveys conducted in IFO and Hagadera camp and be able to assess whether an electronic survey is feasible in this setting.

After a short assessment of the paper questionnaire, the aim of the survey and the current situation, the Field Coordination Support Section (FICSS) recommended the use of Open Data Kit (ODK), an open source toolset developed for mobile phone data collection with Android phones. The time frame for developing and deploying the electronic form was of only 2 weeks and therefore no guiding material could be produced before the survey was scheduled to go ahead. In order to bridge the gap between the staff creating the ODK material remotely and the staff conducting the survey, a series of documents were produced to assist with background materials for further deployments.

This document serves as a reference, a manual for trainees who would like to learn how to create a form. It is by no means exhaustive and will require background reading of the links cited in the document. It is not difficult to learn how to utilise ODK, however, a strong background in data management, databases, file formats or general knowledge in IT will be necessary to follow the instructions, if unsupervised. At the time of writing, there is no complete manual to be downloaded from the web but several wiki links for ODK and JavaRosa have been consulted and combined to create this reference. The intention is to get a basic overview and cut down the time to search the links for further reading. The document therefore can also serve as a baseline for a workshop or training and can be augmented with hands-on exercises. Similar manuals will be produced for other ODK tools like ODK Aggregate in future projects.

Depending on the complexity of the survey and its resulting electronic form, the creation of a form and its thorough testing can take up to a week. It is recommended to leave some time to have a test run in the field as some questions might have to adapted to fit the local context.

1. How to Create a form and Deploy it

In order to conduct a survey with an Android mobile phone, the paper based form needs to be translated into an electronic questionnaire and send to the phone. The way ODK is set up, it is specifically recommendable for “one shot” surveys, e.g. surveys or assessments which are conducted once to gain a snapshot view of the current situation. This document describes how an electronic questionnaire in ODK is structured and what to look out for when creating a new form.

Note: The instructions given in this manual apply to Windows operating systems. Many of them will work on other systems, too, but some might require different tools and syntax as the ones listed in this document.

Mac or Linux Users should always consult the references cited for alternative instructions.

1. Creating a form

1. Option A: Open Data Kit Build

ODK Build is one of the ODK tools^[1] which have been developed by the ODK community and makes designing the forms easy. You will need to sign up and create an account as the application is hosted online.

Note: At the time of writing this tool is only working for the creation of simple forms which do not require branching and looping^[2]; if your form is complex you can skip this chapter and move to the next.

• Go to http://build.opendatakit.org/ and create an account.
• 

• ODK Build is a tool

Once you have created and activated your account, log in and start creating your own form.

• Rename the form and start exploring the different type of fields you can add. You find them at the bottom of the page.

• Add a Text field and set the properties of this text field on the right hand side. You will need to add the field name (Note: Column name; avoid using spaces and special characters here) and its caption. You can also add a hint (e.g. help) and specify whether the field is required or read-only and even define its length or a default value.

• Continue adding fields you would like to use for your survey.

ODK Build provides for the following field options:

• Numeric (Range can be set)
• Date (Range can be set with the help of a calendar)
• Location (GPS coordinates)
• Media (Type can be set by a dropdown menu: Image, Audio, Video)
• Barcode
• Choose One, e.g. Radio buttons (Surveyor has to choose one option)
• Select Multiple, e.g. Tick boxes (Surveyor can tick all that applies)

For the optional fields Choose One and Select Multiple, you can set what is displayed and the value recorded for it, for instance you have a question which needs to be answered with True or False, you can code it with 1 and 0 if this is how you’d like to analyse your data later.

• Don’t forget to save your form in between; as the application is hosted online, it might crash or you might get disconnected especially in areas with low bandwidth.

• Once you have completed your form, you can export it. Go to File/Export to XML.

Note: You could also export to ODK Aggregate, covered in a later chapter; however, at the time of writing, ODK Build is not coding the form with a form ID automatically. This form ID is needed for ODK Aggregate to work correctly. Find more information and how to add the ID here: http://code.google.com/p/opendatakit/wiki/ODKAggregate

• Now you will need to validate your form. Please refer to Chapter Validating a Form.

Note: Another option for easy creation of forms can be found here: http://xform.childcount.org/ 

This has received positive feedback from the ODK community but has not been tested in the course of the current project.

2. Option B: Building a form in Notepad ++

• The easiest option to build a form from scratch or to modify an existing form is through an xml editor. For Windows Operating System the free Editor Notepad ++ with the xml plugin is for the suggested alternative. Download the software at http://notepad-plus-plus.org/

• Ensure that you have the latest version of Java and the Java Wireless Toolkit. Depending on what you plan to do in future, you have the option of installing JDK^[3]  or JRE^[4]. If you intend to develop or look more in-depth into Java applications, you might want to opt for JDK. Please use the following guide to decide which system works the best for you: http://www.java.com/en/download/faq/techinfo.xml. The JavaRosa initiative has compiled more background information, downloading links and instructions how to install the developer version. Refer to http://code.javarosa.org/wiki/buildxforms and https://bitbucket.org/javarosa/javarosa/wiki/GettingStarted

Note: You will NOT need Java Wireless Toolkit if you are not planning to run the JavaRosa Validator or use other resources and samples from their webpage. Java Wireless Toolkit allows you to build Java applications which run on a variety of Java enabled phones, not only on Androids. You will still need to download and install the latest version of Java, though.

Simple Java: http://www.java.com/en/download/index.jsp.

Wireless Toolkit: http://www.oracle.com/technetwork/java/download-135801.html or http://www.oracle.com/technetwork/java/javame/downloads/sdk30-jsp-139759.html

• It is easier to understand the structure when changing an already existing form and test the effects of your changes instead of starting entirely from scratch. You can find sample forms to look at here:

http://code.google.com/p/opendatakit/source/browse?repo=forms and http://code.javarosa.org/attachment/wiki/buildxforms/training_form_4.xml

The latter can be found on http://code.javarosa.org/wiki/buildxforms when scrolling to the bottom Attachments. The Xforms posted here vary in complexity with form1 being the most simple and form8 the most complex one.

The following screen shots show the Xform created for a Mosquito Net survey conducted by the Public Health Section, UNHCR, in Dadaab, Kenya. They are used for illustrating the structure of an XForm and what to look out for. You can find the layout of the paper questionnaire in the Annex.

• When you load any of the sample forms you downloaded from the ODK or JavaRosa repository into Notepad ++, ensure that you have enabled the XML syntax auto-check and Tag auto-close under Plugins/XML Tools. This will reflect any structural XML error like missing tags^[5]/parenthesis etc. P

Please check ODK Validate and Troubleshooting a form for more information on common errors.

Auto-close will enter the correct closing tag automatically which is very helpful.

Some important XML basics:

(adapted from JavaRosa project page, http://www.javarosa.org/wiki/buildxforms)

• Tags can be self-closing (<tag />) or come in opening and closing pairs (<tag></tag>). Standalone tags like in HTML (a <br> that is never closed by a corresponding </br>) are not allowed.
• Paired tags can have text or other tags inside them (<tag>some text <another-tag /></tag>). Which tags can appear inside other tags is determined by the XML schema^[6].
• Tags must be closed in the reverse order they were opened (<a><b></b></a>). This would be invalid XML: <a><b></a></b> 
• The entire document must be enclosed within a single tag. This is called the top-level element.
• Tags can have attributes (<tag attribute="attribute value" another-attribute="value 2" />)
• Certain special characters must be escaped when used in text or attribute values: < must be replaced with &lt;, > with &gt;, and & with &amp; 

You can find more explanations and definitions for XML structure here: http://en.wikipedia.org/wiki/XML

The skeleton of an XForm looks like this:

<h:html xmlns="http://www.w3.org/2002/xforms"

        xmlns:h="http://www.w3.org/1999/xhtml"

        xmlns:ev="http://www.w3.org/2001/xml-events"

        xmlns:xsd="http://www.w3.org/2001/XMLSchema"

        xmlns:jr="http://openrosa.org/javarosa">

  <h:head>

    <h:title>[form title]</h:title>

    <model>

      <instance>

                [define the schema of your resulting data here]

      </instance>

              [define restrictions on your data (such as data types,

                range constraints, and skip logic) with bindings here]

    </model>

  </h:head>

  <h:body>

            [add controls that describe your questions here]

  </h:body>

</h:html>

• Let’s examine instance a bit further:

The output of a filled-out XForm is itself another XML document. You create a skeleton of this XML document and place it inside the <instance> tag. Questions in the form refer to various parts of the instance and place their answers there as they are filled out. When your form is complete, the instance can be saved as a complete, self-contained XML document, and submitted from the phone to remote servers.

Sample:

Note: For better readability the Netsurvey loop and the personal questions to the respondent at the end of the survey were taken out.

• It’s recommended to make the tag names in your instance as descriptive as possible.

A few points to consider for your field names especially if you are using ODK Aggregate for synchronisation:

(adapted from ODK project page, http://code.google.com/p/opendatakit/wiki/XFormDesignGuidelines)

1. be short (ideally < 30 characters)
2. must be unique within their containing group within the form (this is required by Xml and Javarosa)
3. cannot contain any spaces
4. should contain only alphanumeric characters and the characters '_' and '-'
5. should start with a letter
6. should all consistently follow either the camel-case convention (e.g., thisFormField) with leading capitals denoting word breaks within the field name, or use either the '_' or '-' characters to mark word breaks (e.g., this-form-field).
7. should not have two or more fields that are distinguished only by either their capitalization, use of dashes, or use of underscores. E.g., it is discouraged to have two or more of these field names appear within a single form: thisFormField, this-form-field, thisformfield,this_formField.

• For ODK Aggregate to function properly, you will introduce either an xmlns (deprecated, e.g still compatible, but no longer supported) or preferably a Form ID, especially if the form contains loops/branches.

Sample:  

<instance>
        <data id="sampleForm">
          <name/>
          <age/>
          <date/>
        </data>
   </instance>

Note: As the LLIN form was not designed for using with ODK Aggregate, no attention was paid to this aspect, however, it is recommended to always implement a form ID.  

Find more information on Form ID’s here:  http://code.google.com/p/opendatakit/wiki/XFormDesignGuidelines

• Let us examine Bindings.

Bindings let us attach restrictions to the type of data that may be entered into the instance. The restrictions may be:

1. Data types, for example, indicating that a given question is meant to store dates, so only dates will be allowed as answers to that question. This may also affect how the question appears to the user (see 'controls'). Another kind of data type is restricting answers to numbers only.
2. Skip logic: only allowing a question to be answered if another question has a certain value (e.g., only asking 'is household member pregnant' if 'sex' is female)
3. Required: requiring that a question be answered before you can complete the form
4. Range constraints: limiting the kinds of answers that may be accepted (e.g., setting age for children)

Bindings are defined via a <bind> tag. The binding references a single tag in the instance via an expression, and then defines the various restrictions on that question. Every question has its own binding. Not every question needs a binding, though, such as if it uses the default data type (text) and has no other restrictions.

The instance and the bindings together comprise the XForm model.

• Sample for data types:

Integer: <bind nodeset="/data/Members/Q204AGEY" type="int"/> (Question on Age)

String: <bind nodeset="/data/Members/Q202NAME" type="string"/> (Name of family member)

Binary: <bind nodeset="/data/Netsurvey/NetImage" type="binary"/> (Picture of Net)

Date: <bind nodeset="/data/Q002DATE" type="date" /> (Date of data collection)

• Sample for Skip logic:

<bind nodeset="/data/Q104ENTR" relevant="selected(/data/Q101NETS, 'true')"/>

The question Q101NETS (“Do you have mosquito (bed) nets in this household that can be used for sleeping?”) needs to be answered with “true” before Question Q104ENTR (ASK RESPONDENT IF THEY WILL LET YOU ENTER THE HOUSEHOLD AND TO SHOW YOU THE NET(S) IN THE HOUSEHOLD.) will show up on the screen of the mobile phone.

• Sample for Required:

<bind nodeset="/data/Netsurvey/NetNum" type="int" required="true()"/> (Number of surveyed Net is required)

• Sample for Range Constraints:

<bind nodeset="/data/Q001CODE" type="int" constraint="(. &gt; 0 and . &lt; 13)" required="true()"/> (Number of code of surveyor is limited to 1-12; as there were no more than 12 surveyors per Refugee camp for the Mosquito Net Survey) Note: This question is also required.

• Let us examine Controls.

The controls define the questions that the user actually sees. Each question presented to the user is its own control, and the user sees the questions in the same order listed in the XForm. A control is either an <input>, <select>, or <select1> tag.

<input> is used for free-entry questions, such as text, numbers, and dates; <select1> is used for multiple-choice questions where you can pick only one choice; <select> is used for multiple-choice questions where you can pick many choices.

A control must define the following things:

1. Where in the instance the answer is stored (via an XPath expression)
2. The caption or prompt of a question
3. For multiple choice questions, the available choices and their captions

• Sample for <input>

<input ref="/data/Netsurvey/NetNum">

                    <label ref="jr:itext('/data/Netsurvey/NetNum:label')"/>

                    <hint ref="jr:itext('/data/Netsurvey/NetNum:hint')"/>

           </input>

        Input is the number of the surveyed net.

The corresponding itext in the <itext></itext> body:

<text id="/data/Netsurvey/NetNum:label">

             <value>Number of Net</value>

 </text>

 <text id="/data/Netsurvey/NetNum:hint">

<value>Start counting from 1 onwards, 1 for the first net you survey, 2 for the second net and so on</value>

 </text>

• Sample for <select>

Note: Sampled is shortened as original sample contained more than 9 options.

<select ref="/data/Netsurvey/Q112LABL">

        <label ref="jr:itext('/data/Netsurvey/Q112LABL:label')"/>

        <hint ref="jr:itext('/data/Netsurvey/Q112LABL:hint')"/>

             <item>

              <label ref="jr:itext('/data/Netsurvey/Q112LABL:option0')"/>

                  <value>1</value>

             </item>

             <item>

               <label ref="jr:itext('/data/Netsurvey/Q112LABL:option1')"/>

                   <value>2</value>

              </item>

             <item>

                <label ref="jr:itext('/data/Netsurvey/Q112LABL:option2')"/>

                    <value>3</value>

             </item>

             <item>

<label ref="jr:itext('/data/Netsurvey/Q112LABL:option3')"/>

                    <value>4</value>

             </item>

    </select>

The surveyor has to select all the sources of information the respondent was exposed to.

The corresponding itext in the <itext></itext> body:

<text id="/data/Netsurvey/Q112LABL:label">

<value>Did you receive any information on how to hang your net?  If yes, from where?  </value>

</text>

<text id="/data/Netsurvey/Q112LABL:hint">

              <value/>

</text>

<text id="/data/Netsurvey/Q112LABL:option0">

               <value>Household visit</value>

 </text>

 <text id="/data/Netsurvey/Q112LABL:option1">

               <value>At health clinic</value>

 </text>

 <text id="/data/Netsurvey/Q112LABL:option2">

               <value>Poster</value>

 </text>

 <text id="/data/Netsurvey/Q112LABL:option3">

               <value>Radio</value>

 </text>

The surveyor can tick all that applies: Household visit, At health clinic, from a Poster or by listening to the Radio.

•  Sample for <select1>

       <select1 ref="/data/Netsurvey/Q106SHAP">

         <label ref="jr:itext('/data/Netsurvey/Q106SHAP:label')"/>

         <hint ref="jr:itext('/data/Netsurvey/Q106SHAP:hint')"/>

            <item>

            <label ref="jr:itext('/data/Netsurvey/Q106SHAP:option0')"/>

                   <value>1</value>

             </item>

             <item>

             <label ref="jr:itext('/data/Netsurvey/Q106SHAP:option1')"/>

                   <value>2</value>

             </item>

             <item>

             <label ref="jr:itext('/data/Netsurvey/Q106SHAP:option2')"/>

                   <value>3</value>

             </item>

      </select1>

The shape of the surveyed net has to be determined.

The corresponding itext in the <itext></itext> body:

<text id="/data/Netsurvey/Q106SHAP:label">

          <value>Observe or ask the shape of the net and record</value>

</text>

<text id="/data/Netsurvey/Q106SHAP:hint">

      <value/>

</text>

<text id="/data/Netsurvey/Q106SHAP:option0">

       <value>Rectangular</value>

</text>

<text id="/data/Netsurvey/Q106SHAP:option1">

       <value>Conical</value>

</text>

<text id="/data/Netsurvey/Q106SHAP:option2">

       <value>Other</value>

</text>

The surveyor can choose between Rectangular, Conical and Other as the shape of the surveyed net.

• Groups and Loops/Branches

If parts of your survey need to be repeated; it makes sense to create groups in your structure. These can be repeated an x amount of time, for instance if you need to add information on every mosquito net in each household, you will have a varying number of loops per household. In order to code this in your form, you will declare a group.

• As you can see in the graph to the right, a group for household members has been declared in instance.

Note: This also changes the XPath reference structure, here the example for the bindings:

• If you want this group to loop allowing you to add several groups to every record; you need to use the expression <repeat nodeset=”/xx/yy”> in the <h:body> of the xml file where all the groups are declared. See graph below and to the right.

Note: The syntax has been shortened to fit on a screenshot

• The graph on the right shows how the looping of a group works on an Android device. Every time you finished entering a looping group, you will be asked again whether you want to Add New Group.

• There are several Xforms reference guides found on the Internet; the following two are recommended to read up on the structure and can also help for tracing an error.

ODK: http://code.google.com/p/opendatakit/wiki/XFormDesignGuidelines and http://code.google.com/p/opendatakit/wiki/XFormLogicExplained

JavaRosa: http://code.javarosa.org/wiki/buildxforms

2. Validating a form

After creating your form, you will need to validate it. You can validate either by using ODK Validator or the JavaRosa XForm validator. They can be downloaded from the Internet and require Java and WTK (JavaRosa, refer to previous chapter).

ODK : http://code.google.com/p/opendatakit/downloads/detail?name=ODK%20Validate%20v1.2.jar&can=2&q=

JavaRosa:

http://code.javarosa.org/attachment/wiki/JavaRosa-XForm-Validator/javarosa-xform-validator.jar

• Whereas the XML plug-in of Notepad ++ is already picking up structural errors, for instance dangling tags, only the above mentioned Validators are able to pick up XForm specific errors.

• Validating your form is easy, you open the Validator (double-click), navigate to your xml file and load it into the Validator.

If it does not contain any errors, you will receive the following message:

Note: For validator ODK has a few additional restrictions that may not be tested by the tool. In particular, a Form ID must be defined. In Aggregate 1.0, there may be additional restrictions for alternative persistence mechanisms such as MySQL. ODK Validate is expected to be updated once those restrictions, if any, are determined.

3. Troubleshooting a form

The following collection, by no means exhaustive, is meant to

assist you with simple troubleshooting. Also refer to resources listed in Glossary and References for more information.

• The Validator will state line and position of error. When checking the respective form in Notepad ++, you will notice that the error is linked to using Symbols without parsing them correctly. “<” is not allowed and has to be replaced with &lt. 

• The Nodes got mixed up. The following is only a warning and you are able to deploy the form on the Android, but it then won’t work on the Android. Whereas the bind nodeset and the label ref are using the same XPath, input ref shows an error and is not referencing the full XPath.

• Leaving values empty. Whereas it is ok to utilize tag <value/> if you want to leave a hint empty, you cannot leave an option value of a select question empty or you will run the risk of having a JavaNullPointerException.

• Error of omission: Carefully check your syntax, especially when copying and pasting from other forms. required="true()" was set twice.

4. Deploying the validated xml form on an Android device^[7] 

Before trying your newly created form on your mobile platform it is recommendable to test it on an Emulator first. For documentation on how to install an emulator, please refer to document emulator

• To test your form on your emulator, launch your emulator by double-clicking on SDK Manager in your android-sdk-windows directory and choose the appropriate virtual device.  Note: you will need to have ODK Collect installed on your device! Refer to ODK_How2InstallEmulator if you have not done so already.

• For copying the form on your virtual device you can use the adb command. The command is composed like this: adb push <local> <remote>. Launch the adb application (which you will find in the folder tools of your android-sdk-windows directory, please note that depending on the file version, this folder can also be called platform-tools) and type adb push YourFileName.xml sdcard/odk/forms. 

Note: If your file is not in the /tools directory where your adb shell is, you will need to add the path to your filename.

• Launch ODK Collect. On the ODK Collect main menu, click on Start New Form and you will be able to select your form.

• Uninstalling an application works the same way as it would on a real Android device: You go to Settings/Applications/Manage applications and click on the Application you want to uninstall.

• Testing on your mobile device:

• First Option: Use the same adb command.

Note: Ensure that you have closed the emulator instance or else or you will need to specify which device your command is destined for. More information on adb commands and specifying the devices can be found here:

http://developer.android.com/guide/developing/tools/adb.html

• Second Option: Install the software which has been delivered with your Android phone and drag and drop your xml file into the sdcard/odk/forms directory like you would with any other external hard drive.

• Third Option: Ensure that you have installed the USB driver in your Android SDK. If not, go to Available packages and download from there.

Connect your mobile device. Verify that you have the option Settings/Applications/Development/USB debugging ticked on your device. On the notification panel, choose option “Mount SD Card”.  Now drag and drop files from your computer to your device which has now become accessible through your Explorer. Remember to place the xml form in sdcard/odk/forms.

Refer to http://developer.android.com/sdk/win-usb.html for more information.

• Fourth Option: Place your form on a server and download it; this is normally achieved through using ODK Aggregate; the form can then be downloaded through the Manage Forms and Data menu in ODK Collect.

In theory you could be downloading a form from any server and copy/paste from the /download folder on your SD card to your /odk/forms folder. However, for this you need to have a file explorer software installed on your android, either from the Android market (ex: AND Explorer) or an inherent file explorer (ex: My Files on Samsung Galaxy) on your device.

5. Glossary

ODK        Open Data Kit (ODK) is a free and open-source set tools which help organizations author, field, and manage mobile data collection solutions. Open Data Kit is a research platform for the Department of Computer Science & Engineering at the University of Washington. More information to be found here: http://opendatakit.org/about/

OpenRosa         The OpenROSA consortium was formed in an effort to create a set of standards to allow mobile data collection tools to interoperate. More information on participating organizations and background information can be found here: http://openrosa.org/about/

JavaRosa          JavaRosa is a Java Standard Edition (J2SE) framework for building data collection applications on Java enabled devices. Javarosa-core contains the code that builds the framework. Javarosa-validator and Open Data Kit, and openXdata are examples of applications that use JavaRosa. More information can be found here: http://www.javarosa.org/ 

Note: At the time of writing, the page seems to have moved and will deprecate. The new page is hosted on https://bitbucket.org/javarosa/javarosa/wiki/Home, but has a new structure now. The policy of the new host Bitbucket (signup required for accessing some pages) has not been perused prior to writing the manual.

Java Wireless  

Toolkit        The Sun Java Wireless Toolkit (formerly known as Java 2 Platform, Micro Edition (JavaME) Wireless Toolkit) is a state-of-the-art toolbox for developing wireless applications that are based on JavaME's Connected Limited Device Configuration (CLDC) and Mobile Information Device Profile (MIDP), and designed to run on cell phones, mainstream personal digital assistants, and other small mobile devices. The toolkit includes the emulation environments, performance optimization and tuning features, documentation, and examples that developers need to bring efficient and successful wireless applications to market quickly. More information can be found here: http://www.oracle.com/technetwork/java/index-jsp-137162.html

XForm        It is a format for creating forms/questionnaires in XML. XForms are similar to forms in HTML, and are meant to be the next-generation replacement for HTML forms.

An XForm is an XML document that describes your electronic form, including what questions to ask (this also comprises the type of question and the question's caption or prompt), restrictions on the kinds of answers you can enter, and what you want your final data to look like.

XPath        XPath, the XML Path Language, is a query language for selecting nodes from an XML document. In addition, XPath may be used to compute values (e.g., strings, numbers, or Boolean values) from the content of an XML document. XPath was defined by the World Wide Web Consortium (W3C).

ODK Aggregate        ODK Aggregate provides a ready to deploy server repository to: manage collected data, provide standard interfaces to extract data (e.g., spreadsheets, queries, etc.), and integrate with existing systems via web requests. ODK Aggregate is currently implemented on Google's App Engine allowing users to avoid the difficulties of setting up their own scalable web service.

adb        ADB (Android Debug Bridge) is a tool that comes with the Android SDK which allows you to control and interface with your Android device. It is located in the tools folder when you unpack the SDK.

6. References

The following references have been consulted to compile the form used in Kenya and this manual:

Creating an ODK form:

Information on ODK in general: http://opendatakit.org/

Repository for tools and applications: http://code.google.com/p/opendatakit/

Information on ODK Build: http://opendatakit.org/use/build/

ODK Build application: http://build.opendatakit.org/

Notepad ++: http://notepad-plus-plus.org/

Sample forms: http://code.google.com/p/opendatakit/source/browse?repo=forms

Design guidelines: http://code.google.com/p/opendatakit/wiki/XFormDesignGuidelines

Explaining xml logic: http://code.google.com/p/opendatakit/wiki/XFormLogicExplained

JavaRosa Training guide: http://code.javarosa.org/wiki/buildxforms

General XML structure: http://en.wikipedia.org/wiki/XML

Validating your ODK form:

ODK Validate: http://code.google.com/p/opendatakit/wiki/ODKValidate

JavaRosa XForm Validator: http://code.javarosa.org/wiki/JavaRosa-XForm-Validator

Deploying your ODK form:

Installing SDK: http://developer.android.com/sdk/index.html

SDK Packages: http://developer.android.com/sdk/installing.html#components

Adb commands: http://developer.android.com/guide/developing/tools/adb.html#move

General information on adb: http://developer.android.com/guide/developing/tools/adb.html

USB driver: http://developer.android.com/sdk/win-usb.html

Annex: LLIN COVERAGE AND DURABILITY SURVEY

To be filled in by surveyor before the interview

To be filled in by Supervisor at the end of the day

To be filled in by data entry clerks during data entry

Introduction and Informed Consent

Hello, my name is _______________________ and I am working with _____________________ and UNHCR.  We are conducting a survey on mosquito nets in your community, and your household has been selected to participate.  We would like to ask you, the head of household, a number of questions concerning mosquito nets and their use in your household.  It will help us in programming for health activities in your community. The questionnaire takes 20 minutes to complete.  

Your participation is voluntary.  You are not under any obligation to participate and you have the right to refuse this invitation.  If at any point in time during the interview you wish to stop participating you may do so without giving a reason and with no consequences.  All information related to your participation will be kept confidential.  We hope that you will agree to participate.  

Yes I___I       No  I___I        (If no, do not continue the survey, CHECK REFUSED IN 0.6 and continue to the next selected household)

Signature of Surveyor_____________________________________________________________

SECTION 1: Interviewer: I would like to ask you some questions about the mosquito nets in your house

SECTION 2.1 Interviewer:  I would like to ask you some questions about you and  the members of your household