carp_mobile_sensing

• fix duplicate column name: record_id crash in the record_id SQLite migration (SQLiteDataManager.onUpgrade) by only adding the column/index when it isn't already there

• upgrade to device_info_plus ^13.2.0 and package_info_plus ^10.2.1, which require Flutter >=3.38.1
  • needed for compatibility with health ^13.3.2, which also requires device_info_plus ^13.x
  • both bumps pull in win32 6.x; neither changes the API used here

• require carp_serializable ^3.0.0, which replaces the built-in Uuid with the uuid package

• resume a connectable device's task control executors when it connects after the study has started - previously they stayed paused and the device never sampled
• request location permission for BLE devices on Android, which is required for BLE scanning to return any results
• cancel the previous subscription when a [StreamProbe] is resumed, so resuming an already resumed probe no longer orphans a subscription that keeps delivering and collects every measurement once per resume

• Update screen_state plugin to 5.0.1

Backwards compatibility with studies created on CAMS 1.x (protocol API level < 2.0), so that apps can upgrade from 1.x to 2.x without losing running deployments.

• Support deserialization of 1.x protocols and deployments, which used the carp_core device namespace before the rename to dk.carp.cams.devices — the 1.x device type names are now registered as fromJson aliases (Smartphone, BLEHeartRateDevice, SmartphoneDeviceRegistration).
• Tolerate missing BLE scan fields (serviceUuids, allowDuplicates) and the missing deployed / 1.x status fields when deserializing 1.x deployments.
• Restore the 1.x stepcount measure type and probe.
• Migrate the local SQLite database from the 1.x schema to the 2.x schema on first launch (studies table and the device_role_name column on task_queue), instead of failing with no such table / no such column.

This release has two new main features: (i) to support adding, running, and removing multiple studies to the client manager, and (ii) to save runtime state persistently so that sampling of data in all studies will resume effortlessly across app restart. In addition, a set of issues have been addressed, as listed in Milestone 2.0.0. The important ones include:

• Update of the client software architecture to reflect the CARP Core client architecture. This - amongst other things - provides better support for StudyStatus in the client manager (#504)
• Simplified configuration - now only the client and not the controller needs configuration.
• Revised state machine model for executors, now using states 'resumed' and 'paused' instead of 'started' and 'stopped'
• Added AppLifecycleEvent measure to collect life-cycle event from the app
• Correct device registration in the deployment service (#550).

The example app has also been update to illustrate how a client can run multiple studies (#559). Also note that CAMS now has a completely new documentation site.

API level 2.0 for all packages as released on pub.dev

• Fix of #491
• Fix of #492
• Fix of #493
• Fix of #494
• Fix of #498

• Deprecating the ONE_TIME_SENSING_TYPE - now there is only one type of sensing user task (#488)

• Upgrade of Android APK
• Bumped minimum Flutter SDK requirement to 3.3
• Upgrade of plugins to latest versions
• Fix of #470
• Upgrade to latest Flutter plugins
• Fix of #481
• Fix of #482

• Support for the NoUserTaskTrigger (issue #453)

• Fix of issue with restarting data collection on device reconnect (issue #442)
• Added timestamps to user tasks when completed (issue #441)

• Extended the SmartphoneStudy and SmartphoneDeployment to hold info on participant ID and participant role for a study running on the phone. This helps upload participant data (like informed consent) without the need to specify this every time.
• Fix of #429
• Fix of #430
• Fix of #431
• Fix of #437

• Upgrade to carp_core v. 1.8 & carp_serialization v. 2.0
• Type safe fromJson() methods & nested json serialization
• Upgrade of example app to use new Flutter Android Gradle build setup

• Support for handling permission on a Measure level #407.

• Fix of #408

• Added support for extension of triggers, #403. See the section on Adding new Trigger on the CAMS wiki.
• Refactor of the software architecture to align better with a domain-driven design architecture.
• Improvements to executor state machine (can only restart an executor/probe that is already started)

• Fix of #390

• Refactor task and notification enqueueing process:
  • Move from sequential scheduling for each TaskControl to buffering tasks in AppTaskController.
  • Buffered tasks are sorted by time and scheduled in batches based on platform limits (iOS and Android notification limits).
• Enhance consistency in task scheduling:
  • Ensured all necessary tasks in the foreseeable future are queued.
  • Prevent task and notification drops due to notification slot limitations.
• Resolve issue with duplicate tasks being scheduled:
  • Ensure tasks are stored in the database after being scheduled the first time.

• Improvement to removing studies (linked to issue #283 in the CARP Studies App)
  • adding a new "disposed" sensing state
  • removing study deployment runtime
  • better handling of restarting sampling on device reconnection
• Upgrade of carp_serialization and carp_core
• Getting rid of uuid package dependency
• Fix of #394

• Automatically stopping a background task if all of its underlying probes have stopped (fix of 384)
• Upgrade to carp_core v. 1.5.0 (getting rid of IsoDuration)

• Improvements to the Notification Controller
  • support app-specific methods to create, schedule, and cancel app-specific notifications
  • asks for permission on Android (Issue #375)
  • tapping a notification takes the user to the right task in the app (Issue #376)
• Fix of #379

• Improvements to handling connected BLE devices
• Improvement to triggers and probes using BLE devices
• Improvements to restarting sampling on device reconnect
• Upgrade of packages

• Upgrade of plugins (battery_plus, sensor_plus, cron)
• Support for specifying ("overriding") sampling frequency in sensor measures (accelerometer, gyroscope, magnetometer) by using a IntervalSamplingConfiguration
• Improvement to executor state machine
• Improvement to restarting sampling on device (re)connection, including now also online service like the location service
• Improvements to device manager

First major release of CARP Mobile Sensing based on CARP Core API level 1.x.

• Upgrade to Dart 3.2
• Update to README

• Upgrade of uuid and permission_handler plugins
• Addition of a ACCELERATION_FEATURES that samples accelerometer readings over a sampling period and calculates a set of statistical features (Issue 336 & 347)
• Removal of support for awesome_notifications which does not compile on iOS
• Improvements to API docs
• Removal of toString() methods on data points - if you want to print data, print the json generated from the toJson() method.
• Rename of TransformerSchemaRegistry to DataTransformerSchemaRegistry

• Battery stream on device controller and device managers
• Support for creating, scheduling, and cancelling generic text-based notifications in the notification controller
• A device manager can now specify and handle its required permissions

• Added support for restoring a SmartPhoneClientManager on app restart
• A privacySchemaName is moved to be part of the SmartphoneStudyProtocol configuration.
• Simplification of API so that a simple local study can be configured, initialized, and started in one statement (without the need for understanding the whole deployment architecture).

Note: This release has breaking changes.

• The first stable release of CARP Mobile Sensing which follows the carp.core-kotlin v. 1.1.0 domain model, which again is implemented in the carp_core v. 1.1.0 Dart Domain model.

• This entails a set of breaking changes to the domain model:

  • CARP cores now comes with a range of pre-defined Measure Types (e.g., geolocation, stepcount, etc.). These CARP Core measures has replaced the previous CAMS versions of these. However, most of the "old" measures are kept, so there should be backward compatibility.
  • Important new measure types are the TriggeredTask, CompletedTask, which now automatically collected data on when and how a trigger and task are done.
  • A Heartbeat measurement has been added, which sends a measure every 5 minutes for each device (incl. the phone), if connected. This can be used to retrospectively check if sampling has been running (typically used in our so-called Coverage tests).
  • In the protocol, triggering is now controlled by the Control class, which basically states if sampling should be started or stopped. So, instead of adding a TriggeredTask to a protocol you now add a TaskControl instead.
  • As part of this, the states of sampling has changed from "resumed" and "paused" to "started" and "stopped" (to reflect the Control state of a TaskControl).
  • Configuration of sampling is done using the SamplingConfiguration which can be part of a DataTypeSamplingScheme which again can be part of a DataTypeSamplingSchemeMap. A description of how this works is on the CARP Core description of Sampling Schemes and Configuration section. Note that sampling configurations can be associated both with a Measure, with a DeviceConfiguration for a device, and with a SamplingPackage.

• The new data sub-system has been implemented in CAMS. This entails:

  • Sampled data is now stored as Data objects which again are stored as part of a Measurement (this replaces the old DataPoint data model).
  • Measurements are streamed using the measurements stream which is accessible from the SmartphoneDeploymentController.
  • Measurements can be stored or managed by a DataManager. CAMS comes with two build-in data managers: the FileDataManager and the SQLiteDataManager.

• The UserTask is no longer responsible for showing the user interface of the task. Now, instead of showing the user interface, the onStart methods now returns a Widget to be shown. In this model, the app (and not CAMS) is responsible for deciding when and how to show the user interface. This entails that the the life cycle methods of onStart, onCancel, onExpired, and onDone no longer takes the Flutter BuildContext as a parameter. Read more on the AppTask and UserTask model on the CAMS wiki.

• Other smaller changes include:

  • Use the CarpMobileSensing.ensureInitialized() static method in your main method to ensure that CAMS is initialized before use.
  • Update of AppDelegate.swift in example app to handle notifications in the background.
  • Adding info, warning, and debug information to the system log (instead of the console) using colors for better reading.