Trip recording lifecycle

Before you start, we recommend that you install the Sample Application and perform some testing to get familiar with the SDK's behavior and features.

The Sample Application integrates all components of the DriveKit SDK and you can refer to the code before installing the Trip Analysis component in your mobile application.

You can find all resources on Github.

  • Android Sample Application can be found here.

  • iOS Sample Application can be found here.

In order to understand how the smartphone telematics SDK works and how it will transform your app into a powerful sensor, take the time to read the following section that explains briefly the expected behavior.

Automatic trip recording

The DriveKit SDK (TRIP ANALYSIS component) has the ability to automatically detect and record a trip when your application runs in background.

Before integrating the Trip Analysis component into your application, it is recommended that you understand how it works. This section explains the main states of the SDK during a trip as well as the events that trigger the transitions between states.

The diagram below shows, from top to bottom:

  • Events that trigger the transition from one state to another,

  • Main SDK states,

  • Accessible callbacks that your application can use to implement your own business logic.

Automatic trip analysis lifecycle

Here is a brief description of the sequence of trip analysis from A to Z:

Trip Detection: the SDK does not start instantly at the beginning of the trip. There is a variable delay during which the application identifies that a trip might be in progress. If the probability is high enough, the application turns on the GPS sensor and starts to analyze the vehicle's speed.

Trip confirmation: the trip is not validated immediately. Beforehand, the SDK checks if the trip speed is consistent with that of a motor vehicle. If this is not the case, the trip will be cancelled naturally and no data will be stored locally (and no data will be transmitted to the DriveQuant's server).

Trip Recording: if the trip is confirmed by the SDK, then the data are recorded locally for the entire trip.

End of Trip Detection: the SDK can determine if the trip is completed. Each time the vehicle stops, a timer starts to check whether the stop is definitive or not. Depending on your needs, it is possible to set a time delay for stopping a trip. The default timeout value is 4 minutes. You can adjust this value between 2 and 8 minutes.

Trip Analysis: once the trip has been completed, the SDKs automate the request to the trip analysis API. If the smartphone is not connected to a mobile network, the request will be retried later.

The same principles apply to the iOS and Android operating systems. The only minor differences concern callbacks, whose names and types may change slightly. The table below describes the callbacks on iOS:

iOS Callback

Type

Description

sdkStateChanged

Listener

This method is called each time the status of the SDK changes.

tripStarted

Listener

This method is called each time a trip is started. It indicates which event triggers the trip.

tripPoint

Listener

This method is called when a trip is confirmed. It is used to retrieve GPS while the trip is being recorded.

tripCancelled

Listener

This method is called when a trip is cancelled. It indicates which event cancels the trip.

tripFinished

Listener

This method is called when a trip has been recorded by the SDK and sent to DriveQuant's server for analysis.

tripSavedForRepost

Listener

This method is called if the trip data cannot be sent to DriveQuant's server for analysis because the phone is not connected to the mobile network. In this case, the trip is saved locally on the SDK and will be sent later.

The table below describes the callbacks on Android:

Android Callback

Type

Description

sdkStateChanged

Listener

This method is called each time the status of the SDK changes.

tripStarted

Listener

This method is called each time a trip is started. It indicates which event triggers the trip.

tripPoint

Listener

This method is called when a trip is confirmed. It is used to retrieve GPS while the trip is being recorded.

tripCancelled

Broadcast Receiver

This method is called when a trip is cancelled. It indicates which event cancels the trip.

onTripReceived

Broadcast Receiver

This method is called when a trip has been recorded by the SDK and sent to DriveQuant's server for analysis.

tripSavedForRepost

Listener

This method is called if the trip data cannot be sent to DriveQuant's server for analysis because the phone is not connected to the mobile network. In this case, the trip is saved locally on the SDK and will be sent later.

Manual trip recording

Manual recording of a trip is similar to automatic recording. The main difference concerns the triggering: instead of being generated by the trip detection function, the start of a trip is triggered by this method:

Kotlin
Java
Swift
Kotlin
DriveKitTripAnalysis.startTrip()
Java
DriveKitTripAnalysis.INSTANCE.startTrip();
Swift
DriveKitTripAnalysis.shared.startTrip()

In case of a manual trip start, there is no confirmation phase, the trip switches directly to recording phase.

To stop the trip analysis, you only need to call up the following method at the end of the trip:

Kotlin
Java
Swift
Kotlin
DriveKitTripAnalysis.stopTrip()
Java
DriveKitTripAnalysis.INSTANCE.stopTrip();
Swift
DriveKitTripAnalysis.shared.stopTrip()

In case the driver forgets to stop the trip, the end-of-trip detection mechanism will automatically stop the recording after an adjustable time-out of 2 to 8 minutes. This prevents the GPS sensor from remaining on after the end of a trip and draining the smartphone battery.

Mobile data usage

The use of the DriveQuant SDK has a minimal impact on the driver's smartphone data plan. Data consumption is a topic that users of your application may be concerned about, so we have done our best to limit the amount of data used by the SDK.

The trip data are recorded with a frequency of 1Hz and are transmitted in text format.The volume of data recorded is about 5 kb per minute of driving:

  • 50 kb of data are used for the analysis of a short 10-minute trip,

  • 150 kb of data are used for the analysis of a 30-minute trip,

  • A 2-hour long trip uses 600 kb of data.

The average data usage for a commuter working 30 minutes from home will be in the range of 10 Mb to 12 Mb per month.

Battery consumption

The DriveKit SDK measures data from smartphone sensors while minimizing the impact on the battery. It automatically detects the start and end of a motorized trip and does not use the GPS sensor outside of the trip.

This helps to avoid draining the phone's battery and protects the user's privacy. Location data from the phone are not collected outside of the phases where the user is driving.