MA8: Device features, permissions, background work and privacy
Using the phone's features
🎯You'll be able to
Use device features through Expo modules or native libraries, check they're available, and plan for phones where they aren't.
🏠The everyday picture
A hotel room has a kettle, a safe and a hairdryer, but not every room has all three. A good guest checks before planning to use one, and asks reception if it's missing.
📘What it really is
-
Modules wrap features: the camera and image picker, location, notifications, SQLite, secure storage, background tasks, haptics and more. Install them so their version matches your Expo SDK.
-
Check availability: some phones lack a feature (no fingerprint sensor, location turned off). Ask the module before relying on it.
- Plan the fallback: typing a farm ID if the scanner can't run, or saving a visit without location.
- Test on devices: simulators lack some hardware; real phones behave differently.
- Each feature brings rules: a permission, an explanation for the user, and an entry in the store's privacy answers.
📝A worked example
Input: KhetNote wants to record where each visit happened.
Steps:
- Choose the location module and decide: approximate location is enough to confirm the village.
- Check location services are on; if not, save the visit without location and say so.
- List what this adds to the release: a permission, its explanation text, and a line in the data safety answers.
Expected output: a feature plan that works with and without location.
🌍Where it's used
- Delivery apps use location and the camera for proof of delivery.
- Banking apps use biometrics to unlock.
- Inspection apps attach photos and positions to reports.
📝Case scenario
An attendance app required fingerprint sign-in. On phones without a sensor it simply wouldn't open, and staff couldn't mark attendance. Adding a PIN fallback, offered when no sensor is available, fixed it.
🖱️Try it
Pick one device feature for KhetNote. Write what it needs, how you'd check it's available, and what happens if it isn't. Success: a fallback that keeps the adviser's work going.
⚠️Common mistakes
- Assuming hardware exists. Sign: crashes on some phones. Fix: check availability.
- No fallback. Sign: a blocked user. Fix: a way to carry on without the feature.
- Mismatched module versions. Sign: build errors. Fix: install with Expo's command.
🛠️For your project
Section 3 of the capstone design notes plans one device feature, with its permission and fallback.
✅Quick check
Why check that a feature is available before using it?
Show the answer
Some phones lack it or have it turned off, and the app must not crash or block the user.
What should KhetNote do if location is turned off?
Show the answer
Save the visit without location and say so.