The desired accuracy level to use when monitoring the device location.

Use with an accuracy constant such as ACCURACY_BEST_FOR_NAVIGATION. No other values are accepted.

The location service will try its best to achieve your desired accuracy. However, it is not guaranteed. To optimize power performance, be sure to specify an appropriate accuracy for your usage scenario (eg, use a large accuracy value when only a coarse location is needed). More precise locations generally require higher battery usage.

Support: iOS only

Sets the duration (in milliseconds) this request will continue before being automatically removed Defaults to -1, which represents an unlimited duration. Support: Android only

Explicitly set the fastest interval for location updates, in milliseconds.

This controls the fastest rate at which your application will receive location updates, which might be faster than interval in some situations (for example, if other applications are triggering location updates).

This allows your application to passively acquire locations at a rate faster than it actively acquires locations, saving power.

Unlike interval, this parameter is exact. Your application will never receive updates faster than this value.

If you don't set this value, a fastest interval will be selected for you. It will be a value faster than your active interval.

An interval of 0 is allowed, but not recommended, since location updates may be extremely fast on future implementations.

Support: Android only

Set the desired interval for active location updates, in milliseconds.

The location client will actively try to obtain location updates for your application at this interval, so it has a direct influence on the amount of power used by your application. Choose your interval wisely.

This interval is inexact. You may not receive updates at all (if no location sources are available), or you may receive them slower than requested. You may also receive them faster than requested (if other applications are requesting location at a faster interval). The fastest rate that that you will receive updates can be controlled with fastestInterval. By default this fastest rate is 6x the interval frequency.

Applications with only the coarse location permission may have their interval silently throttled.

An interval of 0 is allowed, but not recommended, since location updates may be extremely fast on future implementations.

Support: Android only

Sets the maximum wait time in milliseconds for location updates.

If you pass a value at least 2x larger than the interval specified with interval, then location delivery may be delayed and multiple locations can be delivered at once. Locations are determined at the interval rate, but can be delivered in batch after the interval you set in this method. This can consume less battery and give more accurate locations, depending on the device's hardware capabilities. You should set this value to be as large as possible for your needs if you don't need immediate location delivery.

Support: Android only

Since Android O, in order to receive consistent updates while your application is in the background a foreground service and corresponding notification must be used. When this is true the extension will use a foreground service to perform location monitoring and updates and handle display of the required notification (required by Android for foreground services).

If you require consistent updates to the location while your application is in the background you must set this to true using the setPersistInBackground() function.

If this is false then your applications location updates may be throttled when in the background and batched together at least frequent intervals ignoring any options specified in this request.

See also

Notification text for the foreground service notification

Set the priority of the request.

Use with a priority constant such as PRIORITY_HIGH_ACCURACY. No other values are accepted.

The priority of the request is a strong hint for which location sources to use. For example, PRIORITY_HIGH_ACCURACY is more likely to use GPS, and PRIORITY_BALANCED_POWER_ACCURACY is more likely to use WIFI and Cell tower positioning, but it also depends on many other factors (such as which sources are available) and is implementation dependent.

On iOS these values control whether the location services use the significant location updates or the standard and significant locations updates.

• PRIORITY_NO_POWER or PRIORITY_LOW_POWER:
  • ALWAYS permission: will use significant updates
  • IN_USE permission: will use standard updates
• PRIORITY_BALANCED_POWER_ACCURACY or PRIORITY_HIGH_ACCURACY:
  • ALWAYS permission: will use significant + standard updates
  • IN_USE permission: will use standard updates

Support:

• Android: Values coincide with the direct equivalents in the Android SDK
• iOS: Values control whether the extension will use standard / significant location updates. See the definitions of the PRIORITY_ values in this class for details.

Additional data that will be sent with every update to the updataUrl. This can be used to identify this device or user in your server code.

The minimum interval between updates to the server in milliseconds.

This allows you to limit the request frequency to your server. It is not a guaranteed interval but the minimum interval that will be between sequential updates from a device. This interval may be longer if the device does not receive a location update during that interval.

If 0, then every location update will be sent.

This is a url that the extension will attempt to send the location information to whenever a location update is received.

This can be useful in situations where the application is running in the background (or even terminated on Android) the update url will still be contacted where AS3 code may not run.

The payload sent to the url takes the following form:

         {
          "location": {
              "altitude": 0.00,
              "latitude": 0.00,
              "longitude": 0.00,
              "timestamp": 000000000
          },
          "data": "YOUR_CUSTOM_DATA_STRING"
         }
         

Constructor

Parameters

See also

Parameters

See also

Parameters

See also

Parameters

See also

Parameters

See also

Sets the value of persistInBackground

Parameters

See also

Parameters

See also

Parameters

See also

To request "block" level accuracy.

Block level accuracy is considered to be about 100 meter accuracy. Using a coarse accuracy such as this often consumes less power.

On iOS this will use both standard and significant update modes. If you only have the "in-use" permission then you will not get significant updates but only the standard updates.

To request the most accurate locations available.

This will return the finest location available.

On iOS this will use both standard and significant update modes. If you only have the "in-use" permission then you will not get significant updates but only the standard updates.

To request "city" level accuracy.

City level accuracy is considered to be about 10km accuracy. Using a coarse accuracy such as this often consumes less power.

On iOS this will use the significant update mode only if you have the always permission otherwise it will use the standard updates.

To request the best accuracy possible with zero additional power consumption.

No locations will be returned unless a different client has requested location updates in which case this request will act as a passive listener to those locations.

On iOS this will use the significant update mode only if you have the always permission otherwise it will use the standard updates.