URL Scheme: چیست، چگونه کار می‌کند و در توسعه استفاده می‌شود

URL Scheme چیست؟

URL Scheme — یک شناسه پروتکل یکتا است که برنامه در سیستم عامل برای دریافت فراخوانی‌ها از طریق لینک‌های سفارشی ثبت می‌کند. وقتی کاربر روی لینکی مانند myapp://profile/123 کلیک می‌کند، سیستم برنامه‌ای را که طرح myapp را ثبت کرده شناسایی کرده و کنترل را با URI کامل به آن منتقل می‌کند. این مکانیزم به برنامه‌ها اجازه می‌دهد بدون زیرساخت سرور داده تبادل کرده و یکدیگر را باز کنند.

مفهوم URL Scheme مستقیماً از استانداردهای وب RFC 3986 گرفته شده است، جایی که طرح URI اولین مؤلفه هر شناسه منبع جهانی است. در توسعه موبایل، این ایده برای ارتباطات بین برنامه‌ها تطبیق داده شده است، جایی که به جای سرور HTTP، خود برنامه پردازشگر لینک عمل می‌کند.

نمونه‌هایی از URL Schemeهای معروف

بسیاری از برنامه‌های محبوب URL Schemeهای خود را برای یکپارچه‌سازی با سرویس‌های شخص ثالث ثبت می‌کنند. برای مثال، Spotify از طرح spotify://، Telegram از tg:// و Instagram از instagram:// استفاده می‌کند. توسعه‌دهندگان همچنین اغلب طرحی به شکل appname:// برای ناوبری داخلی و تست صفحه‌ها ایجاد می‌کنند.

URL Schemeها هنوز هم به طور گسترده در اعلان‌های فشاری، کمپین‌های ایمیلی و کدهای QR استفاده می‌شوند، جایی که انتقال فوری به بخش خاصی از برنامه مورد نیاز است. با این حال، از iOS 9 و Android 6 به بعد، مکانیزم‌های جایگزینی ظاهر شده‌اند که به تدریج طرح‌های خام را تکمیل و جایگزین می‌کنند.

نحو URL Scheme: طرح، میزبان و مسیر

ساختار URI سفارشی تابع مشخصات کلی RFC 3986 است و از چندین مؤلفه تشکیل شده است. طرح ابتدا مشخص می‌شود و با دونقطه از بقیه آدرس جدا می‌گردد. پس از طرح می‌توانند میزبان، پورت، مسیر، پارامترهای query و بخش (fragment) قرار گیرند که هرکدام اختیاری هستند.

نحو کامل به صورت scheme://host/path?key=value#fragment است. طرح تنها عنصر اجباری است و بقیه بر اساس نیازهای پیاده‌سازی خاص تعیین می‌شوند. اسلش دوتایی بعد از طرح از نظر تاریخی از HTTP گرفته شده و طبق مشخصات به شدت اجباری نیست، اما به عنوان یک قرارداد رایج استفاده می‌شود.

مؤلفه‌های URI

برای نمایش بصری ساختار URI از جدول مؤلفه‌ها استفاده می‌شود. هر عنصر هدف و سطح الزام خاص خود را دارد.

توسعه‌دهندگان می‌توانند آزادانه ساختار URI را انتخاب کنند که انعطاف‌پذیری ایجاد می‌کند اما مشکلات سازگاری بین نسخه‌های مختلف برنامه به وجود می‌آورد. توصیه می‌شود فرمت URL Scheme به عنوان بخشی از API عمومی برنامه مستند شده و در هنگام تغییر نسخه‌بندی شود.

URL Scheme در iOS چگونه کار می‌کند

iOS نیاز به ثبت صریح هر URL Scheme در فایل Info.plist پروژه دارد. توسعه‌دهنده آرایه CFBundleURLTypes را اضافه می‌کند که هر عنصر آن شامل یک شناسه (CFBundleURLName) و لیست طرح‌های پشتیبانی‌شده (CFBundleURLSchemes) است. پس از ثبت، سیستم به طور خودکار تمام فراخوانی‌های ورودی به طرح‌های ثبت‌شده را به برنامه هدایت می‌کند.

پردازش URL Scheme ورودی در نماینده برنامه از طریق متد application(_:open:options:) انجام می‌شود. این متد یک شی URL دریافت می‌کند که مسیر و پارامترهای query برای تصمیم‌گیری در مورد ناوبری از آن استخراج می‌شود. پردازش باید یک مقدار Bool برگرداند که موفقیت عملیات را نشان می‌دهد.

پردازش در AppDelegate

در زیر نمونه‌ای از پیاده‌سازی پردازشگر URL Scheme به زبان Swift آورده شده است. کد استخراج میزبان و پارامترهای query از URI ورودی را با استفاده از URLComponents نشان می‌دهد.

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 برای تجزیه امن پارامترهای query استفاده می‌کند. این رویکرد نسبت به تجزیه دستی رشته ترجیح داده می‌شود، زیرا به طور خودکار کدگذاری درصدی و رمزگشایی کاراکترهای خاص در مقادیر پارامترها را مدیریت می‌کند.

URL Scheme در Android چگونه کار می‌کند

Android از سیستم Intent Filter برای مسیریابی deep link بر اساس URL Scheme استفاده می‌کند. توسعه‌دهنده فیلتر را در AndroidManifest.xml داخل تگ Activity که باید لینک را پردازش کند اعلام می‌کند. فیلتر شامل action VIEW، دسته‌های BROWSABLE و DEFAULT و همچنین تگ data با تعیین طرح، میزبان و pathPrefix است.

وقتی کاربر روی لینکی با طرح سفارشی کلیک می‌کند، سیستم Intent Filter همه برنامه‌های نصب‌شده را بررسی می‌کند. اگر چند برنامه مناسب یافت شود، یک گفتگوی انتخاب به کاربر نشان داده می‌شود. دسته BROWSABLE امکان پردازش لینک از مرورگر را فراهم می‌کند.

تنظیم Intent Filter

نمونه اعلام Intent Filter در AndroidManifest.xml برای پردازش طرح myapp در Activity. ترکیب action و category برای مسیریابی صحیح deep link الزامی است.

<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 باید intent.getData() برای دریافت URI فراخوانی شود. بررسی intent و داده‌ها از نظر null مهم است، زیرا Activity ممکن است بدون deep link ورودی، مثلاً هنگام راه‌اندازی استاندارد از لانچر، شروع شود.

انتقال پارامترها از طریق URL Scheme

پارامترهای query در URL Scheme بعد از علامت سؤال در قالب کلید=مقدار و با جداکننده ampersand منتقل می‌شوند. این فرمت با درخواست‌های HTTP یکسان است و به راحتی توسط ابزارهای استاندارد پلتفرم پردازش می‌شود. پارامترها باید با استفاده از کدگذاری درصدی برای همه کاراکترهایی که در مجموعه مجاز URI نیستند کدگذاری شوند.

مثال یک لینک کامل با پارامترها: myapp://profile?userId=42&source=email&ref=abc123. پس از استخراج URL، برنامه به ترتیب همه query-items را تجزیه کرده و بر اساس مقادیر آنها در مورد ناوبری به صفحه هدف تصمیم می‌گیرد.

محدودیت طول URI

هنگام انتقال داده‌های ترکیبی، مهم است که محدودیت طول URI را در نظر بگیرید. در iOS، حداکثر طول URL Scheme به 2 KB محدود شده است و پس از آن سیستم لینک را قطع می‌کند. در Android، حد حدود 8 KB است اما مقدار دقیق به نسخه سیستم عامل و تولیدکننده دستگاه بستگی دارد. برای حجم زیاد داده، توصیه می‌شود فقط شناسه جلسه را از طریق URL Scheme منتقل کرده و بقیه داده‌ها را از سرور بارگذاری کنید.

محدودیت‌ها و جایگزین‌های URL Scheme

عیب اصلی URL Scheme — عدم امکان پردازش لینک در صورت نصب نبودن برنامه روی دستگاه است. مرورگر خطا نشان می‌دهد و کاربر بافت انتقال را از دست می‌دهد. برای حل این مشکل، اپل Universal Links را در iOS 9 و گوگل App Links را در Android 6 معرفی کرد. هر دو مکانیزم از طریق دامنه وب متصل به برنامه ثبت می‌شوند.

Universal Links و App Links مانند لینک‌های معمولی HTTPS کار می‌کنند، اما در صورت نصب بودن برنامه، آن را بدون گفتگوی انتخاب باز می‌کنند. اگر برنامه نصب نباشد، لینک یک صفحه وب در همان دامنه را باز می‌کند و تجربه کاربری را حفظ می‌کند. این آنها را به جایگزین ترجیحی برای محیط تولید تبدیل می‌کند.

مکانیزم‌های fallback

برای URL Scheme در iOS و Android مکانیزم fallback داخلی وجود ندارد. توسعه‌دهندگان از راه‌حل‌های میانی سرور استفاده می‌کنند: لینک به صفحه وبی منتهی می‌شود که نصب برنامه را از طریق JavaScript بررسی کرده و یا به طرح یا به فروشگاه برنامه هدایت می‌کند. Firebase Dynamic Links و Branch.io راه‌حل‌های آماده این مشکل را با پشتیبانی از deferred deep link ارائه می‌دهند که به طور خودکار وضعیت نصب را تعیین کرده و کاربر را بدون نیاز به توسعه خط لوله سرور شخصی هدایت می‌کنند.

پیچیدگی اضافی هنگام استفاده از URL Scheme در iOS 15+ و Android 12+ ایجاد می‌شود، جایی که قوانین حریم خصوصی سخت‌گیرانه‌تر شده است. Safari تلاش برای باز کردن طرح ثبت‌نشده بدون تأیید قبلی را مسدود می‌کند و Android 12 دید برنامه‌های نصب‌شده را از طریق PackageManager محدود می‌کند. این تغییرات استفاده از URL Scheme برای تعامل بین برنامه‌ها را نسبت به نسخه‌های قبلی پلتفرم‌ها کمتر قابل اعتماد می‌کند.