Client Architecture: Conceptual Overview

The client application is the part of solution which runs on mobile devices. In general Android applications consit of the following elements:

• Foreground Activity (Class with processes wihich run in the foreground and enable user interaction - User Interface)
• Background Service (Class with processes which run in the background and exchange data with foreground activity and other services)
• Intermittent Activity (The processes which can be modified directly by user and run in the background after user's modifications)

In case of solution for motion determination the main client's task is to retrieve the values from acceleration sensor. Optionally, in case we want to enable automatic emergency call with location report, the client has to determine the location by simply reading GPS values or getting the information from available web services which are able to determine the approximate location by base station the phone currently uses. In order to enable storing informations for later motion analysis in case the internet connection is unavailable, we can add the database and the logic for data storing and later retrieval before sending.

The picture represents the client application concept. The red rectangles represent activities and blue are the services. The application consits of three dialogs: main dialog, login and settings. The main dialog displays current activity status, acceleration values and location informations. On application start the user has to sign-in to the server with username and password so at the beginning the login dialog appears. Some options modifications such as enable/disable location report are possible by using Settings dialog.

There are four services running in the background . The Location Service retrieves the location informations and broadcasts the location data which are received at main (GaitLink) activity, Communication Service and optionally at Database Service. The Acceleration Service retrieves the data from accelerometers and also broadcasts the data which are received by the same components. The Database Service listens for the broadcasted messages which can represent the data that have to be stored or the commands for data reading and sending to Communication Service.

Communication Service implements multiple threads. Broadcast Receivers for acceleration and location messages run in separate thread. Every received message is sent to queue. Another thread is periodically retrieving the messages from queues and send the messages to the server. In order to prevent queue congestion the reading frequency has to be higher than queue writing frequency. The main reason for using queues are possible transitory network delays or drops. Without intermediate measurements storing to the queue every value would have to be successfully sent before reading next values from the sensors which is certainly fair too unreliable.