It seems like the browser you are using has JavaScript disabled. As a result, the site will not function properly. We really want you to enable it so you may experience our site as we intended it. If you have no idea what we are talking about or if you need help, visit http://www.enable-javascript.com×
This website uses cookies. By continuing to browse this site you are agreeing to our use of cookies. Find out more on our cookie page.×

Oops, it seems like you're using an old browser that we do not fully support. If you're able to, please upgrade your browser here.×
This website uses cookies. By continuing to browse this site you are agreeing to our use of cookies. Find out more on our cookie page.×

intbufferSize

By default, the buffer size is 1, which means no buffering. If the maximum buffer size is 1, then buffering is not supported by the sensor.

Setting bufferSize greater than maxBufferSize will cause maxBufferSize to be used.

Buffering is turned on when bufferSize is greater than 1. The sensor will collect the requested number of samples and deliver them all to the application at one time. They will be delivered to the application as a burst of changed readings so it is particularly important that the application processes each reading immediately or saves the values somewhere else.

If stop() is called when buffering is on-going, the partial buffer is not delivered.

When the sensor is started with buffering option, values are collected from that moment onwards. There is no pre-existing buffer that can be utilized.

Some backends like Blackberry only support enabling or disabling the buffer and do not give control over the size. In this case, the maxBufferSize and efficientBufferSize properties might not be set at all, even though buffering is supported. Setting the bufferSize property to any value greater than 1 will enable buffering. After the sensor has been started, the bufferSize property will be set to the actual value by the backend.

On Blackberry, buffering will not wait until the buffer is full to deliver new readings. Instead, the buffer will be used if the backend does not manage to retrieve the readings in time, for example when the event loop is blocked for too long. Without a buffer, these readings would simply be dropped.

boolconnectedToBackend[read-only]

a value indicating if the sensor has connected to a backend.

A sensor that has not been connected to a backend cannot do anything useful.

Call the connectToBackend() method to force the sensor to connect to a backend immediately. This is automatically called if you call start() so you only need to do this if you need access to sensor properties (ie. to poll the sensor's meta-data before you use it).

Since:

1.0

intdataRate

the data rate that the sensor should be run at.

Measured in Hertz.

The data rate is the maximum frequency at which the sensor can detect changes.

Setting this property is not portable and can cause conflicts with other applications. Check with the sensor backend and platform documentation for any policy regarding multiple applications requesting a data rate.

The default value (0) means that the app does not care what the data rate is. Applications should consider using a timer-based poll of the current value or ensure that the code that processes values can run very quickly as the platform may provide updates hundreds of times each second.

This should be set before calling start() because the sensor may not notice changes to this value while it is running.

Note that there is no mechanism to determine the current data rate in use by the platform.

intoutputRange

Setting this property is not portable and can cause conflicts with other applications. Check with the sensor backend and platform documentation for any policy regarding multiple applications requesting an output range.

The default value (-1) means that the app does not care what the output range is.

Note that there is no mechanism to determine the current output range in use by the platform.

The reading class provides access to sensor readings. The reading object is a volatile cache of the most recent sensor reading that has been received so the application should process readings immediately or save the values somewhere for later processing.

Note that this will return 0 until a sensor backend is connected to a backend.

Also note that readings are not immediately available after start() is called. Applications must wait for the readingChanged() signal to be emitted.

Note that the identifier is filled out automatically when the sensor is connected to a backend. If you want to connect a specific backend, you should call setIdentifier() before connectToBackend().

Since:

1.0

boolskipDuplicates

Indicates whether duplicate reading values should be omitted.

When duplicate skipping is enabled, successive readings with the same or very similar values are omitted and skipped. This helps reducing the amount of processing done, as less sensor readings are made available. As a consequence, readings arrive at an irregular interval.

Duplicate skipping is not just enabled for readings that are exactly the same, but also for readings that are quite similar, as each sensor has a bit of jitter even if the device is not moved.

Support for this property depends on the backend. It is disabled by default.

Duplicate skipping can only be changed while the sensor is not active.

boolskipDuplicates()

Static Public Functions

This is set in a config file and can be overridden if required. If no default is available the system will return the first registered sensor for type.

Note that there is special case logic to prevent the generic plugin's backends from becoming the default when another backend is registered for the same type. This logic means that a backend identifier starting with {generic.} will only be the default if no other backends have been registered for that type or if it is specified in {Sensors.conf}.

Protected Functions

QSensorPrivate *d_func()

QSensor (

QSensorPrivate *dd,

Public Slots

(Only has inherited public slots)

boolstart()

Start retrieving values from the sensor.

Returns true if the sensor was started, false otherwise.

The sensor may fail to start for several reasons.

Once an application has started a sensor it must wait until the sensor receives a new value before it can query the sensor's values. This is due to how the sensor receives values from the system. Sensors do not (in general) poll for new values, rather new values are pushed to the sensors as they happen.

Signals

voidreturnGeoValuesChanged (

boolreturnGeoValues)

voidactiveChanged()

voidalwaysOnChanged()

This signal is emitted when the alwaysOn property changes.

voidavailableSensorsChanged()

This signal is emitted when the list of available sensors has changed.

The sensors available to a program will not generally change over time however some of the avilable sensors may represent hardware that is not permanently connected. For example, a game controller that is connected via bluetooth would become available when it was on and would become unavailable when it was off.

voidbufferSizeChanged (

intbufferSize)

voidbusyChanged()

sensor.start();
if (sensor.isBusy()) {
// need to wait for busyChanged signal and try again
}

Since:

1.0

voiddataRateChanged()

voidefficientBufferSizeChanged (

intefficientBufferSize)

voidmaxBufferSizeChanged (

intmaxBufferSize)

voidreadingChanged()

This signal is emitted when a new sensor reading is received.

The sensor reading can be found in the QSensor::reading property. Note that the reading object is a volatile cache of the most recent sensor reading that has been received so the application should process the reading immediately or save the values somewhere for later processing.

Before this signal has been emitted for the first time, the reading object will have uninitialized data.

1. Download the tools

Before you start developing, you'll need to visit the Downloads tab. Here you'll find downloads for the BlackBerry 10 Native SDK, BlackBerry 10 Device Simulator, and some other useful tools.

2. Try the sample apps

Now featuring a filter control, the Sample apps tab allows you to search for samples by name or by feature.

Select either the Core or Cascades radio buttons to display the samples relevant to you.

3. Educate yourself

The Documentation tab contains tons of examples, tutorials, and best practices to guide you along the path towards building an awesome app.

You can access all the documentation that you need in the left-hand navigation.

4. Start developing

The Reference tab is where you'll find essential details about how to use our APIs.

You can use the left-hand navigation to choose how you would like to browse the reference: by module, by topic, or alphabetically. If you have an idea of what you are looking for, start typing it in the Filter box.