Mesh4x goes mobile with JavaROSA, allows you to sync data on your handset with no Internet

posted on: October 28, 2008

The latest batch of advances in mesh4x and JavaROSA allows you to do forms-based data input and editing on any java-enabled phone and synchronize with other phones or a server.

JavaROSA forms UI, in action. I'm in ur phonez, filling formzYou can define a generic form, load the form definition to any  java-enabled cell phone loaded with the JavaROSA forms clients extended with a mesh4x transport component, do data entry in your phone and synchronize the data 2-way with a server or directly peer-to-peer with another phone handset.

all types of sync options The form definitions are saved and exchanged as XForms, and the data as XForm models. The data can be exchanged over http (if the phone users can afford GPRS and have a data connection) or over compressed SMS messages. This can even happen between phones directly – you enter the phone number of another handset running the app and press “sync”. Tondat describes this in detail in his latest blog post. The clients depicted here look awful on the emulators as they use J2ME Polish (, which then makes the app look great on specific handset models and adapts the UI to the capabilities of each phone.

This extends the scenarios of JavaROSA- from data-entry bringing it closer to a collaboration tool, where the information being entered can be edited by multiple users and shared from a central database back to the phone in the field.

This contrasts with “data collection” pattern of data entry solutions…if you believe information is power, data collection creates a vast vacuum cleaner shifting the balance of power: away from those in the field who understand the data the best and can act on it the soonest, towards the center. But does it need to be this way?

At InSTEDD we look at information flows such as those and ask  people working in health in developing countries spend a large proportion of their time filling in forms that then go somewhere. What information would they want in return? ourselves: What information should be flowing back to the field? How can the person at A work better with the person at B beyond just sending data? How do we shift from ‘sending’ data to sharing realtime and enriched information two ways? The mesh4x + JavaROSA effort is addresses some of these questions.

This was made possible through a collaboration and set of code contributions we had with the JavaROSA team. JavaROSA is an implementation of OpenROSA which could become a strong player in the mobile data gathering and sharing space in the near future. Kudos to Clayton Sims, Jonathan Jackson, Andreas Kollegger, and everyone else from the javaROSA team for your work and friendly attitude!

The XForm definitions are stored in an http service behind a REST API ( which is a strawman of a mesh4x cloud-based service. If you played with our map-sync technology you have already used this service).

kind of like this

Next Steps

Our strategy with mesh4x is to contribute code to existing projects being deployed in the field that need 2-way synchronization, data exchange over SMS, or multi-master storage based on standards. Episurveyor, Gather, Pendragon etc come to mind.

Within this directive, our roadmap on mesh4x will involve effort in four areas:

  • Cloud Services
  • Data Standards
  • Client Applications
  • Transformers and Adapters

1. Cloud Services: A scalable server implementation supporting security standards . We have a skeletal solution built in C# that we grew from the ‘sse’ open source project in Codeplex, (which has moved to as well). We host an instance at But it uses a relational database, so we Amazons web services include VM Hosting (EC2) Storage (S3) and Message Queuing (SQS)would have to change the storage layer if we wanted to grow it    for real. So what are our options? Java on EC2/S3  seems to be the shortest path given the code Google App Engine - coolest logo in town!we already have in the project, but Python on Google App Engine sounds enticingly simple to  maintain and scale, at the expense of initial effort to port the sync libraries to Python. Which seems a unnecessary until you consider that Inveneo, the African Access Point and other platforms prefer Python or Ruby for a bunch of good reasons. We’d like your input – .NET+MySQL, Java, or Python + GAE?

2. Default Data Exchange Standards: Using XForms is simple and works for easy scenarios.  this fun little thing looks like an RDF triplet, of sorts.We’ll advocate use of RDF when XForms will fall short, but by all means we wanted to avoid a custom/ad hoc way of defining a typed dictionary ‘schema’, versioning of that schema, and of encoding entities following the schema.

Following a clear set of standards for data formats will allow easier mapping of information from one system to another, and the creation of tools that allow end-users to define how their systems integrate.

Isn’t this obvious? Defining which standards to support early in the process is critical because it is easy to reinvent the wheel in this space. Even accidentally. Anyone who can code their way out of a paper bag can define a custom way of serializing dictionaries (a collection of names and values such as name:Ed, country:Cambodia) and define a schema model for it in an hour or so. But inventing one just tends to lead to incompatibilities in the long run, and lack of interoperability in humanitarian systems is an obstacle that anyone with experience has seen get in the way of collaboration and data sharing. It is much smarter to support a well documented subset of a standard such as RDF or XForms -and define extensions as needed (both standards allow schemas/ontologies to be extended). If we can we pledge to play along, applications from multiple organizations will add up to be ‘more than the sum of the parts’

3. Client Applications: We desperately would like to implement or contribute to a stand-alone fat (aka rich) client that you can use on your desktop to synchronize two data endpoints. Ideally this client would allow you to set the endpoints for synchronization, mapping of data schemas, filters, and managing conflicts – in a secure and easy-to-use interface. Any pointers?

4. Transformers and Adapters: There are many existing applications out there that do their work very well. Sometimes two applications serve similar purposes for different audiences or contexts. Sometimes new applications have to coexist with politically entrenched older systems. While we are building common-purpose adapters to mesh4x (such as Hibernate, Java RMS, and KML which we already have but also CSV and google spreadsheets for example), we already hear demand for specific adapters that take into account particular needs of real-world applications that are already deployed in the field. Which systems should we start with? We have been approached with questions about mesh4x and OpenMRS ( or Sahana ( 

We’d love your input!

Comments are closed.

View more of InSTEDD's blog posts.