يشبه طلب الأذونات على Wear OS طلب الأذونات في تطبيقات الأجهزة الجوّالة، إلى جانب بعض حالات الاستخدام الإضافية. يفترض هذا المستند أنك تفهم آلية عمل أذونات Android. إذا لم يسبق لك إجراء ذلك، راجِع آلية عمل الأذونات على Android.
تمامًا كما هو الحال في تطبيق الهاتف المحمول، يجب أن يمنح المستخدم الأذونات لتطبيق Wear للوصول إلى وظائف معينة. في تطبيقات Wear OS، يمكنك توفير وظائف مفيدة بدون طلب أي أذونات.
سيناريوهات الأذونات
هناك عدة سيناريوهات قد تواجهها عند طلب أذونات خطيرة على Wear OS:
يطلب تطبيق Wear OS الأذونات لتطبيق يعمل على الجهاز القابل للارتداء.
يطلب تطبيق Wear OS أذونات لتطبيق يعمل على الهاتف.
يطلب تطبيق الهاتف أذونات لتطبيق يعمل على الجهاز القابل للارتداء.
يطلب تطبيق الهاتف عدة أذونات لا يمكن استخدامها إلا أثناء اتصال الجهاز القابل للارتداء.
للاطّلاع على جميع هذه السيناريوهات في تطبيق قيد التشغيل، يمكنك مراجعة نموذج ExcersizeSampleCompose على GitHub.
توضح الأقسام التالية كل من هذه السيناريوهات. للحصول على معلومات أكثر تفصيلاً حول طلب الأذونات، يمكنك الاطّلاع على قسم أنماط طلبات الأذونات.
يطلب تطبيق Wear OS إذنًا للأجهزة القابلة للارتداء
عندما يطلب تطبيق Wear OS إذنًا لتطبيق يعمل على الجهاز القابل للارتداء، يعرض النظام مربّع حوار لطلب الحصول على هذا الإذن من المستخدم. لا تطلب الأذونات في تطبيقك إلا عندما يكون واضحًا للمستخدم سبب الحاجة إلى الأذونات لتنفيذ عملية معيّنة.
راجِع مبادئ الأذونات للتأكّد من أنّك تقدّم أفضل تجربة للمستخدمين، ولا تنسَ مراجعة shouldShowRequestPermissionRationale() وتقديم معلومات إضافية حسب الحاجة.
إذا كان أحد التطبيقات أو خلفية شاشة الساعة يتطلّب أكثر من إذن واحد في الوقت نفسه، ستظهر طلبات الأذونات واحدًا تلو الآخر.
يطلب تطبيق Wear OS الحصول على إذن لاستخدام الهاتف
عندما يطلب تطبيق Wear OS إذنًا للهاتف - على سبيل المثال، إذا أراد أحد التطبيقات القابلة للارتداء الوصول إلى الصور أو البيانات الحساسة الأخرى على إصدار الجوّال من التطبيق - يجب أن يرسل تطبيق Wear المستخدم إلى الهاتف لقبول الإذن. هناك، يمكن لتطبيق الهاتف توفير معلومات إضافية للمستخدم باستخدام نشاط ما. في النشاط، قم بتضمين زرين: أحدهما لمنح الإذن والآخر لرفضه.
يطلب تطبيق الهاتف إذنًا للأجهزة القابلة للارتداء
إذا كان المستخدم يستخدم أحد تطبيقات الهاتف وكان التطبيق يتطلب إذنًا للأجهزة القابلة للارتداء، لتحميل الموسيقى مسبقًا في حال انقطاع الاتصال بالهاتف، يرسل تطبيق الهاتف المستخدم إلى الجهاز القابل للارتداء لقبول الإذن. يستخدم إصدار التطبيق القابل للارتداء الطريقة
requestPermissions()
لعرض مربّع حوار أذونات النظام.
يطلب تطبيق "الهاتف" العديد من الأذونات في آنٍ واحد
يمكن لتطبيقات الشركاء على نظام التشغيل Android 12 (المستوى 31 من واجهة برمجة التطبيقات) والإصدارات الأحدث استخدام الملفات الشخصية للأجهزة المصاحبة عند الاتصال بساعة. يؤدي استخدام ملف شخصي إلى تبسيط عملية التسجيل من خلال جمع منح مجموعة من الأذونات الخاصة بنوع الجهاز في خطوة واحدة.
يتم منح الأذونات المجمّعة للتطبيق المصاحب بعد اتصال الجهاز، ولا تستمر إلا أثناء ربط الجهاز. ويؤدي حذف التطبيق أو
إزالة الربط إلى إزالة الأذونات. لمعرفة التفاصيل، يُرجى الاطّلاع على AssociationRequest.Builder.setDeviceProfile().
أنماط طلبات الأذونات
هناك أنماط مختلفة لطلب الأذونات من المستخدمين. حسب الأولوية، وهي:
السؤال في السياق عندما يكون الإذن ضروريًا بوضوح لوظيفة محددة ولكنه ليس ضروريًا لتشغيل التطبيق ككل.
يجب توفير المعلومات السياقية عندما لا يكون سبب طلب الإذن واضحًا وعندما يكون الإذن غير ضروري لتشغيل التطبيق ككل.
يتم شرح هذه الأنماط في الأقسام التالية.
طرح السؤال في السياق
اطلب الأذونات عندما يكون واضحًا للمستخدم سبب الحاجة إلى الإذن لتنفيذ عملية معيّنة. من المرجح أن يمنح المستخدمون إذنًا عندما يفهمون صلته بالميزة التي يريدون استخدامها.
على سبيل المثال، قد يطلب أحد التطبيقات الموقع الجغرافي للمستخدم لعرض الأماكن القريبة ذات الأهمية. عندما ينقر المستخدم للبحث عن الأماكن المجاورة، يمكن للتطبيق طلب إذن تحديد الموقع الجغرافي على الفور نظرًا لوجود علاقة واضحة بين البحث عن الأماكن المجاورة والحاجة إلى إذن تحديد الموقع الجغرافي. إن وضوح هذه العلاقة يجعل من غير الضروري على التطبيق عرض شاشات تعليمية إضافية.
توفير سياق للمحتوى
يوضح الشكل 6 مثالاً على التعليم ضمن السياق. لا يتطلب التطبيق أذونات لبدء الموقت، ولكن هناك إشارة تعليمية مضمنة توضح أن جزءًا من النشاط - اكتشاف الموقع - مقفل. عندما ينقر المستخدم على الإشارة، تظهر شاشة طلب الإذن، ما يتيح للمستخدم إلغاء قفل اكتشاف الموقع.
استخدِم الطريقة
shouldShowRequestPermissionRationale()
لمساعدة تطبيقك في اتّخاذ قرار بشأن توفير المزيد من المعلومات أو لا. لمزيد من التفاصيل، راجِع طلب أذونات التطبيق. وبدلاً من ذلك، يمكنك التحقق من الطريقة التي يتعامل بها نموذج تطبيق المتحدث على GitHub مع عرض المعلومات.
التعامل مع الرفض
إذا رفض المستخدم الإذن المطلوب الذي ليس بالغ الأهمية لنشاط مقصود، لا تحظره من مواصلة النشاط. إذا تم إيقاف أجزاء معيّنة من النشاط بسبب الإذن الذي تم رفضه، يمكنك تقديم ملاحظات مرئية وقابلة للتنفيذ.
يوضح الشكل 7 استخدام أيقونة قفل للإشارة إلى قفل الميزة لأن المستخدم لم يمنح الإذن لاستخدامها.
عند ظهور مربّع حوار أذونات الأجهزة القابلة للارتداء الذي سبق رفضه للمرة الثانية، سيتضمّن الخيار الرفض، عدم الإظهار مرة أخرى. إذا اختار المستخدم هذا الخيار، فإن الطريقة الوحيدة له لمنح هذا الإذن في المستقبل هي الانتقال إلى تطبيق "الإعدادات" على الجهاز القابل للارتداء.
مزيد من المعلومات حول كيفية التعامل مع رفض الإذن
أذونات للخدمات
يمكن للأنشطة فقط استدعاء طريقة
requestPermissions()،
لذا، إذا تفاعل المستخدم مع تطبيقك باستخدام خدمة، من خلال خلفية شاشة الساعة مثلاً، يجب أن تفتح الخدمة نشاطًا قبل طلب
الإذن. في هذا النشاط، قدم تعليمًا إضافيًا حول سبب
الحاجة إلى الإذن.
بوجه عام، لا تطلب الحصول على أذونات لخلفية شاشة الساعة. بدلاً من ذلك، عليك تنفيذ إضافة والسماح للمستخدم باختيار البيانات التي سيتم عرضها من خلال الإضافة.
الإعدادات
يمكن للمستخدم تغيير أذونات تطبيق Wear OS في "الإعدادات" في أي وقت. عندما يحاول المستخدم تنفيذ إجراء يتطلّب إذنًا، عليك أولاً استدعاء الطريقة checkSelfPermission() لمعرفة ما إذا كان التطبيق لديه الإذن اللازم لتنفيذ العملية.
نفِّذ عملية التحقق هذه حتى إذا كان المستخدم قد منح الإذن من قبل، لأنه ربما يكون المستخدم قد أبطله في وقت لاحق.
أفلام مُقترَحة لك
- ملاحظة: يظهر نص الرابط عند إيقاف JavaScript
- طلب أذونات التشغيل
- أذونات البلوتوث
- التواصل في الخلفية