محتويات الدورة

تطوير Android / المتوسط: الحالة والبيانات والميزات الشاملة / الدرس 10

الأذونات والتكامل المحترم مع المنصة

ابنِ ميزات الكاميرا والإشعارات الاختيارية حول قصد المستخدم والرفض وعقود المنصة الخاصة بالإصدارات.

وقت القراءة التقريبي: 4 دقيقةتاريخ مراجعة المحتوى
في هذه الصفحة

أهداف الدرس

  • افصل الإعلان عن المنح أثناء التشغيل وعن توفر الميزة.
  • وفّر حالات مفيدة عند الرفض وسحب الإذن.

ابدأ ببديل عن طلب الإذن

ينبغي للميزة طلب الوصول اللازم للإجراء الذي اختاره المستخدم فقط. قد يستخدم اختيار غلاف منتقي صور النظام بدلاً من الوصول الواسع للمكتبة. يمكن لاختيار مستند استخدام عقد نظام وURI محدد الصلاحية. يختلف إذن الاستخدام المباشر للكاميرا عن طلب الالتقاط من تطبيق كاميرا آخر عبر عقده. راجع مسار الواجهة الفعلي قبل إضافة الأذونات. يزيد كل إعلان غير لازم الصيانة وارتباك المستخدم، بينما يقدم تفاعل أضيق مع المنصة نموذج ملكية وخصوصية أوضح غالباً.

اطلب الوصول في سياق الميزة

تحتاج الأذونات الخطيرة معالجة أثناء التشغيل على Android 6.0، أي API 23، وما بعده وفق الاستهداف وقواعد المنصة. أعلن الإذن المطلوب وافحص منحه الحالي قبل الاستخدام، واشرح المبرر عند ملاءمته واطلبه عبر عقد Activity Result. المنح السابق ليس دائماً؛ يستطيع المستخدم والمنصة سحب الوصول. لا تطلب الإذن عند كل إعادة تركيب أو تكرره بعد الرفض. أبقِ ميزات القراءة غير المرتبطة متاحة ودع المستخدم يرفض دون الوقوع في حلقة نوافذ نظام.

kotlin طلب كاميرا مباشرة يملكه نشاط
class CaptureActivity : ComponentActivity() {
    private val cameraPermission = registerForActivityResult(
        ActivityResultContracts.RequestPermission()
    ) { granted -> showCameraAvailability(granted) }

    fun onDirectCameraRequested() {
        if (ContextCompat.checkSelfPermission(this, Manifest.permission.CAMERA) ==
            PackageManager.PERMISSION_GRANTED) showCameraAvailability(true)
        else cameraPermission.launch(Manifest.permission.CAMERA)
    }
}

أعلن CAMERA في manifest واستورد واجهات Activity Result وContextCompat من AndroidX. نفذ showCameraAvailability لعرض حالة السماح أو الرفض وأضف مسار المبرر عند الحاجة. ما زال فتح العتاد يحتاج فحوصاً حالية وإدارة دورة الحياة؛ لا يفتح المقتطف الكاميرا.

افصل إذن الإشعارات عن تسليمها

قدم Android 13، أي API 33، إذن POST_NOTIFICATIONS للإشعارات غير المستثناة. يختلف توقيت الطلب بين التطبيقات التي تستهدف API 33 أو أعلى والأهداف الأقدم، فلا تعمم سلوك محاكٍ واحد. تهم قنوات الإشعارات أيضاً منذ Android 8.0، أي API 26؛ فلا يتجاوز منح الإذن قناة محظورة. تظل الخدمة الأمامية ملزمة بعقد إشعارها، ولا يتطلب إطلاقها بذاته الحصول على POST_NOTIFICATIONS. أبقِ القواعد منفصلة بدلاً من اختزال كل إشعار مفقود إلى قيمة إذن منطقية واحدة.

kotlin فحص إذن محمي بمستوى الإصدار
fun needsNotificationPermission(context: Context): Boolean =
    Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU &&
        ContextCompat.checkSelfPermission(
            context, Manifest.permission.POST_NOTIFICATIONS
        ) != PackageManager.PERMISSION_GRANTED

ترجم باستخدام SDK يعرّف ثوابت API 33 وأعلن POST_NOTIFICATIONS واطلبه فقط من مسار واجهة مناسب يبدأه المستخدم. تعني false أن هذا الفحص لا يحتاج طلباً، ولا تثبت تفعيل إشعارات التطبيق أو قناة محددة.

عامل الرفض كنتيجة مدعومة

رفض الإذن اختيار مستخدم وليس حالة تعطل. اشرح الميزة غير المتاحة واعرض بديلاً مفيداً كإدخال العنوان يدوياً بدلاً من المسح. لا تسمح بعض حالات الرفض بطلب نظام آخر، ولا تحدد واجهات المبرر وحدها كل التاريخ بدقة. وفّر طريق الإعدادات عند ملاءمته دون إلحاح. للوصول الخاص كالمنبهات الدقيقة سير عمل مختلف ولا يعامل كإذن خطير عادي. اختبر الرفض الأول والمتكرر وسحب الإذن والعودة من الإعدادات منفصلة.

اختبر الجهاز والاستهداف وحالة المستخدم معاً

يعتمد سلوك المنصة على API الجهاز وtargetSdk وتنفيذ المكتبة والإعدادات الحالية. ابنِ مصفوفة صغيرة تشمل أقدم بيئة مدعومة وحدود تغير السلوك ذات الصلة. تحقق من نتيجة الإذن ومن إجراء الميزة معاً؛ فلا ينشئ الإذن الممنوح عتاداً غائباً ولا يفعّل خدمة نظام معطلة ولا يضمن تسليماً بعيداً. اجعل حالة الميزة قابلة للمراقبة عند العودة من الإعدادات وتجنب الاحتفاظ بعلم إذن قديم كسلطة دائمة. وثّق افتراضات التوافق قرب التكامل.

الأخطاء الشائعة وإصلاحها

تتكرر طلبات الإذن أثناء عرض الشاشة

لماذا يحدث؟
يعمل الطلب داخل جسم الدالة التركيبية.
كيف تصلحه؟
أطلقه من حدث مستخدم عبر عقد مسجل ثابت.
كيف تتجنب تكراره؟
راجع مساري الرفض وإعادة التركيب معاً.

تبقى الإشعارات غير مرئية بعد منح الإذن

لماذا يحدث؟
قناة الإشعارات أو إعداد التطبيق محظور.
كيف تصلحه؟
افحص إنشاء القناة وإعداداتها ومتطلبات النشر.
كيف تتجنب تكراره؟
اختبر حالة الإذن والقناة منفصلتين.

يثير إجراء كاميرا كان يعمل SecurityException

لماذا يحدث؟
اعتمد التطبيق على علم منح مخزن قديم.
كيف تصلحه؟
أعد فحص الإذن الحالي وعالج فقده عند العملية المحمية.
كيف تتجنب تكراره؟
ضمّن اختبارات السحب والعودة من الإعدادات.

اختبر فهمك

1. يريد المستخدم اختيار غلاف واحد فقط. قارن الوصول الواسع للوسائط بعقد منتقي النظام.

اعرض الحل المشروح

يضيّق المنتقي الوصول إلى المحتوى المختار ويتجنب إذن مكتبة واسعاً غير لازم. عالج الإلغاء وعمر URI المعاد. إذا لزم استمرار الوصول لمعالجة خلفية لاحقة فاتبع خيارات الاستمرار الموثقة للعقد بدلاً من افتراض بقاء URI قابلاً للقراءة دائماً.

2. على API 33+ الإذن ممنوح لكن قناة تذكير معطلة. ماذا يستنتج التطبيق؟

اعرض الحل المشروح

بوابة إذن التشغيل مستوفاة لكن القناة لا تسلّم عادياً بإعدادها الحالي. احترم اختيار المستخدم واشرح الإعداد المحدد إذا طلب التذكير. لا يستطيع إعادة طلب الإذن تجاوز القناة، وسيشخّص الإلحاح المشكلة بصورة خاطئة.

أهم ما تعلمته

  • يبدأ أقل وصول باختيار عقد المنصة الصحيح.
  • حالة الإذن حالية وقابلة للسحب.
  • تؤثر API الجهاز وسلوك الاستهداف والإعدادات في التكامل.

المراجع الرسمية