Intent Filter: यह क्या है, डेवलपमेंट में कैसे काम करता है और उपयोग होता है

Intent Filter क्या है?

Intent Filter एक Android एप्लिकेशन का कॉन्फ़िगरेशन तत्व है जो सिस्टम को कुछ प्रकार के अंतर्निहित इरादों को संभालने की कॉम्पोनेंट की क्षमता के बारे में बताता है। स्पष्ट Intents के विपरीत जो एक विशिष्ट वर्ग निर्दिष्ट करते हैं, अंतर्निहित Intents में केवल आवश्यक क्रिया का विवरण होता है, और सिस्टम स्वयं पंजीकृत फ़िल्टर के आधार पर उपयुक्त कॉम्पोनेंट ढूंढता है।

फ़िल्टर AndroidManifest.xml फ़ाइल में एक कॉम्पोनेंट — Activity, Service या BroadcastReceiver — के अंदर घोषित किए जाते हैं। प्रत्येक फ़िल्टर में कई 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 टैग के घटक

उपयोगकर्ता प्रोफ़ाइल के लिंक खोलने वाली Activity के लिए Intent Filter का उदाहरण। फ़िल्टर में सटीक रूटिंग के लिए तीनों समूहों के तत्व शामिल हैं।

<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 पर डीप लिंक को action VIEW और स्कीम, होस्ट और पथ वाले data टैग के साथ Intent Filter के माध्यम से कॉन्फ़िगर किया जाता है। myapp://profile/42 जैसे लिंक का अनुसरण करने पर, सिस्टम मेल खाने वाले फ़िल्टर वाली Activity ढूंढता है और पारित URI के साथ इसे लॉन्च करता है। सटीक मिलान के लिए pathPrefix, pathPattern या path को सही ढंग से कॉन्फ़िगर करना महत्वपूर्ण है।

Android 6 (API 23) से शुरू होकर, App Links के लिए समर्थन जोड़ा गया — HTTPS के माध्यम से सत्यापित डीप लिंक। App Links उसी Intent Filter का उपयोग करते हैं लेकिन Digital Asset Links के माध्यम से अतिरिक्त डोमेन सत्यापन के साथ। सत्यापन के बाद, सिस्टम चयन डायलॉग के बिना स्वचालित रूप से एप्लिकेशन खोलता है।

URL के लिए Data टैग

HTTPS लिंक के माध्यम से सत्यापन के साथ App Link के लिए फ़िल्टर का उदाहरण। इस मामले में स्कीम हमेशा 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 के लिए, onCreate() में getIntent() विधि का उपयोग किया जाता है; BroadcastReceiver के लिए, onReceive() विधि का उपयोग किया जाता है, जहाँ Intent को पैरामीटर के रूप में पारित किया जाता है।

डेटा निष्कर्षण में ऑपरेशन के प्रकार को निर्धारित करने के लिए action प्राप्त करना, URI के लिए data और अतिरिक्त जानकारी के लिए extra पैरामीटर शामिल हैं। इनमें से प्रत्येक तत्व अनुपस्थित हो सकता है, इसलिए उपयोग से पहले null जाँच अनिवार्य है।

Activity में हैंडलिंग कोड

Kotlin में Activity में आने वाले डीप लिंक को संभालने का उदाहरण। कोड Intent से URI निकालता है और होस्ट और पथ के आधार पर नेविगेशन निर्णय लेता है।

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 के लिए जाँचने के लिए safe call operator का उपयोग करने की अनुशंसा की जाती है, क्योंकि गतिविधि बिना आने वाले डीप लिंक के लॉन्च हो सकती है। नेविगेशन में उपयोग करने से पहले host और pathSegment को null के लिए भी जाँचना चाहिए।

प्राथमिकता और विरोध समाधान

यदि कई एप्लिकेशन ने एक ही अंतर्निहित Intent से मेल खाने वाला Intent Filter पंजीकृत किया है, तो सिस्टम उपयोगकर्ता को एक चयन डायलॉग दिखाता है। उपयोगकर्ता एक बार के उपयोग के लिए कोई एप्लिकेशन चुन सकता है या डिफ़ॉल्ट हैंडलर सेट कर सकता है। Android 10 से शुरू होकर, चयन डायलॉग केवल पहली कॉल पर दिखाया जाता है, जिसके बाद सिस्टम उपयोगकर्ता की पसंद को याद रखता है।

प्राथमिकता प्रबंधित करने के लिए, intent-filter टैग में android:priority विशेषता का उपयोग किया जाता है। मान जितना अधिक होगा, विरोधों को हल करते समय कॉम्पोनेंट की उतनी ही अधिक प्राथमिकता होगी। हालांकि, प्राथमिकता विभिन्न एप्लिकेशन के फ़िल्टर के लिए काम नहीं करती — इस मामले में, हमेशा एक चयन डायलॉग दिखाया जाता है यदि कोई एप्लिकेशन डिफ़ॉल्ट के रूप में सेट नहीं है।

एप्लिकेशन चयन डायलॉग

डेवलपर Intent.createChooser() के माध्यम से प्रोग्रामेटिक रूप से चयन डायलॉग को कॉल कर सकता है, लक्ष्य Intent और एक शीर्षक पास करके। यह तब उपयोगी होता है जब एप्लिकेशन उपयोगकर्ता को स्पष्ट रूप से एक हैंडलर चुनने का विकल्प देना चाहता है, भले ही कोई डिफ़ॉल्ट एप्लिकेशन सेट हो। उदाहरण के लिए, ACTION_SEND के माध्यम से सोशल नेटवर्क पर इमेज भेजते समय createChooser के साथ डिफ़ॉल्ट सेटिंग्स की परवाह किए बिना डायलॉग दिखाने की गारंटी देता है।

Intent Filter कॉन्फ़िगर करते समय सामान्य गलतियाँ

सबसे आम गलतियों में से एक Intent Filter में DEFAULT श्रेणी की अनुपस्थिति है। डेवलपर उदाहरणों से कॉन्फ़िगरेशन कॉपी करते हैं लेकिन इस श्रेणी को जोड़ना भूल जाते हैं, जिसके परिणामस्वरूप Activity को अंतर्निहित Intents प्राप्त नहीं होते हैं। सिस्टम अंतर्निहित कॉल के लिए फ़िल्टर नहीं देखता है, हालांकि स्पष्ट Intents काम करते रहते हैं।

दूसरी सामान्य गलती पूर्ण URI के बिना data टैग में scheme का गलत निर्दिष्टीकरण है। यदि केवल स्कीम निर्दिष्ट है लेकिन होस्ट नहीं है, तो फ़िल्टर किसी भी स्रोत से इस स्कीम वाले सभी लिंक स्वीकार करेगा, जो अविश्वसनीय स्रोतों से अवांछित कॉल का कारण बन सकता है। कम से कम scheme और host हमेशा निर्दिष्ट करने की अनुशंसा की जाती है।

तीसरी गलती Activity कोड में intent.data की null जाँच की अनुपस्थिति है। यदि Activity डीप लिंक के माध्यम से नहीं बल्कि लॉन्चर से मानक तरीके से लॉन्च होती है, तो Intent में URI नहीं होता है। बिना जाँच के intent.data तक पहुँचने से NullPointerException होता है और एप्लिकेशन क्रैश हो जाता है। safe call ऑपरेटर के साथ हमेशा intent?.data?.toString() का उपयोग करें।