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-এর ব্যবহার কম নির্ভরযোগ্য করে তোলে।