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 کے استعمال کو پلیٹ فارم کے پہلے والے ورژنز کے مقابلے میں کم قابل بھروسہ بناتی ہیں۔