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 العام للتطبيق وإصداره عند إجراء تغييرات.

كيف يعمل URL Scheme في iOS

يتطلب iOS تسجيلًا صريحًا لكل URL Scheme في ملف Info.plist للمشروع. يُضيف المطور مصفوفة CFBundleURLTypes، يحتوي كل عنصر منها على معرف (CFBundleURLName) وقائمة بالمخططات المدعومة (CFBundleURLSchemes). بعد التسجيل، يُوجّه النظام تلقائيًا جميع الاستدعاءات الواردة على المخططات المُسجّلة إلى التطبيق.

تتم معالجة URL Scheme الوارد في مفوّض التطبيق عبر الطريقة application(_:open:options:). تستقبل هذه الطريقة كائن URL يُستخرج منه المسار ومعاملات الاستعلام لاتخاذ قرارات التنقل. يجب أن يُعيد المعالج قيمة Bool تشير إلى نجاح العملية.

المعالجة في AppDelegate

فيما يلي مثال على تنفيذ معالج URL Scheme بلغة Swift. يُظهر الكود استخراج المضيف ومعاملات الاستعلام من 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 للتحليل الآمن لمعاملات الاستعلام. هذا النهج أفضل من التحليل اليدوي للسلسلة لأنه يتعامل تلقائيًا مع ترميز النسبة المئوية وفك تشفير الأحرف الخاصة في قيم المعاملات.

كيف يعمل URL Scheme في Android

يستخدم Android نظام Intent Filter لتوجيه الروابط العميقة بناءً على URL Scheme. يُعلن المطور عن عامل تصفية في AndroidManifest.xml داخل علامة Activity التي يجب أن تعالج الرابط. يحتوي الفلتر على action VIEW والفئتين BROWSABLE و DEFAULT، وعلامة data تُحدد المخطط والمضيف و pathPrefix.

عندما ينقر المستخدم على رابط بمخطط مخصص، يتحقق النظام من Intent Filter لجميع التطبيقات المثبتة. إذا تم العثور على عدة تطبيقات متطابقة، يُعرض على المستخدم مربع حوار الاختيار. تسمح الفئة BROWSABLE بمعالجة الرابط من المتصفح.

إعداد Intent Filter

مثال على إعلان Intent Filter في AndroidManifest.xml لمعالجة المخطط myapp على Activity. الجمع بين 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، يجب استدعاء intent.getData() للحصول على URI. من المهم التحقق من intent والبيانات بقيمة null، حيث قد يتم تشغيل Activity بدون رابط عميق وارد، على سبيل المثال أثناء التشغيل القياسي من المشغل.

تمرير المعاملات عبر URL Scheme

تُمرّر معاملات الاستعلام في URL Scheme بعد علامة الاستفهام بتنسيق مفتاح=قيمة، مفصولة بعلامة العطف. هذا التنسيق مماثل لطلبات HTTP ويُعالج بسهولة بواسطة أدوات النظام الأساسية القياسية. يجب ترميز المعاملات باستخدام ترميز النسبة المئوية لجميع الأحرف غير المدرجة في مجموعة URI المسموح بها.

مثال على رابط كامل مع معاملات: myapp://profile?userId=42&source=email&ref=abc123. بعد استخراج URL، يُحلّل التطبيق تسلسليًا جميع query-items وبناءً على قيمها يتخذ قرار التنقل إلى الشاشة المستهدفة.

حد طول URI

عند تمرير بيانات معقدة، من المهم مراعاة حد طول URI. في iOS، الحد الأقصى لطول URL Scheme هو 2 كيلوبايت، وبعد ذلك يقطع النظام الرابط. في Android، يبلغ الحد حوالي 8 كيلوبايت، لكن القيمة الدقيقة تعتمد على إصدار نظام التشغيل والشركة المصنعة للجهاز. لكميات كبيرة من البيانات، يُوصى بتمرير معرف جلسة فقط عبر URL Scheme وتحميل باقي البيانات من الخادم.

قيود وبدائل URL Scheme

العيب الرئيسي لـ URL Scheme هو عدم القدرة على معالجة الرابط إذا لم يكن التطبيق مثبتًا على الجهاز. يعرض المتصفح خطأً ويفقد المستخدم سياق التنقل. لحل هذه المشكلة، قدمت Apple Universal Links في iOS 9 وقدمت Google App Links في Android 6. يتم تسجيل كلتا الآليتين عبر نطاق ويب مرتبط بالتطبيق.

تعمل Universal Links وApp Links كروابط HTTPS عادية، ولكن عند تثبيت التطبيق، تفتحه دون حوار اختيار. إذا لم يكن التطبيق مثبتًا، يفتح الرابط صفحة ويب على نفس النطاق، مما يحافظ على تجربة المستخدم. وهذا يجعلهما البديل المفضل لبيئات الإنتاج.

آليات الاحتياط

لا توجد آلية احتياط مدمجة لـ URL Scheme في iOS وAndroid. يستخدم المطورون حلول خادم وسيطة: الرابط يؤدي إلى صفحة ويب تتحقق من تثبيت التطبيق عبر JavaScript وتُوجّه إما إلى المخطط أو إلى متجر التطبيقات. تقدم Firebase Dynamic Links وBranch.io حلولًا جاهزة لهذه المشكلة مع دعم الروابط العميقة المؤجلة التي تُحدد تلقائيًا حالة التثبيت وتُوجّه المستخدم دون الحاجة إلى تطوير خط أنابيب خادم مخصص.

يظهر تعقيد إضافي عند استخدام URL Scheme في iOS 15+ وAndroid 12+، حيث تم تشديد قواعد الخصوصية. يحظر Safari محاولات فتح مخطط غير مُسجّل دون تأكيد مسبق، ويُقيّد Android 12 رؤية التطبيقات المثبتة عبر PackageManager. هذه التغييرات تجعل استخدام URL Scheme للتواصل بين التطبيقات أقل موثوقية مما كان عليه في الإصدارات السابقة من المنصات.