UWP Sensors and Devices

Analogy categoryAnalogies

The Windows.Devices.Sensors Namespace

Windows.Devices.Sensors exposes a family of sensor classes — Accelerometer, Gyrometer, Compass, Inclinometer, LightSensor, and OrientationSensor — that all follow the same basic pattern: a static GetDefault() call returns the sensor instance, or null if the device has no such hardware, and a ReadingChanged event fires new data at an interval configured via ReportInterval. Because not every PC, tablet, or Xbox has every sensor, code must always null-check the result of GetDefault() before subscribing, rather than assuming the hardware exists.

🏏

Cricket analogy: Like a broadcaster checking whether a stadium actually has Hawk-Eye cameras installed before trying to pull ball-tracking data — GetDefault() similarly checks whether the accelerometer hardware even exists before an app tries to subscribe to it, returning null if absent.

Reading Motion Sensors

The Accelerometer reports linear acceleration on the X, Y, and Z axes in units of g-force, while the Gyrometer reports angular velocity in degrees per second around those same axes. Neither alone gives a complete picture of how a device is oriented in space; combining both through sensor fusion — most conveniently via the higher-level OrientationSensor class, which returns a quaternion — produces a stable estimate of the device's rotation, which is what powers AR-style apps that need to know exactly how a phone or HoloLens is tilted and turned.

🏏

Cricket analogy: Like separately tracking a bowler's run-up speed, linear, similar to accelerometer g-force, and the ball's spin rate in revolutions per second, angular, similar to gyrometer degrees per second, then combining both readings to fully model the delivery's trajectory, similar to sensor fusion producing an orientation quaternion.

csharp

Accelerometer _accelerometer;

void InitializeAccelerometer()
{
    _accelerometer = Accelerometer.GetDefault();
    if (_accelerometer == null)
    {
        // No accelerometer hardware on this device; disable the feature.
        return;
    }

    _accelerometer.ReportInterval = Math.Max(_accelerometer.MinimumReportInterval, 50);
    _accelerometer.ReadingChanged += (sender, args) =>
    {
        AccelerometerReading reading = args.Reading;
        double x = reading.AccelerationX;
        double y = reading.AccelerationY;
        double z = reading.AccelerationZ;
        // Update UI or game state on the dispatcher thread.
    };
}

Geolocation and Proximity

The Geolocator class requires the location capability declared in the manifest plus runtime user consent, and its DesiredAccuracy property lets code choose between Default, which favors low-power Wi-Fi triangulation, and High, which engages full GPS at a real battery cost. Subscribing to PositionChanged provides continuous tracking for scenarios like a running app plotting a route. Separately, the ProximityDevice API supports NFC-based tap-to-share between two nearby Windows devices, a distinct short-range mechanism unrelated to Geolocator's broader positioning.

🏏

Cricket analogy: Like a broadcast truck choosing between a quick low-power GPS fix for a general stadium location versus firing up the full high-precision rig for pinpoint Hawk-Eye accuracy — DesiredAccuracy.Default versus High trades battery for precision the same way.

Always null-check the return value of GetDefault() for every sensor class before subscribing to ReadingChanged. Assuming hardware presence and calling into a null reference is one of the most common crashes reported from UWP apps run on devices, like many desktop PCs or virtual machines, that simply lack the sensor in question.

Enumerating Cameras and Other Devices

To let a user choose between a front and rear camera, or between multiple connected webcams, code calls DeviceInformation.FindAllAsync with a device selector string obtained from MediaCapture.FindAllVideoProfiles or the simpler MediaDevice.GetVideoCaptureSelector(), which returns a list of DeviceInformation objects each exposing a unique Id and an EnclosureLocation hinting at front versus back placement. MediaCapture.InitializeAsync then takes a MediaCaptureInitializationSettings referencing one specific DeviceInformation.Id to actually start that chosen camera — and none of this works without the webcam capability declared in the manifest and granted at runtime.

🏏

Cricket analogy: Like a broadcast director choosing between two installed camera rigs — the square-leg camera or the third-umpire replay camera — by selecting a specific device ID before routing the live feed, just as MediaCapture must be initialized against a specific DeviceInformation.Id to pick front versus rear camera.

Sensor classes in Windows.Devices.Sensors share a common pattern: GetDefault(), a ReportInterval, and a ReadingChanged event.
GetDefault() returns null if the hardware doesn't exist, and code must always null-check before subscribing.
Accelerometer reports linear g-force acceleration; Gyrometer reports angular velocity in degrees per second.
OrientationSensor fuses accelerometer and gyrometer data into a quaternion representing full device orientation.
Geolocator requires both the location manifest capability and runtime consent, plus a DesiredAccuracy tradeoff between power and precision.
ProximityDevice provides NFC-based tap-to-share, distinct from Geolocator's broader position tracking.
Enumerating cameras with DeviceInformation.FindAllAsync and initializing MediaCapture against a specific DeviceInformation.Id lets an app choose front vs. rear camera, gated by the webcam capability.