As of late 2017, the main objectives of the DHIS2 Android development team are:

  • 1. To build a new generation DHIS2 Android App which responds to the needs of the DHIS2 community - the primary
    aim is to support the work of mobile health workers.
  • 2. To make a robust, well documented DHIS2 Android SDK available to the developer community, so others can build
    innovative apps that use DHIS2 as the underlying platform.
  • 3. To maintain the current generation of apps: we will guarantee compatibility with DHIS ‘current’ version* and
    up to two previous versions for the current apps, until they are replaced by the new app.

SDK Development

The intention of building a DHIS2 Android SDK is to allow organizations with different needs or approaches to build their
own Android apps in response to their functional requirements.

Users Community

DHIS2 Android SDK Architecture

Key components:

  • Stores: responsible for persistence of a particular database model.
  • Retrofit services: abstraction over DHIS2 API.
  • Database handlers: responsible for synchronizing in-memory representation of models to the database.
  • Calls: consume retrofit services and database handlers. This is the actual process of syncing.

Two sets of models:

  • API model: represents views into DHIS2 REST API. They reflect what API provides us.
  • Database model: reflects database tables and their structure.

The main motivation for having different models is to decouple the structure of the database from the API representation of data. For example, it is quite normal to have collections in API, while in databases there is no such concept. Both sets of models are immutable, which guarantees that the state of the objects is not altered during runtime.

Design Goals

  • Performance: solution should scale to work with arbitrary sized DHIS2 instances.
  • Full access to the underlying database.
  • User interface widgets (view components).
  • Ability to have multiple databases within one application.
  • Integrating data between apps on one device (shared database).
  • Guarantee data integrity / health of the database.
  • Provide flexibility to do analytics on local devices.

Low level android APIs are targeted, in order to use as low an amount of resources as possible. This is especially important for low-end devices, which have only 32mb of RAM per process.

You can follow the SDK development in github.