Intent Filter: ما هو، كيف يعمل ويستخدم في التطوير

ما هو Intent Filter؟

Intent Filter هو عنصر تكوين في تطبيق Android يُخبر النظام عن قدرة المكون على معالجة أنواع معينة من النوايا الضمنية. على عكس Intents الصريحة التي تُحدد فئة معينة، تحتوي Intents الضمنية فقط على وصف للإجراء المطلوب، والنظام نفسه يجد المكون المناسب بناءً على الفلاتر المسجلة.

تُعلن الفلاتر داخل المكون — Activity أو Service أو BroadcastReceiver — في ملف AndroidManifest.xml. يمكن أن يحتوي كل فلتر على عناصر متعددة من action و category و data. يمكن أن يكون للمكون عدد غير محدود من Intent Filters، كل منها يصف سيناريو معالجة منفصل.

الدور في بنية Android

يطبق Intent Filter مبدأ الاقتران الضعيف بين مكونات التطبيقات. التطبيق A ليس مضطرًا لمعرفة وجود التطبيق B — فهو ببساطة يرسل Intent مع وصف الإجراء، ويقوم النظام بتوجيهه بناءً على الفلاتر. هذه الآلية هي أساس Share Sheet واختيار المتصفح ومعالجة الروابط العميقة.

أنواع Intent: الصريحة والضمنية

تحدد Intents الصريحة فئة مكون معينة للتشغيل. تُستخدم للتنقل الداخلي داخل تطبيق واحد عندما يعرف المطور بالضبط أي Activity يجب أن تفتح. تحتوي Intents الضمنية فقط على وصف للإجراء، ويتم تحديد المكون بواسطة النظام ديناميكيًا.

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

مقارنة بين Intents الصريحة والضمنية

هيكل Intent Filter في البيان

يتكون كل Intent Filter من ثلاث مجموعات من العناصر — action و category و data — يحدد مزيجها أي Intents سيتلقاها المكون. يعتبر الفلتر مستوفيًا إذا تطابق Intent مع عنصر واحد على الأقل من كل مجموعة.

تصف Action الإجراء الذي يتم تنفيذه — العرض أو التحرير أو الإرسال. Category تُضيف سياق معالجة إضافي — مثلاً إمكانية التشغيل من المتصفح. Data تُحدد تنسيق المعلومات التي تتم معالجتها عبر URI أو نوع MIME.

مكونات وسم intent-filter

مثال على Intent Filter لـ Activity تفتح روابط لملفات تعريف المستخدمين. يتضمن الفلتر جميع المجموعات الثلاث من العناصر للتوجيه الدقيق.

<activity android:name=".ProfileActivity">
    <intent-filter>
        <action
            android:name="android.intent.action.VIEW" />
        <category
            android:name="android.intent.category.DEFAULT" />
        <category
            android:name="android.intent.category.BROWSABLE" />
        <data
            android:scheme="myapp"
            android:host="profile" />
    </intent-filter>
</activity>

لاحظ التحديد الإلزامي لـ category DEFAULT — بدونها لن يقوم النظام بتمرير Intents ضمنية إلى المكون. تُضاف فئة BROWSABLE إذا كان يجب معالجة الرابط من المتصفح.

Intent Filter للروابط العميقة

يتم إعداد الرابط العميق على Android عبر Intent Filter مع action VIEW ووسم data يحتوي على المخطط والمضيف والمسار. عند اتباع رابط مثل myapp://profile/42، يجد النظام Activity ذات الفلتر المناسب ويشغلها مع URI المُمرر. من المهم تكوين pathPrefix أو pathPattern أو path بشكل صحيح للمطابقة الدقيقة.

بدءًا من Android 6 (API 23)، تمت إضافة دعم App Links — روابط عميقة موثقة عبر HTTPS. تستخدم App Links نفس Intent Filter ولكن مع تحقق إضافي من المجال عبر Digital Asset Links. بعد التحقق، يفتح النظام التطبيق تلقائيًا دون مربع حوار اختيار.

وسم Data لعنوان URL

مثال على فلتر لـ App Link مع التحقق عبر رابط HTTPS. في هذه الحالة، المخطط دائمًا https والمضيف يطابق المجال المحدد في Digital Asset Links.

<intent-filter android:autoVerify="true">
    <action
        android:name="android.intent.action.VIEW" />
    <category
        android:name="android.intent.category.DEFAULT" />
    <category
        android:name="android.intent.category.BROWSABLE" />
    <data
        android:scheme="https"
        android:host="example.com"
        android:pathPrefix="/profile" />
</intent-filter>

يخبر السمة autoVerify النظام بالتحقق من Digital Asset Links عند تثبيت التطبيق. إذا نجح التحقق، يصبح التطبيق تلقائيًا المعالج الافتراضي للمجال والمسارات المحددة.

معالجة Intent في مكونات التطبيق

بعد أن يختار النظام مكونًا لمعالجة Intent، يجب على المطور استخراج البيانات من intent الوارد داخل المكون الهدف. لـ Activity، يُستخدم method getIntent() في onCreate()؛ لـ BroadcastReceiver، method onReceive() حيث يتم تمرير Intent كمعامل.

يتضمن استخراج البيانات الحصول على action لتحديد نوع العملية، و data لـ URI ومعاملات extra للمعلومات الإضافية. قد يكون كل من هذه العناصر غائبًا، لذلك من الضروري التحقق من null قبل الاستخدام.

كود المعالجة في Activity

مثال على معالجة رابط عميق وارد في Activity بلغة Kotlin. يستخرج الكود URI من Intent ويتخذ قرارات التنقل بناءً على المضيف والمسار.

class ProfileActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        val uri = intent?.data
        if (uri?.host == "profile") {
            val userId = uri.lastPathSegment
            loadProfile(userId)
        }
    }
}

يُوصى باستخدام عامل الاستدعاء الآمن للتحقق من intent و data بقيمة null، حيث قد يتم تشغيل النشاط بدون رابط عميق وارد. يجب أيضًا التحقق من host و pathSegment بقيمة null قبل استخدامهما في التنقل.

الأولوية وحل التعارضات

إذا سجلت تطبيقات متعددة Intent Filter يطابق نفس Intent الضمني، يعرض النظام على المستخدم مربع حوار اختيار. يمكن للمستخدم اختيار تطبيق للاستخدام لمرة واحدة أو تعيين معالج افتراضي. بدءًا من Android 10، يتم عرض مربع حوار الاختيار فقط عند الاستدعاء الأول، وبعد ذلك يتذكر النظام اختيار المستخدم.

لإدارة الأولوية، يُستخدم السمة android:priority في وسم intent-filter. كلما زادت القيمة، زادت أولوية المكون عند حل التعارضات. ومع ذلك، لا تعمل الأولوية للفلاتر من تطبيقات مختلفة — في هذه الحالة، يتم دائمًا عرض مربع حوار الاختيار إذا لم يتم تعيين أي تطبيق كافتراضي.

مربع حوار اختيار التطبيق

يمكن للمطور استدعاء مربع حوار الاختيار برمجيًا عبر Intent.createChooser()، مع تمرير Intent الهدف وعنوان. هذا مفيد عندما يريد التطبيق أن يقدم للمستخدم صراحة اختيار معالج، حتى إذا كان هناك تطبيق افتراضي مُعد. مثلاً، عند إرسال الصور إلى الشبكات الاجتماعية عبر ACTION_SEND مع createChooser يضمن عرض مربع الحوار بغض النظر عن الإعدادات الافتراضية.

الأخطاء الشائعة عند إعداد Intent Filter

أحد أكثر الأخطاء شيوعًا هو غياب الفئة DEFAULT في Intent Filter. ينسخ المطورون التكوين من الأمثلة لكنهم ينسون إضافة هذه الفئة، ونتيجة لذلك لا تتلقى Activity Intents ضمنية. النظام ببساطة لا يرى الفلتر للاستدعاءات الضمنية، على الرغم من أن Intents الصريحة تستمر في العمل.

الخطأ الثاني الشائع هو التحديد غير الصحيح لـ scheme في وسم data بدون URI كامل. إذا تم تحديد المخطط فقط ولكن لم يتم تحديد المضيف، سيقبل الفلتر جميع الروابط بهذا المخطط من أي مصدر، مما قد يؤدي إلى استدعاءات غير مرغوب فيها من مصادر غير موثوقة. يُوصى دائمًا بتحديد scheme و host على الأقل.

الخطأ الثالث هو عدم التحقق من null لـ intent.data في كود Activity. إذا تم تشغيل Activity ليس عبر رابط عميق ولكن بالطريقة القياسية من المشغل، لا يحتوي Intent على URI. الوصول إلى intent.data بدون تحقق يسبب NullPointerException وتعطل التطبيق. استخدم دائمًا intent?.data?.toString() مع عامل الاستدعاء الآمن.