wiki:BluePrint/CAPMobileApp

Version 19 (modified by Lutz Frommberger, 9 years ago) ( diff )

--

SAMBRO Mobile Application

Table of Contents

  1. Introduction
  2. Stakeholders
  3. User Stories
  4. Requirements
    1. Functional
    2. Non-functional
    3. Interoperability
    4. Standards
    5. System Constraints
  5. Design
    1. Data Model
    2. Workflows
    3. Site Map
    4. Wireframes
    5. Technologies
  6. Current Implementation
  7. Planned Implementation
  8. Future Extensions
  9. Outstanding Questions
  10. References

Introduction

The app is supposed to be a mobile app to issue alerts for several hazards to be included into SAMBRO/Sahana.

The app will complement the web based GUIs for issuing alerts to enable a mobile solution even working in areas with weak internet connectivity.

An existing similar solution is ​mobile4D, a bi-directional hazard reporting and alerting tool developed at the Capacity Lab at the University of Bremen.

Stakeholders

<Who will be the users of the solution?>
<Who else will be affected by this solution? eg. Developers, Users of Existing Functionality that may be changed?>
<How will stakeholders be affected?>
Tip: Engage these stakeholders in the development of your BluePrint.

User Stories

An authorized user finds himself in a situation where he/she is in the need to issue an alert, but does not have access to a computer or/and a sufficiently stable internet connection. The user can now use the app and fill in the data via a structured interface. After confirming the data, the app takes over and sends the data to the Sahana server as soon as internet connection is available again without the user having to take care of it. (Alternatively, the app uses SMS to send the data. This is transparent to the user.)

Requirements

<Group requirements in subsections, e.g. etc.> <​http://en.wikipedia.org/wiki/Requirements_analysis requirements> <Identify different types of requirements:>

Functional

  • Simple interface
  • step by step input
  • must work without internet connectivity
  • alerts are a buffered and automatically sent as soon as the internet connection comes up again
  • satisfies a subset of CAP

Non-functional

​http://en.wikipedia.org/wiki/Non-functional_requirements

Interoperability

Standards

  • Results are sent out in CAP

System Constraints

The system has to be operational by late March.

Design

<Where relevant include alternative design options>

Data Model

(e.g. EER or class diagrams)

Workflows

<Diagrams or Pseudocode>

Site Map

<for User Interface solutions>

Wireframes

<for User Interface solutions>

Technologies

Current Implementation

Currently, there is no implementation within Sahana Eden.

  • Step 1. Test the current SAMBRO GUIs for its responsiveness to mobile handhelds. If necessary suggest some GUI tweaks to harmonize the desktop version with the mobile screens.
  • Step 2. Design hazard specific alert authoring and issuing GUIs. For example, Alerting Authorities, in a local area (Barangay, Gramaniladari, Thaluk, etc) do not need the full CAP message but a few attributes like the area and water level. We will target on delivering 3-5 mobile GUIs for Landslide, Flood, Accident,
  • Step 3. Develop the requirements/design for using the concept of Pictographs in Alerting and other features such as a wake up function to sound an Audible Alarm etc. I think we should do the same with the web GUI such that we can set a siren audio to sound for a specific warning_priority threshold.

We may have to look for funding outside of the ESCAP project for step 3.

Planned Implementation

To meet the time constraints given above, the plan is as follows:

  • Use a stripped-down version of the mobile4D mobile client (for Android)
  • enhance the functionality by the needed report types not supported yet
  • have the client deliver valid CAP directly from the device (the current implementation uses the mobile4D protocol and converts this to CAP server-sided)

The current functionality includes:

  • Send hazard reports:
    • filling in needed fields (numbers, contact details, urgency, etc.)
    • detect the current location
    • alternatively give a location and specifying a polygon on a map
  • Buffer issued reports and re-send them upon network connectivity.
  • Retrieve alerts and display them as list and map. This will most probably not be included.
  • Many more communication features that might not be included either.

Future Extensions

  • Send SMS when no TCP/IP network is available.

Outstanding Questions

  • Photos: does CAP support photos? Should photos be sent from within the app?

References

Note: See TracWiki for help on using the wiki.