Using the SDK
A few general notes:
Customers should avoid using
TripDetector
directly; to ensure proper functionality, customers should only use the public classTripDetectionManager
;TripDetectionManager
can be accidentally initialised multiple times; this got fixed and we print a warning for this now.Show thread name in log file (“main” or “other”).
Log current thread on
Common.initialize
andTripDetectionManager.enable
; initialising the SDK and enabling trip detection outside of main thread may cause issues for trip detection.
Device Activation (aka Phone Registration)
The user's phone must be registered through the Portal
before trips recorded on that phone can be uploaded. Depending on the activation method, as selected by the host app, the device may only require one activation.
There is currently a limit of one registered phone per user account. If the same user logs in and registers a second phone, trips from the first phone will no longer get uploaded to the server.
Use the DeviceService to activate the device (register the phone) before you start recording trips.
Control Trip Detection and Recording
To utilize trip detection, recording, and uploading features, it is essential to initialize the trip detection manager. We highly advise performing this initialization process upon application launch. Once the trip detection manager is initialized, you will have access to enable
and disable
functionalities.
To activate trip detection, recording, and file upload, utilize the enable
function. Additionally, there are two callback functions available: tripStartHandler
, which triggers when a trip starts, and tripEndHandler,
which is called upon trip ends.
Use the disable
function to stop, such as when the user logs out.
Note that once trip detection is enabled, it remains enabled even if the application restarts or the phone reboots. You only need to explicitly re-enable it if you previously disabled it.
Manual Trip Recording and Uploading
Trip detecting, recording, and uploading will be performed automatically once the enable
function is called. If you prefer manual control over recording and uploading trips, you can use the following functions:
Use
beginTripRecording
to start trip recording
Use
endTripRecording
to stop trip recording
Use
uploaAll
to upload all the trip data
Use
tripsToUplaod
to see the number of trips that are ready to upload. Note the this number will be increased when a trip is recorded without a network connection.
Bluetooth Trip Detection
How it works
The Bluetooth Trip Detection (BTD thereafter) uses pending connections to Bluetooth LE devices to wake-up the trip detection. The BTD acts as a wake-up trigger, which kick-starts the trip detection. The first implementation is neither required, nor sufficient to start a trip on its own. A trip can still be started without any bluetooth device being detected, and the trip detection is still required to confirm the validity of a trip.
Bluetooth vs Bluetooth LE vs Bluetooth beacon
BTD supports both Bluetooth and Bluetooth LE technology. BTD does not support Bluetooth beacon, although these can be used via the Bluetooth LE features (beacon features are not used in the current implementation) BTD makes use of the "Bluetooth classic" as defined in Apple's WWDC 2019. Not all Bluetooth devices support this feature. BTD makes use of the AudioManager to try to infer the presence of regular Bluetooth devices, such as a car infotainment system.
Starting and Stopping the Bluetooth Trip
Once a Bluetooth device is added to the list of known devices, the Bluetooth trip detection will start detecting automatically.
Built-in Bluetooth device list
To reduce issues related to device support, the SDK provides a list of devices that can be directly used for trip detection. The list is built using the same technologies used by the SDK for the detection, and insure a higher success rate by not showing devices known to not be compatible with the current implementation. The list can be accessed via
BluetoothDevice's can be used in place of CBPeripherals when adding/removing devices.
Adding / removing devices
In order to add a Bluetooth device to the list of known Bluetooth devices you need to call:
This does not show any audio devices.
Then one needs to access the trip detection component 'BluetoothTripDetector' (name subject to change for final release). This component includes all the required methods to add or remove Bluetooth devices to and from the list. The list of devices is backed up by the SDK itself in order to provide the simplest implementation. When using the TripUmbrella, a default implement exists and can be used as follows
In the same fashion, it is possible to remove a Bluetooth device.
NOTE: For a full implementation example, check out the Sample App.
Controlling how the files are uploaded
At the time of SDK initialization, if the host app wants it can select the upload route for uploading the trip files to the DriveSync server.
SDK has two upload routes host app can choose:
.wifiOnly:
Upload data only when connected to a WiFi network..anyNetwork:
Upload data when connected to any network.
If the host app doesn't pass the upload route, the SDK will choose .anyNetwork
by default for uploading the trip files.
See below example for passing the upload route:
Also, after initialization the upload route settings can be changed.
See below example:
Logging the message
The log function will log the message into SDK log file. Please make sure to import the Common
framework. There are 4 levels for the log message, which are debug, info, warning and error.
The format of the log message will be:
Here is an example of the log
All the logs will be stored in the log
directory under the app directory. You can use the app directory, which from initializing sdk, to get the log directory.
Last updated