Skip to content

Documentation

Nicolas Himmelmann edited this page Jul 29, 2018 · 13 revisions

Architecture Overview

vStore Architecture

[TODO NICO] Ich glaube, die Grafik müssen wir in zweierlei Hinsicht anpassen: (Könntest du mir eine editierbare Version der Grafik schicken?)

  1. "Aware" ersetzen durch etwas generischeres wie "Context Provider"

  2. Der neue zentrale K/V-Store muss rein. Im zuge dessen, würde es sinn machen das mit dem Block "Configuration File" zusammen zu legen?

The general architecture of vStore and its interfaces can be seem in the above figure. The main components of the framework are:

ContextManager

This component is responsible for storing new usage context and to provide interfaces for deleting and retrieving the current usage context. The external application should use this component when providing new context information to the framework, mainly when context conditions have changed.

The actual context data has to be provided from the application. This ensures a real platform-independence. An example implementation of a context aggregator for Android devices can be found in the code of the demo application vstore-android-filebox. It uses the AWARE framework and plugins, as well as the Google Places API.

Currently, the following context types are implemented:

  • Location: The physical location represented by latitude and longitude, and a timestamp.
  • Places: The large amount of different place types possible are represented by 3 groups: points of interest (POI), event (such as stadiums, city halls and night clubs) and Social (such as restaurants, cafes and bars).
  • Activity: The user's physical activity. Denotes if the user is sitting still, walking, driving or if the activity is unknown.
  • Network: The network context can currently consist of a WiFi context or a cellular network context.

Rules

Matching engine

To make it all work, you need the following things besides an instance of the framework:

  • Master Node:
  • Configuration:
  • Storage nodes:
  • Context providers:

Interfaces (Hier die interfaces nach außen beschreiben. Für context, store/get und die API zu den Storage Nodes)

Application (store/get)

Context providers

Storage API

Error Codes

  • BASE_DIRECTORY_DOES_NOT_EXIST
    • The working directory given as parameter to the framework does not exist.
  • COPYING_INTO_FRAMEWORK_FAILED
    • Copying the given file into the framework directory failed.
  • URI_SCHEME_NOT_SUPPORTED
    • The given URI has a scheme which is not supported.
  • FILE_ALREADY_EXISTS
    • The file to be stored already exists.
  • PARAMETERS_MUST_NOT_BE_NULL
    • The parameters of the method which returned this error must not be null or empty.
  • USAGE_CONTEXT_MUST_NOT_BE_NULL
    • The given usage context must not be null.
  • REQUEST_NOT_STARTED
    • A network request could not be started.
  • DB_LOCAL_ERROR
    • An error occurred while using the local sqlite database.
  • CONFIG_CONNECTION_FAILED
    • While downloading the configuration, a connection error occurred.
  • CONFIG_DOWNLOAD_FAILED
    • The download of the configuration file has failed.
  • CONFIG_PARSE_ERROR
    • Parsing of the configuration json string has failed.
  • FILE_NOT_FOUND
    • The given file cannot be found. Maybe the path is wrong.
  • MASTERNODE_WRONG_RESPONSE
    • The master node sent a wrong response.

Status Events

The framework uses GreenRobot EventBus, to post different status information to the application. All events are listed and explained under this section.

Clone this wiki locally