Windows apps
Collapse the table of content
Expand the table of content

Guidelines for using sensitive devices (Windows Store apps using C#/VB/C++ and XAML)

This topic describes best practices for using sensitive device capabilities, which include microphones, cameras, location, and text messaging. Microphones, cameras, location providers and text messaging services can access the user's personal data or cost the user money, so Windows Store apps have features to ensure the user has control over these sensitive devices. If your app accesses sensitive devices, design it to account for how a user may enable and disable device access.

How the user controls the app's use of sensitive devices.

Permissions for Windows Store apps to use sensitive devices are controlled on a per-app, per-user level. The user controls permissions using the consent prompt, or by using the Settings Charm

The consent prompt

The following screen shot shows the consent prompt as it appears in a Windows Store apps. The prompt appears the first time an app accesses a sensitive devices. It gives the user options to block or allow the app's access to the device capability. Windows remembers the response so that the user is not prompted again for the same application.

Consent prompt in a Windows Store app

The Settings charm

Users of Windows 8 can also control each app's access to sensitive devices using the Settings charm. The user taps on the Settings Charm to open a Settings flyout to enable or disable the app's access to sensitive device capabilities.

The Settings charm is pictured here on the right side of the app:

Settings charm

The Settings charm provides flyouts that let the user enable or disable sensitive capabilities, pictured here:

Settings flyout that provides app location settings

When to start using the device

The first API call that accesses the device will trigger the consent prompt. If an app's primary purpose does not require access to a sensitive device, it can be confusing to the user if a prompt for permission to use a device appears as soon as the app starts. Follow these guidelines for a good user experience.

GuidelineExample

If use of the sensitive device is not essential to your app, don't access it until the user specifically requests it.

A social networking app has buttons for "Check in with my location" and "Take a profile picture". This app should not access location or the camera until the user clicks the corresponding button.

If an app requires device access for its main function, then it can access the device when the app starts.

An app for capturing live videos from an attached camera requires the camera for its main purpose. It's OK for this app to use the camera when it starts, to show a video preview right away.

 

See the Reference section for more info on the API calls that trigger a consent prompt.

What if access to a device is turned off?

An app's access to a sensitive device may be disabled for one of these reasons:

  • The user blocked access using the consent prompt.
  • The user disabled access to the device in the Settings Charm.
  • The device is not present on the system.

To provide a good user experience when access is disabled, do the following:

  • Handle the error from the API that occurs when your app attempts to access a disabled device capability. The Reference section of this topic provides more information on the method calls that may return errors that indicate that the app doesn't have access to a device.
  • Display a message to the user that informs them that the device capability is disabled, and tells them how they can re-enable it by using the Settings Charm and reattempting to use the capability in the app. Following the Guidelines for notifying the user to provide this message.
  • Provide UI for the user to re-initiate access to the device if the device is re-enabled. Reinstantiate or reinitialize the object that accesses the device using this UI. For example, a mapping app may provide a button for refreshing the current location. The button must instantiate a new Geolocator object.

Guidelines for notifying the user of device revocation

The following guidance relates to how apps should react when a user revokes a sensitive capability that he/she has previously granted access to. The purpose of this is to properly notify the user of loss of functionality and guide them towards turning a capability back on without taking away from the app's experience.

Your app should tell the user that the capability is turned off, and that they can enable the capability using the app's settings.

Reason the device is disabledSample error message format

The user blocked access using the consent prompt or the Settings charm.

"Your <device capability> is currently turned off. To change your <device capability> setting, open the settings charm and tap permissions. Then <enable action> to start using <device capability> again. ”

  • Replace <device capability> with webcam, microphone, location, or text messaging.
  • Replace <enable action> with the action the user needs to take in the UI to reinitialize access the capability, like clicking a button.

The device capability isn't present on the system.

“You do not have the required <device capability> present on your system.”

 

The UI you use to present the message about a disabled device capability depends on whether the device capability is essential to the app. The following examples show how to display device capability messages.

Display a flyout or inline text if the device is non-essential

If use of the sensitive device is not essential to your app, display the message in a flyout at the point of invocation, or using unobtrusive inline text.

For example, if a mapping app has a button for showing the current location, and the user clicks the button when the required device capability is disabled, the app should show the error message in a flyout near the button, or in inline text.

The following screen shot shows an app that displays the message in flyout. The message reads: "Your location cannot be found. Change your permissions in Settings to allow Maps to access your location. Then restart the app."

Consent prompt in a Windows Store app

Display a message if the device capability is essential

If an app requires device access for its main function, it displays the error message.

In the screen shot that follows, the Camera app requires access to the webcam and microphone capabilities for its main function, so it displays a message instructing the user to enable the camera capability.

Message to user that location should be enabled

Other guidelines for revocation messages

Here are some more guidelines for informing the user that a device capability is disabled:

  • Notify the user of an unavailable capability if the user attempts to use a device capability that's not essential to the app, so the user is aware of the loss of functionality.
  • Make the device revocation message clearly visible to the user.
  • Use a flyout when a capability is not available, a control to use the capability is provided, and the capability is not essential to app functionality.
  • Don't let the text interrupt the app's flow.
  • Don't use notifications to notify the user of device capability unavailability.
  • Don't programmatically try to launch the Permissions page in the Settings charm
  • Don't show an error message for a device capability that has not yet been requested by the user. For example, if a social networking site has an option to include location when posting messages, but the user has not chosen to share location, don't show an error message when posting messages.

Reference

This table lists API info for disabling and reenabling sensitive device capabilities.

CapabilityInfo on enable and disable
Location

Either the GetGeopositionAsync method or adding an event handler for the PositionChanged event will trigger a consent prompt.

See the Guidelines for location-aware apps for more info on how to handle user disable and re-enable of location in your app.

See Detecting geolocation for tutorials.

Webcam or Microphone

Apps that use Windows.Media.Capture.CameraCaptureUI.CaptureFileAsync to capture photos or videos from a camera should note the following:

  • Calling Windows.Media.Capture.CameraCaptureUI.CaptureFileAsync will trigger a consent prompt the first time the app is run. Windows.Media.Capture.CameraCaptureUI.CaptureFileAsync does not return an error if the webcam capability is turned off. Instead, the Camera Capture UI will display a message indicating that the webcam capability is turned off.

Apps that use Windows.Media.Capture.MediaCapture to preview or capture audio, video, or photos should note the following:

  • The error handlers for the asynchronous methods of MediaCapture receive an E_ACCESSDENIED error if the user did not grant permission, and HRESULT_FROM_WIN32(ERROR_FILE_HANDLE_REVOKED), if permission is revoked.
  • Call InitializeAsync again to access the camera, if the user re-enables access to the webcam after revoking it. For example, if the error handler for a HRESULT_FROM_WIN32(ERROR_FILE_HANDLE_REVOKED) error instructs the user to re-enable the webcam using the settings charm and then to tap a button to restart a video preview. The code behind the button should call InitializeAsync before making any other calls.

See Adding Multimedia to your app for tutorials.

 

Related topics

DeviceCapability element reference
App capability declarations
How to specify device capabilities in a package manifest (manually)
How to use a flyout
How to use a dialog

 

 

Build date: 11/16/2013

Show:
© 2016 Microsoft