Detecting Inefficient Location API Configurations

This page briefly explains our typestate configuration for detecting inefficient location API configurations based on our upcoming ICSME paper.

The various configurations of Standard Location Service and Visits Location Service (among other services) are categorized in terms of optimality in the paper. Adding the foreground and background optimality scores for each configuration, we get a total score for optimal configuration (higher is less optimal). We then classify ranges of the score (x) that we deem good (x<5, 🟢), nonoptimal (5<=x<=6, 🟡), and very nonoptimal (x>6, 🔴). The following tables show the configurations and their scores.

Standard Location Service

The user can configure the desiredAccuracy and distanceFilter fields of the CLLocationManager. The columns represent desiredAccuracy settings, and the rows represent distanceFilter settings. S<X> represents the configuration identifiers from the paper.

	Best	100m	1km	Navigation
16	S1, 5 🟡	S6, 3 🟢	S11, 4 🟢	S16, 6 🟡
256	S2, 5 🟡	S7, 3 🟢	S12, 2 🟢	S17, 6 🟡
4096	S3, 9 🔴	S8, 6 🟡	S13, 4 🟢	S18, 8 🔴
4096	S4, 10 🔴	S9, 5 🟡	S14, 3 🟢	S19, 8 🔴
65536	S5, 4 🟢 (default)	S10, 2 🟢	S15, 2 🟢	S20, 4 🟢

Example:

locationManager.startUpdatingLocation()
locationManager.desiredAccuracy = kCLLocationAccuracyBest
locationManager.distanceFilter = 4096

This configuration is very non-optimal. Note that startUpdatingLocation() must be called in order to activate the service.

Visits Location Service

The user can configure the activityType field of the CLLocationManager. V<X> represents the configuration identifiers from the paper.

airborne	automotiveNavigation	fitness	other	otherNavigation
V1, 2 🟢	V2, 5 🟡	V4, 7 🔴	V5, 5 🟡 (default)	V6, 8 🔴

Example:

locationManager.startMonitoringVisits()
locationManager.activityType = CLActivityType.fitness

This configuration is very non-optimal. Note that startMonitoringVisits() must be called in order to activate the service.