Notification Permission: ما هو، أنواع الإشعارات ومبدأ العمل

ما هو Notification Permission؟

Notification Permission هو إذن نظام ينظم قدرة التطبيق على إرسال الإشعارات للمستخدم. قبل Android 13، كانت جميع التطبيقات قادرة على عرض الإشعارات بدون طلب — كان يكفي declaration الإذن في البيان. ومع ذلك، مع زيادة البريد العشوائي والإشعارات المزعجة، قدم Google طلباً إلزامياً في وقت التشغيل، مماثلاً لنظام iOS.

على iOS، كان إذن الإشعارات إلزامياً منذ iOS 8، وبدءاً من iOS 12 ظهرت الإشعارات المؤقتة — إشعارات صامتة يتم تسليمها بدون صوت وتظهر في مركز الإشعارات بدون طلب صريح. الإشعارات المؤقتة تسمح للمطور بعرض قيمة الإشعارات للمستخدم قبل طلب الإذن الكامل.

وفقاً لـ Localytics (2024)، يوافق 61% من مستخدمي iOS و 55% من مستخدمي Android على تلقي الإشعارات الفورية بعد الطلب. يعتمد معدل الموافقة بشكل مباشر على سياق الطلب: التطبيقات التي تطلب الإذن بعد أول تفاعل قيم تحصل على موافقات أكثر بنسبة 40% من تلك التي تطلب عند التشغيل الأول.

تطور أذونات الإشعارات

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

Android: من الوصول الحر إلى التحكم الصارم

قبل Android 13 (2022)، كان أي تطبيق قادراً على عرض الإشعارات بدون موافقة المستخدم. Android 8.0 (2017) قدم قنوات الإشعارات، Android 12 (2021) أضاف الحظر التلقائي للإشعارات المزعجة، وأخيراً Android 13 جعل طلب POST_NOTIFICATIONS إلزامياً في وقت التشغيل. للتطبيقات التي targetSdkVersion أقل من 33، يمنح النظام الإذن تلقائياً، لكن Google Play يتطلب تحديث targetSdkVersion إلى 33+ منذ أغسطس 2023.

iOS: التعزيز التدريجي للتحكم

iOS 8 (2014) قدم طلب الإذن الإلزامي عبر UIUserNotificationSettings. iOS 10 (2016) قدم UNUserNotificationCenter مع دعم الإشعارات الغنية. iOS 12 (2018) أضاف الإشعارات المؤقتة والإشعارات المجمعة. iOS 15 (2021) قدم وضع التركيز، الذي يمكنه حظر الإشعارات بغض النظر عن إذن التطبيق. App Tracking Transparency (iOS 14.5) لا يرتبط بالإشعارات ولكنه أثر أيضاً على الثقافة العامة لطلبات الأذونات.

الوضع الحالي

حالياً، تتطلب كلتا المنصتين طلب Notification Permission في وقت التشغيل. لم يعد بإمكان المطور الاعتماد على التمكين التلقائي للإشعارات. المستخدم يتحكم بشكل كامل في التطبيقات التي يمكنها إشعاره. قنوات الإشعارات على Android وفئات الإشعارات على iOS تسمح للمستخدم بضبط أنواع التنبيهات التي يتلقاها بدقة.

Notification Permission على Android

Notification Permission على Android يتم تمكينه عبر إذن POST_NOTIFICATIONS المعلن في البيان، متبوعاً بطلب في وقت التشغيل لـ Android 13+.

التصريح في البيان

لـ Android 13+، يجب التصريح عن إذن POST_NOTIFICATIONS في AndroidManifest.xml. للتوافق مع الإصدارات السابقة مع Android 12 والإصدارات الأقدم، يمنح النظام الإذن تلقائياً — لا حاجة لإجراءات إضافية.

<uses-permission android:name="android.permission.POST_NOTIFICATIONS" />

طلب وقت التشغيل في Kotlin

يتم طلب إذن POST_NOTIFICATIONS عبر Activity Result API. من المهم التحقق من إصدار SDK: على Android 12 والإصدارات الأقدم، لا حاجة لطلب — يعتبر الإذن ممنوحاً تلقائياً.

private val notificationPermissionLauncher =
    registerForActivityResult(ActivityResultContracts.RequestPermission()) { granted ->
    if (granted) {
        createNotificationChannel()
        showPushNotification()
    } else {
        logPermissionDenied()
    }
}

fun requestNotificationAccess() {
    if (Build.version.SDK_INT <= Build.VERSION_CODES.S_V2) {
        // Android 12 والإصدارات الأقدم — الإذن ممنوح تلقائياً
        showNotification()
        return
    }
    if (ContextCompat.checkSelfPermission(this,
        Manifest.permission.POST_NOTIFICATIONS) == PackageManager.PERMISSION_GRANTED) {
        showNotification()
    } else {
        notificationPermissionLauncher.launch(Manifest.permission.POST_NOTIFICATIONS)
    }
}

إنشاء قنوات الإشعارات

على Android 8.0+، يجب على التطبيق إنشاء قناة إشعارات عبر NotificationChannel قبل إرسال أول إشعار. القناة لها مستوى أهمية من IMPORTANCE_NONE إلى IMPORTANCE_HIGH، والذي يحدد ما إذا كان الإشعار سيظهر مع صوت وكلافتة. إذا قام المستخدم بتعطيل الإشعارات للتطبيق، فلن يكون للقنوات الجديدة تأثير حتى إعادة التمكين في الإعدادات. يُنصح بإنشاء قنوات منفصلة لأنواع مختلفة من التنبيهات: الرسائل، الإعلانات، أحداث النظام.

private fun createNotificationChannel() {
    val channel = NotificationChannel(
        CHANNEL_ID_MESSAGES,
        "الرسائل",
        NotificationManager.IMPORTANCE_HIGH
    ).apply {
        description = "إشعارات الرسائل الجديدة"
        enableVibration = true
    }
    val manager = getSystemService(NotificationManager::class.java)
    manager.createNotificationChannel(channel)
}

Notification Permission على iOS

Notification Permission على iOS يتم طلبه عبر UNUserNotificationCenter. توصي Apple بنهج من خطوتين: أولاً طلب الإشعارات المؤقتة، ثم بعد إظهار القيمة، طلب الإذن الكامل.

طلب Swift مع الخيار المؤقت

الإشعارات المؤقتة هي إشعارات صامتة تظهر في مركز الإشعارات بدون صوت أو لافتة. لا تتطلب موافقة صريحة من المستخدم وتسمح للتطبيق بإظهار قيمة الإشعارات قبل الطلب الكامل. بعد تلقي عدة إشعارات مؤقتة، يمكن للمستخدم تمكين الإشعارات الكاملة عبر القائمة داخل الإشعار نفسه.

import UserNotifications

func requestNotificationPermission() {
    let center = UNUserNotificationCenter.current()
    center.requestAuthorization(options: [.alert, .badge, .sound]) { granted, error in
        if let error = error {
            print("Notification error: \(error.localizedDescription)")
            return
        }
        if granted {
            registerForRemoteNotifications()
        } else {
            handleDeniedPermission()
        }
    }
}

func requestProvisionalOnly() {
    let center = UNUserNotificationCenter.current()
    center.requestAuthorization(options: [.provisional, .alert, .badge, .sound]) { granted, error in
        // مؤقت — المستخدم لا يرى الحوار
        // تصل الإشعارات بدون صوت إلى مركز الإشعارات
        registerForRemoteNotifications()
    }
}

التحقق من الحالة وإعدادات النظام

يمكن الحصول على حالة Notification Permission الحالية على iOS عبر UNUserNotificationCenter.current().getNotificationSettings. الحالة .authorized أو .denied أو .provisional أو .notDetermined تسمح للتطبيق باختيار السلوك الصحيح. بعد الرفض الأول، لا يظهر حوار النظام مرة أخرى — يجب توجيه المستخدم إلى الإعدادات عبر UIApplication.openSettingsURLString. توصي Apple أيضاً بمعالجة الحالة .ephemeral (iOS 17+)، التي توفر إشعارات مؤقتة لسيناريوهات محددة.

أفضل ممارسات طلب الإشعارات

أفضل الممارسات لطلب Notification Permission تهدف إلى زيادة معدل الموافقة وتقليل فقدان المستخدمين. الطلب غير الصحيح لا يمكن فقط أن يحرم التطبيق من القدرة على إرسال الإشعارات، بل قد يؤدي أيضاً إلى إلغاء تثبيت التطبيق.

لا تطلب عند التشغيل الأول

الأنماط المعاكسة الأكثر شيوعاً هو طلب Notification Permission عند التشغيل الأول للتطبيق. المستخدم لا يفهم بعد قيمة التطبيق ومن المحتمل جداً أن يرفض. اللحظة المثلى هي بعد أن يقوم المستخدم بأول إجراء ذي قيمة: تقديم طلب، إرسال رسالة، الاشتراك في التحديثات. طلب ما بعد القيمة يزيد معدل الموافقة إلى 65-75%.

استخدم شاشة ما قبل الإذن

قبل حوار النظام، اعرض شاشتك الخاصة مع أمثلة للإشعارات التي سيتلقاها المستخدم. اعرض نموذجاً لإشعار مستقبلي مع نص وأيقونة. إذا رأى المستخدم أن الإشعارات ستكون مفيدة وغير مزعجة، فمن المرجح أن يوافق. معاينة الإشعار على شاشة ما قبل الإذن هي تقنية فعالة تزيد معدل الموافقة بنسبة 35-50%.

استخدم الإشعارات المؤقتة على iOS

طلب الإشعارات المؤقتة بشكل استباقي على iOS يسمح بتسليم الإشعارات بدون موافقة صريحة من المستخدم. إذا رأى المستخدم قيمة في هذه الإشعارات، يمكنه تمكين الإشعارات الكاملة عبر القائمة السياقية للإشعار. توصي Apple بهذا النهج لتطبيقات الأخبار وتطبيقات الطقس والخدمات الأخرى حيث تكون الإشعارات إعلامية وليست معاملاتية. وفقاً لـ Apple WWDC 2024، يزيد هذا النهج من معدل الموافقة الكاملة بنسبة 20-30%.