The figure below illustrates the overall runtime architecture of CARP Mobile Sensing (CAMS). The architecture consists of three main layers:
LayerMain responsibility
RuntimeThe main runtime layer of CAMS - orchestrates the client manager with study controllers, device managers, controllers, and registries.
InfrastructureProvides different services for deployment, background sensing, persistence, data management, and sampling packages.
PluginsA set of Flutter plugins used by CAMS for accessing the operating system (OS), online services, and connected BLE devices on Android and iOS.
This architecture is designed to achieve the non-functional software architecture goals of being highly extensible, cross-platform, and maintainable.
carp_mobile_sensing_architecture

​
Runtime

The runtime layer is the main entry point to CAMS and holds the client manager, study controllers for each running study, device managers, and a set of controllers and registries.
ComponentRole
SmartPhone ClientManager *The main entry point to CAMS. The client manager holds references to its deployment service, the device controller, and the client repository, which again holds the set of running studies.
Smartphone StudyControllerA study controller is created for each study added to the client manager’s repository. The study controller is responsible for handling the study on runtime. It collects data via its deployment executor and sends it to to its data manager for storage or upload.
DeviceController *Controls all primary and connected devices during runtime. For each device available on the phone, there is a DeviceManager for it, such as the SmartphoneDeviceManager.
DataManagerRegistry *Registry of available DataManager implementations.
AppTaskController *Manages AppTask lifecycle and queueing.
NotificationManager *Handles OS-level notifications.
SamplingPackage Registry *Registry of available SamplingPackage implementations.
DataTransformer SchemaRegistry *Registry of available DataTransformerSchema mappings.
All classes marked with * are singletons and can hence be accessed throughout the app.
The general flow of execution of a study is:
1
The SmartPhone ClientManager is configured by specifying deployment service, device controller, and runtime options.
2
Studies can be added, which creates and hosts a SmartphoneStudyController per study.
3
A study can be deployed. This entails that the study deployment is fetched from the deployment service and added to the study controller. The study deployment described what data to collect and which data manager to use for data upload and/or transformation.
4
Once a study is deployed, data sampling can be controlled by resuming or pausing all studies in a client. This can also be done per study, by using the resume and pause methods on the SmartphoneStudyController.
5
The data sampled is stored or uploaded by the data manager associated with a study (as available in the study controller).
Since CAMS keeps the state of data sampling persistently across app restart, you only need to follow the flow above once when you add a (new) study. Once a study is added and deployed, the runtime status of the study is saved and is restored automatically when the app is restarted (e.g., based on a OS-level kill of the app). Read more about background sensing.

​
Infrastructure

The infrastructure layer holds a set of services for getting study deployments, collecting data, and storing it. The most important part is the set of sampling packages, which are described in more details in this scientific paper.
ComponentRole
DeploymentServiceHandles study deployment configurations for the client. CAMS comes with a build-in SmartphoneDeploymentService (default) which are used for apps that only runs local deployments. The CarpDeploymentService is an CAWS-specific implementation of theDeploymentService interface.
DataManagerData Managers know how to store, save, or upload data, such as the SQLiteDataManager or the CarpDataManager.
SamplingPackageA sampling package contains support for data collection of measures on specific device.
CAMS comes with two built-in sampling packages (DeviceSamplingPackage and SensorSamplingPackage), but most sampling packages are external and included as needed. In this way, an app only requests permissions for the probes and sensors it actually uses.A sampling package always collect data from a device, including external devices, like the Polar heart rate monitors. In this case it uses a PolarDeviceManager for data collection.Such devices can also be online services, such as WeatherServiceManager, as available in the carp_context_package.

​
Plugins

CAMS make heavy use of the Flutter package & plugin architecture for cross-platform access to OS-level services and sensors. These packages and plugins are maintained independently of CAMS and is available from pub.dev. Plugins for data collections is typically used in probes. Each sampling package contains one or more Probes that access underlying sensors and collect data. Note that the plugins are external to CAMS and loaded by the sampling package as needed. For example, access to location data (which is considered “sensitive” for both Android and iOS) is done in the carp_context_package which uses the location plugin to access location data. But if you don’t need this measure in your study, you can leave out the carp_context_package and avoid asking for location permissions.