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

URL Scheme क्या है?

URL Scheme — एक अद्वितीय प्रोटोकॉल पहचानकर्ता है जिसे कोई ऐप कस्टम लिंक के माध्यम से कॉल प्राप्त करने के लिए ऑपरेटिंग सिस्टम में रजिस्टर करता है। जब कोई उपयोगकर्ता myapp://profile/123 जैसे लिंक पर क्लिक करता है, तो सिस्टम myapp स्कीम को रजिस्टर करने वाले ऐप की पहचान करता है और पूर्ण URI के साथ उसे नियंत्रण सौंपता है। यह तंत्र ऐप्स को सर्वर बुनियादी ढांचे की आवश्यकता के बिना डेटा का आदान-प्रदान करने और एक-दूसरे को खोलने की अनुमति देता है।

URL Scheme की अवधारणा सीधे वेब मानकों RFC 3986 से ली गई है, जहां URI स्कीम किसी भी सार्वभौमिक संसाधन पहचानकर्ता का पहला घटक है। मोबाइल डेवलपमेंट में, इस विचार को इंटर-ऐप संचार के लिए अनुकूलित किया गया है, जहां HTTP सर्वर के बजाय ऐप स्वयं लिंक हैंडलर के रूप में कार्य करता है।

प्रसिद्ध URL Schemes के उदाहरण

कई लोकप्रिय ऐप्स तृतीय-पक्ष सेवाओं के साथ एकीकरण के लिए अपने स्वयं के URL Schemes रजिस्टर करते हैं। उदाहरण के लिए, Spotify स्कीम spotify:// का उपयोग करता है, Telegram tg:// का, और Instagram instagram:// का। डेवलपर्स अक्सर आंतरिक नेविगेशन और एंड-टू-एंड स्क्रीन परीक्षण के लिए appname:// स्कीम भी बनाते हैं।

URL Schemes अभी भी पुश सूचनाओं, ईमेल न्यूज़लेटर्स और QR कोड में व्यापक रूप से उपयोग किए जाते हैं जहां ऐप के किसी विशिष्ट अनुभाग में तत्काल नेविगेशन की आवश्यकता होती है। हालांकि, iOS 9 और Android 6 से शुरू होकर, वैकल्पिक तंत्र उभरे हैं जो धीरे-धीरे सादी स्कीमों को पूरक और प्रतिस्थापित कर रहे हैं।

URL Scheme सिंटैक्स: स्कीम, होस्ट और पथ

कस्टम URI की संरचना सामान्य RFC 3986 विनिर्देश का पालन करती है और कई घटकों से बनी होती है। स्कीम पहले निर्दिष्ट की जाती है और पते के बाकी हिस्से से कोलन द्वारा अलग की जाती है। स्कीम के बाद होस्ट, पोर्ट, पथ, क्वेरी पैरामीटर और फ़्रैगमेंट आ सकते हैं, जिनमें से प्रत्येक वैकल्पिक है।

पूर्ण सिंटैक्स scheme://host/path?key=value#fragment जैसा दिखता है। स्कीम एकमात्र अनिवार्य तत्व है; शेष विशिष्ट कार्यान्वयन की आवश्यकताओं द्वारा निर्धारित किए जाते हैं। स्कीम के बाद डबल स्लैश ऐतिहासिक रूप से HTTP से लिया गया है और विनिर्देश के अनुसार सख्ती से अनिवार्य नहीं है, लेकिन सार्वभौमिक रूप से एक सम्मेलन के रूप में उपयोग किया जाता है।

URI घटक

URI संरचना के दृश्य प्रतिनिधित्व के लिए घटक तालिका का उपयोग किया जाता है। प्रत्येक तत्व का अपना उद्देश्य और अनिवार्यता का स्तर होता है।

डेवलपर्स मनमाने ढंग से URI संरचना चुन सकते हैं, जो लचीलापन पैदा करता है लेकिन ऐप के विभिन्न संस्करणों के बीच संगतता समस्याएं उत्पन्न करता है। URL Scheme प्रारूप को ऐप के सार्वजनिक API के हिस्से के रूप में दस्तावेजित करने और परिवर्तन होने पर इसे संस्करणित करने की अनुशंसा की जाती है।

iOS में URL Scheme कैसे काम करता है

iOS को प्रोजेक्ट की Info.plist फ़ाइल में प्रत्येक URL Scheme के स्पष्ट पंजीकरण की आवश्यकता होती है। डेवलपर एक CFBundleURLTypes ऐरे जोड़ता है, जिसका प्रत्येक तत्व एक पहचानकर्ता (CFBundleURLName) और समर्थित स्कीमों (CFBundleURLSchemes) की सूची रखता है। पंजीकरण के बाद, सिस्टम स्वचालित रूप से पंजीकृत स्कीमों पर सभी आने वाले कॉल को ऐप पर निर्देशित करता है।

आने वाले URL Scheme की हैंडलिंग ऐप डेलिगेट में application(_:open:options:) विधि के माध्यम से होती है। यह विधि एक URL ऑब्जेक्ट प्राप्त करती है जिससे नेविगेशन निर्णय लेने के लिए पथ और क्वेरी पैरामीटर निकाले जाते हैं। हैंडलर को ऑपरेशन की सफलता को इंगित करने वाला Bool मान लौटाना चाहिए।

AppDelegate में हैंडलिंग

नीचे Swift में URL Scheme हैंडलर के कार्यान्वयन का एक उदाहरण दिया गया है। कोड URLComponents का उपयोग करके आने वाले URI से होस्ट और क्वेरी पैरामीटर निकालने का प्रदर्शन करता है।

func application(
    _ app: UIApplication,
    open url: URL,
    options: [UIApplication.OpenURLOptionsKey: Any]
) -> Bool {
    let host = url.host
    let params = URLComponents(
        url: url,
        resolvingAgainstBaseURL: false
    )?.queryItems
    if host == "profile" {
        navigateToProfile(params)
    }
    return true
}

विधि क्वेरी पैरामीटर के सुरक्षित पार्सिंग के लिए URLComponents का उपयोग करती है। यह दृष्टिकोण मैन्युअल स्ट्रिंग पार्सिंग से बेहतर है क्योंकि यह स्वचालित रूप से पैरामीटर मानों में प्रतिशत एन्कोडिंग और विशेष वर्णों के डिकोडिंग को संभालता है।

Android में URL Scheme कैसे काम करता है

Android URL Scheme के आधार पर डीप लिंक को रूट करने के लिए Intent Filter सिस्टम का उपयोग करता है। डेवलपर AndroidManifest.xml में Activity टैग के अंदर एक फ़िल्टर घोषित करता है जिसे लिंक को संभालना चाहिए। फ़िल्टर में VIEW क्रिया, BROWSABLE और DEFAULT श्रेणियां, और स्कीम, होस्ट और pathPrefix निर्दिष्ट करने वाला data टैग होता है।

जब कोई उपयोगकर्ता कस्टम स्कीम वाले लिंक पर क्लिक करता है, तो सिस्टम सभी इंस्टॉल किए गए ऐप्स के Intent Filter की जांच करता है। यदि कई मेल खाने वाले ऐप्स मिलते हैं, तो उपयोगकर्ता को एक चयन संवाद प्रस्तुत किया जाता है। BROWSABLE श्रेणी ब्राउज़र से लिंक प्रोसेस करने की अनुमति देती है।

Intent Filter कॉन्फ़िगर करना

Activity पर myapp स्कीम को संभालने के लिए AndroidManifest.xml में Intent Filter घोषित करने का उदाहरण। सही डीप लिंक रूटिंग के लिए action और category का संयोजन अनिवार्य है।

<activity android:name=".MainActivity">
    <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"
            android:pathPrefix="/user" />
    </intent-filter>
</activity>

Activity में फ़िल्टर कॉन्फ़िगर करने के बाद, URI प्राप्त करने के लिए intent.getData() कॉल करना आवश्यक है। intent और डेटा को null के लिए जांचना महत्वपूर्ण है, क्योंकि Activity बिना आने वाले डीप लिंक के लॉन्च हो सकती है, उदाहरण के लिए लॉन्चर से मानक स्टार्टअप के दौरान।

URL Scheme के माध्यम से पैरामीटर पास करना

URL Scheme में क्वेरी पैरामीटर प्रश्न चिह्न के बाद कुंजी=मान प्रारूप में, एम्परसेंड द्वारा अलग करके पास किए जाते हैं। यह प्रारूप HTTP अनुरोधों के समान है और प्लेटफ़ॉर्म के मानक टूल द्वारा आसानी से संसाधित किया जाता है। अनुमत URI वर्ण सेट में शामिल नहीं होने वाले सभी वर्णों के लिए प्रतिशत एन्कोडिंग का उपयोग करके पैरामीटर एन्कोड किए जाने चाहिए।

पैरामीटर के साथ पूर्ण लिंक का उदाहरण: myapp://profile?userId=42&source=email&ref=abc123। URL निकालने के बाद, ऐप क्रमिक रूप से सभी क्वेरी-आइटम को पार्स करता है और उनके मानों के आधार पर लक्ष्य स्क्रीन पर नेविगेशन का निर्णय लेता है।

URI लंबाई सीमा

जटिल डेटा पास करते समय, URI लंबाई सीमा पर विचार करना महत्वपूर्ण है। iOS में, अधिकतम URL Scheme लंबाई 2 KB तक सीमित है, जिसके बाद सिस्टम लिंक को काट देता है। Android में, सीमा लगभग 8 KB है, लेकिन सटीक मान OS संस्करण और डिवाइस निर्माता पर निर्भर करता है। बड़ी मात्रा में डेटा के लिए, URL Scheme के माध्यम से केवल एक सत्र पहचानकर्ता पास करने और बाकी डेटा सर्वर से लोड करने की अनुशंसा की जाती है।

URL Scheme की सीमाएं और विकल्प

URL Scheme का मुख्य दोष यह है कि यदि ऐप डिवाइस पर इंस्टॉल नहीं है तो लिंक को संभालने में असमर्थता है। ब्राउज़र एक त्रुटि प्रदर्शित करता है और उपयोगकर्ता नेविगेशन संदर्भ खो देता है। इस समस्या को हल करने के लिए, Apple ने iOS 9 में Universal Links और Google ने Android 6 में App Links पेश किए। दोनों तंत्र ऐप से जुड़े वेब डोमेन के माध्यम से पंजीकृत होते हैं।

Universal Links और App Links सामान्य HTTPS लिंक की तरह काम करते हैं, लेकिन जब ऐप इंस्टॉल होता है, तो वे बिना चयन संवाद के इसे खोलते हैं। यदि ऐप इंस्टॉल नहीं है, तो लिंक उसी डोमेन पर एक वेब पेज खोलता है, जो उपयोगकर्ता अनुभव को संरक्षित करता है। यह उन्हें उत्पादन वातावरण के लिए पसंदीदा विकल्प बनाता है।

फ़ॉलबैक तंत्र

iOS और Android पर URL Scheme के लिए कोई अंतर्निहित फ़ॉलबैक तंत्र नहीं है। डेवलपर्स मध्यवर्ती सर्वर समाधान का उपयोग करते हैं: लिंक एक वेब पेज पर जाता है जो JavaScript के माध्यम से ऐप इंस्टॉलेशन की जांच करता है और या तो स्कीम पर या ऐप स्टोर पर रीडायरेक्ट करता है। Firebase Dynamic Links और Branch.io इस समस्या के लिए तैयार समाधान प्रदान करते हैं जिसमें विलंबित डीप लिंक का समर्थन शामिल है जो स्वचालित रूप से इंस्टॉलेशन स्थिति निर्धारित करते हैं और कस्टम सर्वर पाइपलाइन विकसित करने की आवश्यकता के बिना उपयोगकर्ता को रूट करते हैं।

iOS 15+ और Android 12+ में URL Scheme का उपयोग करते समय अतिरिक्त जटिलता उत्पन्न होती है, जहां गोपनीयता नियमों को कड़ा किया गया है। Safari पूर्व पुष्टि के बिना एक अपंजीकृत स्कीम खोलने के प्रयासों को ब्लॉक करता है, और Android 12 PackageManager के माध्यम से इंस्टॉल किए गए ऐप्स की दृश्यता को प्रतिबंधित करता है। ये परिवर्तन इंटर-ऐप संचार के लिए URL Scheme के उपयोग को प्लेटफ़ॉर्म के पहले के संस्करणों की तुलना में कम विश्वसनीय बनाते हैं।