Shift Based Detections
This guide explains how to implement shift-based or session-based SDK detection. This guide will help with implementing the logic if you want to fully control the detections for your users, expecially if your bussiness logic requires shift based detections example being:
You want to only enable detections during the working hours of your users.
You want to enable detections only during the start and end of order delivery for your drivers
You want to perform detections only during a chauffeur session for a chauffeur service
SDK Detection Control
The Sentiance SDK exposes two primary methods to control its detection state:
enableDetections()
Prepares the SDK for detection. Verifies permissions, sensors, and location services. Does not immediately start data collection.
disableDetections()
Stops the SDK from performing any further detections.
Calling enableDetections() puts the SDK into a ready state it verifies that all required permissions are granted and that the necessary sensors and location services are available. It does not start a trip or trigger any GPS or sensor data collection immediately.
Active data collection only begins once the device's geofence is broken, which typically occurs after approximately 2–3 minutes of movement or when the user has travelled 200–300 meters. This means the user must already be in motion before the SDK starts actively collecting location and sensor data.
enableDetections() and disableDetections() can be triggered programmatically at any point based on your application's business logic.
Identifying & Tagging Transports
A trip may contain multiple transport events if the user switches between transport modes, or if the user stops moving for approximately 3 minutes, which triggers a stationary event. Each transport has a unique ID that can be used to query transports within a specific time range and associate them with a shift or session.
A more reliable approach is to use transport tags. By calling setTransportTags() and passing a map or dictionary of your own identifiers such as driverID, sessionID, or orderID those identifiers will be attached to all subsequent transports until the method is cleared or called again with different values.
Tags can also be applied while a transport is already in progress, as long as it has not yet been finalized by the SDK. Once the transport is completed, the tags will be included in the final TransportEvent under the tags attribute.
Example: Shift-Based Detection Flow
The following illustrates a typical implementation of shift-based detection, from the start to the end of a shift
Start shift
User taps the "Start shift" button in the application
Log and store current time as the start time of the shift and appoint a shitID
This action should call the enableDetections() to prepare the SDK for detections
Call eventTimelineAPI.setTransportTags({"shiftID": "123XXX"}) -> this will attach your custom identifiers to all subsequent Transport Events.
When the SDK will now be able to detect the users transports. This will be done on a automatic basis, so the sdk will detect when the user is in movement and when they stopped moving. after every completed transport, the transports detected details and insights will be made available in the Event Timeline and Driving Insights.
The detections will be enabled and active data collection be started and stopped automatically util the disableDetections method is called.
End shift
User taps the "End shift" button in the application
Log and store the current time as the end time of the shift
Call disableDetections() to stop the SDK from performing further detections until manually enabled again.
make sure to clear the TransportTags by calling setTransportTags and passing an map value.
The SDK will terminate a transport if there was an ongoing transport at the moment. and provide the nessesary details in the EventTimeline and Driving Insights if available.
You can query the SDK for the detected transports that belong to a certain session by querying the EventTimeline and requesting all events that were captured during the start time and end time of a transport session
Last updated