Data Transfer
dataRefreshMaxDelay | ||||
---|---|---|---|---|
Type | Default Value | Example | Android | HTML 5 |
Integer | 30 | 120 | + | - |
If push is turned on, the mobile device will ask the server for updated data after a push notification about changes arrives. The mobile device chooses a random delay after the notification within a time frame taken from the process flow preference dataRefreshMaxDelay
. The minimum delay is 1 second.
In order to keep the push connection alive, OMD Mobile creates a timer during startup to send a "keep-alive" regularly. In fact, the keep-alive is combined with sending the device's location to the server. If the locationSendInterval
preference is set to a value lower than 60 seconds, a minimum of 600 seconds (10 minutes) is used for the keep-alive interval.
locationSendInterval | ||||
---|---|---|---|---|
Type | Default Value | Example | Android | HTML 5 |
Integer | 0 | 300 | + | - |
By default, the locationSendInterval
flow preference is set to 0. This will avoid any location being sent to the server - the keep-alive timer will only send an empty message to the server.
Any other value will send the current location of the device to the server, although it may be refused by the server when omdAllowTracking
is set to false.
OMD Mobile can request location updates from the mobile OS throughout the whole working time, by setting the process flow preference locationTrackInterval
to a corresponding interval in seconds. If the value can be set down to a minimum of 60 seconds. Refer to the process flow preference locationSendInterval
, for setting the interval for sending the gathered locations to the server, and refer to omdAllowTracking
to allow storing locations on the server-side.
If locationTrackInterval
is set to 0
, or if the preference is not set at all, location updates are requested once per locationSendInterval
, and if a task is in status onTheWay
, updates are requested at least once every minute.
locationTrackInterval | ||||
---|---|---|---|---|
Type | Default Value | Example | Android | HTML 5 |
Integer | 0 | 300 | + | - |
Battery consumption is increased, while permanently tracking the location. To save energy, OMD Mobile offers an adaptive method for location requests towards the OS. The app requests locations for a limited time only. If the request results in high accuracy, the time limit for measurements is decreased. If the result is bad, the time limit is increased until it gets better.
This is the default method, if locationTrackInterval
is set above or equal to 300 seconds. Otherwise locations are requested in a permanent request, resulting in the best tracking quality, but with high battery consumption. To defer from this standard, the flow preference locationTrackAdaptive
defines which of the two methods is generally used.
locationTrackAdaptive | ||||
---|---|---|---|---|
Type | Default Value | Example | Android | HTML 5 |
Boolean | (see above) | false | + | - |
This preference has an equivalent effect of the location request method, even if locationSendInterval
is set above 60 seconds and locationTrackAdaptive
is not set.
geocodePostSubmissionSeconds | ||||
---|---|---|---|---|
Type | Default Value | Example | Android | HTML 5 |
Integer | 180 | 120 | + | - |
The Android OS may suspend the app for energy saving reasons and the app may be resumed right before the user executed an action, like going on-site. Hence yet the app might not have been able to determine the current location. The flow preference geocodePostSubmissionSeconds
defines the seconds to wait for geocode post-submissions, before transmitting empty or aged locations in TaskAttachments, depending on the dismissAgedGeocodes preference.
dismissAgedGeocodes | ||||
---|---|---|---|---|
Type | Default Value | Example | Android | HTML 5 |
Boolean | false | true | + | - |
If the flow preference dismissAgedGeocodes
is true
, the app dismisses geocodes measured before the geocodePostSubmissionSeconds
limit, instead of using them in attachments. The geocode
field of a task attachment may be empty instead, even though this field is declared as mandatory for the subType
.
lastUpdateWorkingTimeMaximumGap | ||||
---|---|---|---|---|
Type | Default Value | Example | Android | HTML 5 |
Integer | 10 | 60 | + | - |
The flow preference lastUpdateWorkingTimeMaximumGap
defines the maximum time in minutes during working time without a request for new data.
If this time has elapsed, the app will ask the server for an update the next time it communicates with the server, even though no push message has arrived.
Working time is expected to be limited by the start- and end-of-the-day, but can't exceed 12 hours.
If the value is below the absolute minimum of 5 minutes, the default value is used.
lastUpdateSpareTimeMaximumGap | ||||
---|---|---|---|---|
Type | Default Value | Example | Android | HTML 5 |
Integer | 180 | 240 | + | - |
The flow preference lastUpdateSpareTimeMaximumGap
defines the maximum gap in minutes outside working hours without a request for new data.
When this time has elapsed, the app will ask the server for an update the next time it communicates with the server, even though no push message has arrived.
Working time is expected to be limited by the start- and end-of-the-day, but can't exceed 12 hours.
If the value is below the absolute minimum of 5 minutes, the default value is used.
geocodePostSubmissionSeconds | ||||
---|---|---|---|---|
Type | Default Value | Example | Android | HTML 5 |
Integer | 180 | 240 | + | - |
Since the Android OS may suspend OMD Mobile for Android for energy saving reasons, the location lookup service might not be available immediately after the app resumes. This would have an effect on task attachments with geocode, created at the time of resuming the app.
To forbear this delay, the app retains task attachments with geocode, until the location service recovered and the current geocode could be determined. The flow preference geocodePostSubmissionSeconds
defines the maximum of seconds to wait for geocode post submissions, before transmitting an aged or empty geocode in task attachments.
dismissAgedGeocodes | ||||
---|---|---|---|---|
Type | Default Value | Example | Android | HTML 5 |
Boolean | false | true | + | - |
The flow preference dismissAgedGeocodes
defines whether or not an aged geocode will be dismissed, after the time of geocodePostSubmissionSeconds
elapsed, and the Android OS wasn't able to determine the location. If an aged geocode is dismissed, a task attachment may be sent with an empty geocode field, even though the field is not defined as optional for the sub-type. The ERP must allow this discrepancy.