Permissions handling in React Native - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ ui_behavior

intermediate

What happens when permission is denied in React Native?

Consider a React Native app that requests camera permission using react-native-permissions. What is the expected behavior if the user denies the permission request?

React Native

import {check, request, PERMISSIONS, RESULTS} from 'react-native-permissions';

async function requestCameraPermission() {
  const result = await request(PERMISSIONS.IOS.CAMERA);
  return result;
}

A The permission request returns 'denied', and the app can handle this state gracefully.

B The app navigates to the home screen without any permission check.

C The permission is automatically granted after denial without user action.

D The app immediately crashes due to lack of permission.

💡 Hint

Think about how permission APIs usually respond when a user denies access.

When a user denies permission, the API returns a 'denied' status. The app should detect this and handle it, such as showing a message or disabling features that require the permission.

🧠 Conceptual

intermediate

Which permission status means the user permanently denied access?

In React Native permissions handling, which status indicates the user has permanently denied permission and the app cannot request it again without user action in settings?

A "denied"

B "granted"

C "blocked"

D "unavailable"

💡 Hint

This status means the user must manually enable permission in device settings.

The "blocked" status means the user permanently denied permission, so the app cannot prompt again and must direct the user to settings.

❓ lifecycle

advanced

When should you check permissions in a React Native app lifecycle?

You want to ensure your React Native app always has the latest permission status for location access. When is the best time to check permissions to update your UI accordingly?

A Never check; assume permissions are granted.

B Only once when the app is first installed.

C Only when the user clicks a button to request permission.

D Every time the app component mounts or gains focus.

💡 Hint

Think about when the user might change permissions outside the app.

Permissions can change anytime, including when the app is backgrounded. Checking on component mount or focus ensures the app UI reflects current permission status.

🔧 Debug

advanced

Why does this permission request code fail to update UI?

Given this React Native code snippet, why does the UI not update after requesting permission?

const [cameraStatus, setCameraStatus] = useState('unknown');

useEffect(() => {
  request(PERMISSIONS.ANDROID.CAMERA).then(status => {
    cameraStatus = status;
  });
}, []);

A The state variable is assigned directly instead of using the setter function.

B The permission constant is incorrect for Android.

C The useEffect hook is missing a dependency array.

D The permission request API is asynchronous and must use async/await.

💡 Hint

How do you update React state properly?

Directly assigning to the state variable does not update React state or trigger a re-render. The setter function must be used.

❓ navigation

expert

How to navigate user to app settings after permission is blocked?

In React Native, if a permission is 'blocked', the app should guide the user to the app settings page to enable it manually. Which code snippet correctly opens the app settings screen?

React Native

import {Linking, Platform} from 'react-native';

function openSettings() {
  if (Platform.OS === 'ios') {
    Linking.openURL('app-settings:');
  } else {
    Linking.openSettings();
  }
}

A Use Linking.openURL('app-settings:') on both iOS and Android.

B Use Linking.openSettings() on Android and Linking.openURL('app-settings:') on iOS.

C Use Linking.openSettings() on both platforms.

D Use Linking.openURL('settings:') on iOS and Linking.openSettings() on Android.

💡 Hint

Different platforms require different URL schemes or methods.

On iOS, the URL scheme 'app-settings:' opens settings. On Android, Linking.openSettings() is the correct method.