Saturday 5 March 2016

It's all in the application: Recon Instruments Snow 2 vs Paragliding: Part 7

Continued from Part 6

A refactoring we will go.

In an attempt to better segregate the data provision from the data consumption, I've moved the process of flight data collection and broadcast into a service running under its own thread.

Providers


The initial source for the raw flight data (referred to as Channels) are the Providers which are invoked by way of either system callback or periodic runnable.

There are three groups of providers:

  1. Android Generic - Internal GPS and Battery.
  2. Recon Specific - Sensors and Head Orientation.
  3. Test.
The Providers all derive from the abstract Provider class and are expected to implement start/stop, the (de)registration of client, and configuration information (identification and channels supported).

Providers
*Note: At the time of this writing, the Head Orientation Listener does not go through the following flow - it is instead part of the composition of the Compass Display (due to the need for minimal latency).

Multiplexer


As Channel data is received by each provider, it is fed to the registered client of the provider. In this case, each Provider shares the same client - the Message Multiplexer. When more than one Provider is a source for a single Channel, the Multiplexer determines from which Provider the Channel will be ultimately sourced.

Providers are ranked based on registration order - earlier Providers getting priority over later registrants.

When a Channel arrives at the Multiplexer, we first check to see if the Channel has already been reserved by a Provider. If so, is the current Channel Provider of higher priority? If yes, now adopt this Provider of the Source and pass on the Chanel Data. If no, do nothing. If the Channel is not reserved, then adopt and pass on the Channel to the Client.

Providers also have the ability to deregister their reservation of a Channel in the event they go offline.  If the Provider has a Channel reserved in the Multiplexer and sends a channel failed message, the reservation is cleared and we treat the channel as unreserved.

Cache


As Channels pass through the Multiplexer, they are stored in the cache until such time as the Flight Data Service can bundle and broadcast them.

Multiplexer and Message Cache

Flight Data Service


Containing this whole system is the Flight Data Service. It is a simple extension of the standard Android Service with the addition of its own thread of execution. The Service periodically (every 0.5 seconds) bundles Channel data stored in the Message Cache into an intent and broadcasts it.

Flight Data Service
The Data Service contains the Providers, which the Service registers with the Multiplexer. The Multiplexer is then in turn registered with the Message Cache. The Providers are then started and Channel data is bundled and broadcast for the Displays to consume.

Refactor Continued ...

No comments:

Post a Comment