Device Permissions နှင့် Capabilities

နားလည်ထားရမယ့် အချက်

Mobile app တွေက camera, location, notifications စတဲ့ device capability တွေကို အသုံးချနိုင်ပေမယ့် အားလုံးဟာ user ရဲ့ explicit permission ကို အရင်လိုအပ်ပါတယ်။ OS ဟာ request grant ဖြစ်မဖြစ် အဆုံးအဖြတ်ပေးသူ ဖြစ်ပါတယ်။

Universal architecture: feature needs capability -> in-context ရှင်းပြ -> request permission -> allowed ဆိုရင် feature အလုပ်လုပ်၊ denied ဆိုရင် graceful fallback။

Denial ဟာ crash ဖြစ်စေရမယ့် failure state မဟုတ်ပါဘူး — location denial ဆိုရင် location-dependent feature ကိုသာ disable လုပ်ပြီး ကျန်အပိုင်းကို အသုံးပြုနိုင်အောင် ထားသင့်ပါတယ်။

PERMISSION REQUEST FLOW
-----------------------
PERMISSION REQUEST FLOW
-----
Feature needs a capability (camera, location, etc.)
        |
        v
Explain why, in context (not at app launch)
        |
        v
Request permission from the OS
        |
   +----+----+
   |         |
Allowed    Denied
   |         |
   v         v
Feature    Graceful fallback
 works     (not a broken feature)

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

App တစ်ခု လုပ်နေတဲ့ permission request တိုင်းကို audit လုပ်ပါ — specific action နဲ့ ချိတ်ဆက်ထားလား၊ explanation ပါလား၊ user "No" ဆိုရင် feature ဘာဖြစ်သွားမလဲ။

explanation မပါဘဲ launch မှာ camera ကို ချက်ချင်းတောင်းတဲ့ app ဟာ user ကို reflexive "Deny" လေ့ကျင့်ပေးသလိုဖြစ်ပြီး၊ camera icon tap ရင်မှ trigger ဖြစ်ပြီး line တစ်ကြောင်း explanation ပါတဲ့ request ကတော့ ပိုများစွာ grant ဖြစ်သည်။

Graceful fallback ဟာ good practice ရဲ့ ကျန်တဲ့တစ်ဝက်ပါ — location denied ဖြစ်ရင် delivery app ဟာ ပျက်နေတဲ့ map အစား address manual ရိုက်ခွင့်ပြုနိုင်ပါတယ်။

• Universal architecture: feature needs capability -> explain in context -> request -> allowed/denied path
• Permission ကို feature အသုံးပြုတဲ့ အချိန်တွင်သာ request လုပ်သင့်ပြီး launch အချိန်တွင် blanket request မလုပ်သင့်ပါ
• Denial ဟာ crash ဖြစ်ရမည့် failure မဟုတ်ဘဲ graceful fallback ဖြင့် handle လုပ်ရမည်

Permission Request Best Practices

• Feature ကို တကယ်အသုံးပြုတဲ့ အချိန်မှသာ permission ကို request လုပ်ပါ
• System prompt မပေါ်ခင် ဘာကြောင့်လိုအပ်လဲ ရှင်းပြပါ
• App launch မှာ permission အားလုံးကို တောင်းခြင်းကို ရှောင်ပါ
• Denial ကို graceful fallback ဖြင့် handle လုပ်ပါ (feature ချိုးဖျက်မခံပါနှင့်)
• လိုအပ်တာထက် ပိုပြီး data (သို့) access ကို မကောက်ယူပါနှင့်

အတူတူ စမ်းရေးကြည့်မယ်

function followsPermissionBestPractice(request) {
  const { isRequestedInContext, hasExplanation, isRequestedAtLaunch } = request;
  const issues = [];
  if (!isRequestedInContext) issues.push("not requested in the context of actual feature use");
  if (!hasExplanation) issues.push("no explanation given before requesting");
  if (isRequestedAtLaunch) issues.push("requested at app launch instead of when needed");
  return { followsBestPractice: issues.length === 0, issues };
}

const cameraRequestDoneWell = {
  isRequestedInContext: true,
  hasExplanation: true,
  isRequestedAtLaunch: false
};

const locationRequestDonePoorly = {
  isRequestedInContext: false,
  hasExplanation: false,
  isRequestedAtLaunch: true
};

console.log("Camera request done well:", JSON.stringify(followsPermissionBestPractice(cameraRequestDoneWell)));
console.log("Location request done poorly:", JSON.stringify(followsPermissionBestPractice(locationRequestDonePoorly), null, 2));

Camera request done well: {"followsBestPractice":true,"issues":[]}
Location request done poorly: {
  "followsBestPractice": false,
  "issues": [
    "not requested in the context of actual feature use",
    "no explanation given before requesting",
    "requested at app launch instead of when needed"
  ]
}

အကောင်းဆုံး request ဟာ issue လုံးဝမရှိပြီး၊ launch မှာ explanation မပါဘဲ blind တောင်းတဲ့ request ကတော့ issue သုံးမျိုးလုံး ပါဝင်နေတာကို တွေ့ရသည်။

Permissions overview — Android Developers — How Mobile Apps Work