Namespaces

Variants
Actions

Please note that as of October 24, 2014, the Nokia Developer Wiki will no longer be accepting user contributions, including new entries, edits and comments, as we begin transitioning to our new home, in the Windows Phone Development Wiki. We plan to move over the majority of the existing entries over the next few weeks. Thanks for all your past and future contributions.

Notification API and location service for localized heath training

From Wiki
Jump to: navigation, search

This article explains how to use the Nokia Notification API and Location service to create locally relevant health applications on Nokia Asha software platforms in Java ME. The article does not explain the Notification API or Location Service in detail, but instead provides a brief introduction with links to key resources.

Warning.pngWarning: This article is primarily a concept overview/UI prototype. The concepts outlined are not implemented in the code samples.

Note.pngNote: This is an entry in the Nokia Asha Wiki Competition 2013H2.

Article Metadata
Code ExampleTested with
SDK: Nokia Asha SDK 1.1(beta) or Nokia Asha SDK 1.0
Devices(s): RDA: Nokia Asha 501, Emulator: Nokia Asha 503.
CompatibilityArticle
Created: adarsha_saraff (21 Nov 2013)
Last edited: hamishwillee (16 Dec 2013)

Contents

Introduction

Sometimes health institutions, government, or charity organizations conduct medical camps - for example to manage relief efforts during a natural or man-made disaster, or in order to manage collection of blood. The key to the success of these camps is to ensure that both those in need of support and those that might like to give help receive timely notification of where the camps are located, and what they offer.

This article describes an app and service for registering to receive notification of medical camps in the user's area. As Nokia Asha devices are inexpensive, this approach provides a simple mechanism for notification of relevant health information that most users could afford.


Architectural overview

The service has a number of parts, as shown in the diagram below. The developer has to create two of them:

  • Mobile app which can be downloaded through Nokia Store.
  • A Service server which pushes the notifications to desired users through Nokia Notification server.

The client app registers with the Notification Server and gets a notification ID token which can be used to send it messages. The app sends this token to the developers' Service Server (along with other app specific information) - the Service server can then send messages to the app as needed (in this case alerts about health camps)

Life cycle of Application

The app/service lifecycle is described below:

  1. The app then registers with the Notification Server and gets the Notification ID token.
  2. The app sends Notification ID to the Service server, along with other app relevant information like the user location, and types of camps they are interested in
  3. Camp organizer creates a camp event with the help of Service portal provided by Service server.
  4. Server sends notification to Nokia Notification server specifying the IDs to receive the message. In this implementation the Service Server determines the users to notify based on:
    • User's preference.
    • Camp priority and type.
    • User's location. i.e how near the user resides to the camp.
  5. Nokia Notification Server delivers notification to the app user.


Overview of Notification API

The Nokia Notification API and Notification life cycle is well documented in the Java Developers' Library and the article Nokia notifications on the Asha software platform.

The Nokia Notifications API makes it easy to add real-time push notifications to MIDlets running on Nokia Asha software platform devices. It has the following features:

  • Nokia Notifications Client API — Register the MIDlet to receive notifications from the notification service that is coupled with the MIDlet.
  • Nokia Notifications Service API (REST API) — Sends notifications to the MIDlet from the notification service without a direct connection between service and device.


Registering for Notification Service

First register your app with Notification API developer console. You need to acquire 3 required credentials before integrating it into your application:

  • service id
  • application id
  • service secret


Client development

Client development is described in the Java Developer's library. The Nokia Notifications Client API allows MIDlets to receive notification state changes, notification information and notification messages.

To use the Nokia Notifications Client API in your MIDlet, you need to do the following:

  1. Open a session.
  2. Register the application.
  3. Retrieve the Notification ID and send to your server.
  4. Handle Incoming Notifications.

Service development

Service development is described in the Java Developer's library.

The Notifications Service API provides access to the Notification Server through an HTTP REST interface. REST API is platform and programming-language independent. Your Service server can be developed using any preferred environment and tools.

Overview of Location Service

In Nokia Asha software platform locations of user are calculated using:

  • Cell ID
  • Wi-Fi positioning.

The Location API is an sensitive API and should be run on a separate thread.

new Thread() {
public void run() {
LocationProvider myloc;
int[] type = {Location.MTE_CELLID | Location.MTY_NETWORKBASED | Location.MTA_ASSISTED};
try {
myloc = LocationUtil.getLocationProvider(type, null);
javax.microedition.location.Location Loc = myloc.getLocation(300);
if (Loc != null) {
QualifiedCoordinates cor = Loc.getQualifiedCoordinates();
lat = cor.getLatitude();
lon = cor.getLongitude();
System.out.println("Latitude:"+lat);
System.out.println("Longitude:"+lon);
}
} catch (Exception ex) {
}
}
 
}.start();

Note.pngNote: Asha 501 supports only Cell ID location information while Asha 500, Asha 502, and Asha 503 support both Cell ID and Wi-Fi positioning.

Development

Mobile App

The mobile app gets the user's information, registers with the Notification Server, and registers with the Service Server providing the Notification ID and gets notification about health camps from server.

The app should be simple to use. It can have the following features:

  • An interface which allows the user to subscribe and get register with the service server.
  • An interface that list all the upcoming camps details received through notification payload.

Payload data can be stored locally in the device using RMS.

Demo

The demo app screenshot is shown below. Note that this only shows the UI - server registration etc has not been provided. The implementation is up to the reader.

User preferences

Service Server

The Service server is responsible for storing user details and notifying desired user(s) based upon the user's preferences and location.

The Service Server will have a database system to store all the user preference and their app Notification ID. It should map geo-coordinates into place names and store them in hierarchy of subdivision of the country.

Lastly it will have a service portal which will allow the camp manager to specify camps and notification.

The design and implementation of Service server is also left to the user.

Service Portal

The Service portal is used by the camp organizer to schedule camps and send notification to desired users. Picture below shows the design of a simple web portal.

Simple web portal to create new camp.

The portal interacts with the service via an API defined by the Service Server.


Demo

Demo service portal application is build using Java. It is developed on the example of service development from Java developer's library.

Warning.pngWarning: This demo application doesn't implement the design concepts explained above.

Screenshots

Scope

Use of Nokia Notification in not only restricted to this. The same concept can be extend to various fields of Health care. Some of them are:

  • In medical stores to remind the refill of chronic medication practice for regular customers.
  • In hospital to remind the next appointment or next regular test for chronic disease patients.
  • Service portal for doctors.

Summary

The development of this type service portal not limited only to this. It can be extend in all directions. However, design and development of service server should not be generalized. Implementation of server should be done based on country. Country will have different type of hierarchy of subdivision.

Source

This page was last modified on 16 December 2013, at 04:43.
487 page views in the last 30 days.

Was this page helpful?

Your feedback about this content is important. Let us know what you think.

 

Thank you!

We appreciate your feedback.

×