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.
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 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.
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:
The Settings charm provides flyouts that let the user enable or disable sensitive capabilities, pictured here:
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.
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.
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.
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 disabled||Sample 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. ”
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.
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."
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.
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.
This table lists API info for disabling and reenabling sensitive device capabilities.
|Capability||Info on enable and disable|
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:
Apps that use Windows.Media.Capture.MediaCapture to preview or capture audio, video, or photos should note the following:
See Adding Multimedia to your app for tutorials.
- 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