Skip to main content

Mobile Application

Introduction

The Mobile Application for Real-Time Management Information System (RTMIS) plays a pivotal role in facilitating remote data collection, primarily designed to support offline data submission for enumerators. Enumerators, who are an integral part of the data collection process, are assigned the responsibility of collecting critical information beyond the scope of Data Collectors. This mobile application serves as an indispensable tool, equipping enumerators with the means to efficiently gather data, even in areas with limited or no connectivity.

The Mobile Application for Real-Time Management Information System (RTMIS) is built upon a module derived from the National Management Information System (NMIS) Mobile Application (https://github.com/akvo/nmis-mobile). The NMIS Mobile App serves as a generic data collection tool designed to accommodate the needs of multiple services and organizations.

Within this context, the RTMIS Mobile Application takes center stage as a specialized module tailored to support the unique requirements of real-time data collection for management information. Specifically crafted to cater to the demands of the RTMIS, this mobile application empowers enumerators and data collectors with a targeted set of features and functionalities.

Requirements

Initial Setup

  1. Setup New Expo Application:

    • Create a new Expo application as a foundation for the RTMIS Mobile App.
    • Configure the Expo environment with the necessary dependencies.

  2. Integration from nmis-mobile Repository:

    • Copy the entire app folder from the nmis-mobile repository to the RTMIS repository.
    • Ensure that the integration includes all relevant code, assets, and configurations.
    • Make the necessary modifications to the module to align it with the specific requirements and functionalities of the RTMIS back-end.

  3. Docker Compose Setup for Development:

    • Implement Docker Compose setup to enable seamless development of the Mobile App within the RTMIS project.
    • Integrate the Mobile App into the RTMIS development environment to ensure compatibility and ease of testing.

  4. Authentication Method Enhancement:

    • Implement changes to introduce a new and improved authentication method for the RTMIS Mobile App.
    • Ensure that the new authentication method aligns with the security requirements and standards of the RTMIS project.
    • Update relevant documentation and user instructions to reflect the changes.

  5. CI/CD Setup for Mobile App Deployment:

    • Establish a robust CI/CD pipeline for the RTMIS Mobile App, enabling automated deployment to the Expo platform.
    • Configure the pipeline to trigger builds and deployments based on code changes and updates to the Mobile App repository.
    • Ensure that the CI/CD setup includes proper testing and validation procedures before deploying to Expo
  6. Integration of Django Mobile Module:
    • Incorporate the Django mobile module from the National Wash MIS repository folder: v1_mobile into the RTMIS back-end.

System Enhancements and Modifications Overview

To support the integration of the mobile application, several critical updates are required for both the RTMIS platform's back-end and front-end components. These modifications encompass a range of functionalities designed to seamlessly accommodate the needs of the mobile application. Key updates will include, but are not limited to:

Back-end

  1. Authentication and Authorization API for Mobile Users:

    • Integrate automated pass-code generation functionality to generate unique 6-digit alpha-numeric pass-codes for multiple mobile data collector assignment.
    • Establish an API mechanism to authenticate and authorize mobile users based on a pass-code. This ensures secure access to the RTMIS platform while simplifying user management for mobile data collectors.

  2. Form List and Cascade Retrieval API:

    • Develop Cascade SQLite generator for both Entities and Administration.
    • Implement an API that enables the mobile application to retrieve forms and cascades from the RTMIS platform. This functionality is vital for data collection activities performed by enumerators and data collectors in the field.

  3. Data Monitoring API:

    • Modify data/batch submission-related models and API to support monitoring submission.
    • Modify approval workflow-related models and API to support monitoring submission.

  4. Data Synchronisation API:

    • Make the necessary modifications to the v1_mobile module to align it with the specific requirements and functionalities of the RTMIS back-end:
      • Preload existing data-points.
      • Modify Mobile Form submission-related models and API to support monitoring submission.

  5. Data Entry Staff Data Editing and Approval Workflow:

    • Develop functionality for Data Entry Staff to add Mobile Assignments. The Data Entry Staff user can have multiple mobile assignments, which will require village ID and form ID. When a mobile assignment is created, it will generate a pass-code that will be used by Enumerators to collect data in the field via the Mobile App.
    • Develop functionality for Data Entry Staff to edit data submitted via the mobile application.

Front-end

  1. Dedicated "Mobile Data Collectors" Section:

    • Create a dedicated section within the RTMIS front-end, labeled "Mobile Data Collectors," where Data Entry Staff can easily access and manage mobile data collector assignments.

  2. "Add Mobile Data Collector" Feature:

    • Implement a user-friendly feature within the "Mobile Data Collectors" section that allows Data Entry Staff to initiate the process of adding mobile data collectors.

  3. Assignment Details Form:

    • Develop a user-friendly form that Data Entry Staff can use to input assignment details:
      • the name of the assignment
      • Administration village selection
      • and form(s) selection.
    • Once the Data Entry Staff presses "create," the back-end will process it and return a 6-digit Alphanumeric code that will be used for mobile authentication.

  4. Communication of Pass-codes:

    • Provide a mechanism within the front-end that allows Data Entry Staff to easily communicate the generated pass-codes to the respective mobile data collectors.

  5. User Guidance (RTD Updates):

    • Include user guidance elements and feedback mechanisms in the front-end to assist Data Entry Staff throughout the process, ensuring that they understand the workflow and status of each assignment.

Mobile App

  1. Mobile Database Modification
    • Modify the Database Schema to support Monitoring and Cascade Sync Updates
    • See more details about Mobile Database Modification
  2. Mobile UI Modification
    • Develop a screen where user can see and sync the list of existing data-points
    • Develop a screen where user can choose to add new data-point or edit existing data-point
      • NMIS-sync.png
    • See more details about Mobile UI Modification

Database Migrations

Mobile Assignment Schema

Mobile Group (for Later)
  • Table name: mobile_assignment_group
  • Model name: MobileAssignmentGroup
pos column null dtype len default
1 id No Integer - (Auto-increment)
3 name No Text 6 -
4
 created_by



Mobile Assignment Table
  • Table name: mobile_assignment
  • Model name: MobileAssignment
pos column null dtype len default
1 id No Integer - (Auto-increment)
3
 name No Text 255 -
4
 passcode No Text 6 (Auto-generated)
5
 created_by
 No
 Integer
 -
 (Primary Key)

Explanation: The MobileAssignment table stores information about mobile data collector assignments. The id column serves as the primary key and a unique identifier for each assignment. The name column holds the assignment's name or description, while the passcode column stores a unique pass-code for mobile data collector access.

Mobile Assignment Form Administration Table (Junction):
  • Table name: mobile_assignment_form_administration
  • Model name: MobileAssignmentFormAdministration
pos column null dtype len default
1 id No Integer - (Auto-increment)
2 assignment_id No Integer - -
3 form_id No Integer - -
4 administration_id No Integer - -

Explanation: This table serves as a junction table that establishes the many-to-many relationship between mobile  assignments (MobileAssignment), forms (form_id), and administrative level (administration_id). The id column remains as the primary key, and the other columns associate the rows with the respective assignment, form, and administrator.

Form Updates

New Question Type: Data-point Question

This new question type is similar to an option-type question, but instead of custom options created by the user, the options will be populated from the "data-point-name" field in the data table (refer to: https://wiki.cloud.akvo.org/books/rtmis/page/low-level-design#bkmrk-database-overviews).

Requirements:

  • New API for Web-form which retrieve list of data-point based on the user token to filter the data-point list
  • SQLite generation for the data-point list, the SQLite generation cycle will triggered when data is approved.
  • File format for the SQLite: "/sqlite/<form_id>-<administration_id>-data.sqlite"

Parameters:

  • Name: type
  • Type: Enum
  • Enum Name: data_point

New Question Parameters: Display Only

The "Display Only" parameter is a helper that can be used to display a question for which the answer should not be sent to the server. The "Display Only" parameter is used to assist users in running data calculations, dependency population, or auto-answering for other questions.

Example use case:

  • Q1: Do you want to update or create new data?
    • When the answer is "yes," Q2 and Q3 appear.
    • When the answer is "no," Q2 and Q3 do not appear.

Requirements:

  • The "Display Only" question parameter shall be defined as a feature in the survey/questionnaire creation tool.
  • The primary purpose of the "Display Only" parameter is to allow the inclusion of questions in a survey for informational or display purposes only.
  • The survey tool shall include appropriate error handling mechanisms to prevent "Display Only" questions from being treated as regular questions during data processing.

  • This will not become a part of a bulk template, and data download

Parameters:

  • Name: displayOnly
  • Type: Boolean

Mobile UI Modifications

User Story

1. User Authentication

1.a. When there's no user in the users database:

  • Open App
  • Login with the user pass-code
  • Store token (response from server) to users table and state
  • Fill the information about the user in users database from the server response. Unlike the previous version, in this version, the logged in user CANNOT fill the user information themselves.
  • Form list opened

1.b. When user is available in the users database:

  • Open App
  • User selection page opened: on the bottom of the page, there should be a button for adding new user
  • User click add new user
  • Login with the user pass-code
  • Store token (response from server) to users table and state
  • Fill the information about the user in users database from the server response. Unlike the previous version, in this version, the logged in user CANNOT fill the user information themselves.
  • Form list opened
2. Download Data-points (for monitoring)
  • Open App
  • User selection page opened
  • Select the user from user list
  • Press download data
  • Server will give the list of data-points which can be downloaded 
    • [{
  "id": 1,
  "updated_at": 1701070914356
},{
  "id": 2,
  "updated_at": 1701070914356
}]
  • Mobile download the data-points 1 by 1 (queue) and store it to datapoints database
    • Before download, check if the datapointId is exist in the datapoints database
    • And compare:
      • If updated_at > createdAt (in datapoints table): Replace the datapoint
      • If updated_at < createdAt (in datapoints table): Don't download
    • User will get notified when:
      • server send error response
      • download is finished

Mobile Database Modifications

1. Form Database

Table name: forms

Column Name
 Type
 Example
id
 INTEGER (PRIMARY KEY)
 1
userId
 INTEGER
 1
formId
 INTEGER
 453743523
version
 VARCHAR(255)
 "1.0.1"
latest
 TINYINT
 1
name
 VARCHAR(255) 'Household'
json
 TEXT See: Example JSON Form
createdAt
 DATETIME
 new Date().toISOString()

Changes:

  • Add userId column to (from users database), so every form has owner.
2. User Database

Table name: users

Column Name
 Type
 Example
id
 INTEGER (PRIMARY KEY)
 1
active TINYINT 1 (default: 0)
name
 INTEGER
 1
password
 TEXT crypto
token
 TEXT
 token

Changes:

  • Add token column to store (token from authentication response)
3. Form Submission / Datapoints Database

Table name: datapoints

Column Name
 Type
 Example
id
 INTEGER (PRIMARY KEY)
 1
formId
 INTEGER
 1 (represent id in forms table, NOT formId)
userId
 INTEGER 1 (represent id in users table)
submitter
 TEXT
 'John'
name VARCHAR(255) 'John - St. Maria School - 0816735922'
submitted
 TINYINT 1
duration
 REAL
 45.5 (in Minutes)
createdAt
 DATETIME
 new Date().toISOString()
submittedAt
 DATETIME new Date().toISOString()
syncedAt
 DATETIME
 new Date().toISOString()
json
 TEXT '{"question_id": "value"}'

Changes:

  • userId should be NULLABLE when form submission data is synced from RTMIS database sync
  • Add submitter column


Back to top