Office of Digital Humanities
Modern mobile devices are loaded with electronic sensors that allow the device to be aware of things like location, heading, movement and rotation. These sensors include:
These physical sensors are trackable by software. The sensors are referred to using these names:
Location and heading (direction of travel) are simple enough to understand. But what about acceleration and rotation rate? Here is a post from stackoverflow.com explaining the difference between an accelerometer and a gyroscope, and the difference between acceleration and rotation rates.
http://stackoverflow.com/questions/7298127/difference-between-gyro-and-accelerometer
Difference between acceleration and rotation rate: The accelerometer reports the difference between the acceleration that the device is experiencing and that which it would be experiencing were it in freefall. So if the accelerometer is returning a zero vector then the only force acting on the phone is gravity (ie, you've dropped it). Normally it'll be some other value. If the phone is at rest on a table, it'll reveal the direction of gravity relative to the phone. The accelerometer is therefore most often used to figure out which way is down - so that the UI can rotate, and in games so that you can do things like use the device as a steering wheel.
The gyroscope can observe the rate at which the device is rotating. The CoreMotion library can automatically integrate that to get current angles.
Devices with a gyroscope also have a three-axis accelerometer (in addition to the traditional one) that measures acceleration individually along three axes.
The sensor reading capabilities built into LiveCode make it simple to capture inputs from mobile device sensors. For this LiveCode includes a few functions and commands.
The mobileSensorAvailable() function - reports whether the named sensor type is available. This function returns true or false.
Syntax:
mobileSensorAvailable(sensorType)
Where sensorType is one of:
Example:
if mobileSensorAvailable("location") then
# do location reporting stuff here
end if
Due to privacy concerns, in order to get information from certain sensors the app needs to receive authorization from the device user. Location information is one such sensor. The mobileLocationAuthorizationStatus() function reports whether the user has authorized the app to access location sensor informaion. This function returns a string that describes the status of location authorization. It is one of the following:
Example:
if mobileLocationAuthorizationStatus() is "denied" then put "The app cannot access your location." into field "status" end if
Once you have determined that the sensor is available and authorized, you can use the mobileStartTrackingSensor command, which turns on tracking for the specified sensor.
Syntax:
mobileStartTrackingSensor sensorType, [loosely]
Where sensorType is one of:
And the optional parameter loosely is true or false. If false this command will use more accurate but higher power-consuming sources such as GPS rather than less accurate but less power-demanding methods like Wi-Fi triangulation.
Example:
mobileStartTrackingSensor "location"
When you are done tracking the sensor, just turn it off with the mobileStopTrackingSensor command.
Syntax:
mobileStopTrackingSensor sensorType
Where sensorType is one of:
Turning a sensor on simply tells your app to start "listening" to that sensor. That means that repeated update messages will be sent to the card for each of the sensors that has been activated.
When the location sensor is on the locationChanged message is sent out repeatedly:
Syntax:
on locationChanged latitude, longitude, altitude
Where the following parameters are also sent along with the message:
Example. A handler like this would go in the card script:
on locationChanged pLat, pLong, pAlt put "Current Latitude: " & pLat into fld "information" # etc. end locationChanged
When the heading sensor is on the headingChanged message is sent out repeatedly:
Syntax:
on headingChanged heading
Where the following parameter is also sent along with the message:
When the acceleration sensor is on the accelerationChanged message is sent out repeatedly:
Syntax:
on accelerationChanged x, y, z
Where the following parameters are also sent along with the message:
When the rotation sensor is on the rotationChanged message is sent out repeatedly:
Syntax:
on rotationChanged x, y, z
Where the following parameters are also sent along with the message:
If all you want is a one-time sensor reading, there are a couple of options. You must still turn the sensor on with mobileStartTrackingSensor, as explained above. But, rather than writing handlers to continuously track the given sensor, you can use the mobileSensorReading function to get a one-time "snapshot" reading.
Syntax:
put mobileSensorReading(sensorType,detailed) into tSensorData
Where detailed is true or false, and controls the amount of data returned. The data returned depends on the sensorType.
Example:
mobileStartTrackingSensor "location" # enable the sensor first
put mobileSensorReading("location",false) into tSensorData
## this returns a string with the current latitude, longitude and altitude
mobileStopTrackingSensor "location" # turn off the sensor when done
There is also a mobileCurrentLocation() function that can grab a reading of the current location information. This function returns its data as an array, so you can query the current latitude and longitude like this:
mobileStartTrackingSensor "location" put mobileCurrentLocation() into tLocArray put tLocArray["latitude"] into tCurrentLat put tLocArray["longitude"] into tCurrentLong mobileStopTrackingSensor "location"
If at any point there is an error tracking one of the sensors, the trackingError message will be sent.
Syntax:
on trackingError sensor, errorMessage
Where:
sensor is one of the sensor types listed above;
errorMessage is the error message returned by the sensor.
Example. A handler like this would go in the card script:
on trackingError pSensor, pErrorMsg answer "The sensor" && pSensor && "returned an error: " & pErrorMsg end trackingError
Try it!
Do the Mobile Device Sensors Exercise to create a simple mobile app that will read the input from onboard sensors.