URL Scheme: apa itu, cara kerja dan penggunaannya dalam pengembangan

Apa itu URL Scheme?

URL Scheme — adalah pengenal protokol unik yang didaftarkan aplikasi di sistem operasi untuk menerima panggilan melalui tautan kustom. Ketika pengguna mengklik tautan seperti myapp://profile/123, sistem mengidentifikasi aplikasi yang mendaftarkan skema myapp dan memberikan kendali dengan URI lengkap. Mekanisme ini memungkinkan aplikasi untuk bertukar data dan membuka satu sama lain tanpa infrastruktur server.

Konsep URL Scheme diambil langsung dari standar web RFC 3986, di mana skema URI adalah komponen pertama dari setiap pengenal sumber daya universal. Dalam pengembangan mobile, ide ini diadaptasi untuk komunikasi antar-aplikasi, di mana aplikasi pemroses tautan sendiri yang bertindak sebagai pengganti server HTTP.

Contoh URL Scheme terkenal

Banyak aplikasi populer mendaftarkan URL Scheme mereka sendiri untuk integrasi dengan layanan pihak ketiga. Misalnya, Spotify menggunakan skema spotify://, Telegram — tg://, dan Instagram — instagram://. Pengembang juga sering membuat skema berbentuk appname:// untuk navigasi internal dan pengujian layar.

URL Scheme masih banyak digunakan dalam notifikasi push, kampanye email dan kode QR, di mana diperlukan transisi segera ke bagian aplikasi tertentu. Namun, mulai dari iOS 9 dan Android 6, muncul mekanisme alternatif yang secara bertahap melengkapi dan menggantikan skema mentah.

Sintaks URL Scheme: skema, host dan jalur

Struktur URI kustom mengikuti spesifikasi umum RFC 3986 dan terdiri dari beberapa komponen. Skema ditentukan pertama dan dipisahkan oleh titik dua dari sisa alamat. Setelah skema dapat mengikuti host, port, jalur, parameter query dan fragmen, yang masing-masing bersifat opsional.

Sintaks lengkap terlihat seperti scheme://host/path?key=value#fragment. Skema adalah satu-satunya elemen wajib, sisanya ditentukan oleh kebutuhan implementasi spesifik. Garis miring ganda setelah skema secara historis berasal dari HTTP dan tidak sepenuhnya wajib menurut spesifikasi, tetapi digunakan secara luas sebagai konvensi.

Komponen URI

Untuk representasi visual struktur URI digunakan tabel komponen. Setiap elemen memiliki tujuan dan tingkat kewajiban sendiri.

Pengembang dapat secara bebas memilih struktur URI, yang memberikan fleksibilitas tetapi menimbulkan masalah kompatibilitas antara versi aplikasi yang berbeda. Disarankan untuk mendokumentasikan format URL Scheme sebagai bagian dari API publik aplikasi dan melakukan versioning saat perubahan.

Cara kerja URL Scheme di iOS

iOS memerlukan pendaftaran eksplisit setiap URL Scheme di file Info.plist proyek. Pengembang menambahkan array CFBundleURLTypes, yang setiap elemennya berisi pengenal (CFBundleURLName) dan daftar skema yang didukung (CFBundleURLSchemes). Setelah pendaftaran, sistem secara otomatis mengarahkan semua panggilan masuk ke skema terdaftar ke aplikasi.

Pemrosesan URL Scheme masuk terjadi di delegat aplikasi melalui metode application(_:open:options:). Metode ini menerima objek URL yang darinya jalur dan parameter query diekstrak untuk mengambil keputusan navigasi. Pemrosesan harus mengembalikan nilai Bool yang menunjukkan keberhasilan operasi.

Pemrosesan di AppDelegate

Di bawah ini adalah contoh implementasi penangan URL Scheme dalam bahasa Swift. Kode menunjukkan ekstraksi host dan parameter query dari URI masuk menggunakan 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
}

Metode ini menggunakan URLComponents untuk parsing parameter query yang aman. Pendekatan ini lebih disukai daripada parsing string manual, karena secara otomatis menangani encoding persentase dan decoding karakter khusus dalam nilai parameter.

Cara kerja URL Scheme di Android

Android menggunakan sistem Intent Filter untuk merutekan deep link berdasarkan URL Scheme. Pengembang mendeklarasikan filter di AndroidManifest.xml di dalam tag Activity yang harus memproses tautan. Filter berisi action VIEW, kategori BROWSABLE dan DEFAULT, serta tag data dengan menentukan skema, host dan pathPrefix.

Ketika pengguna mengklik tautan dengan skema kustom, sistem memeriksa Intent Filter semua aplikasi yang terinstal. Jika ditemukan beberapa aplikasi yang cocok, pengguna akan diberikan dialog pemilihan. Kategori BROWSABLE mengizinkan pemrosesan tautan dari browser.

Konfigurasi Intent Filter

Contoh deklarasi Intent Filter di AndroidManifest.xml untuk memproses skema myapp di Activity. Kombinasi action dan category wajib untuk perutean deep link yang benar.

<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>

Setelah mengonfigurasi filter, di Activity harus dipanggil intent.getData() untuk mendapatkan URI. Penting untuk memeriksa intent dan data terhadap null, karena Activity dapat diluncurkan tanpa deep link masuk, misalnya saat peluncuran standar dari launcher.

Mengirim parameter melalui URL Scheme

Parameter query di URL Scheme dikirim setelah tanda tanya dalam format kunci=nilai, dipisahkan oleh ampersand. Format ini identik dengan permintaan HTTP dan mudah diproses oleh alat standar platform. Parameter harus dienkode menggunakan encoding persentase untuk semua karakter yang tidak termasuk dalam set URI yang diizinkan.

Contoh tautan lengkap dengan parameter: myapp://profile?userId=42&source=email&ref=abc123. Setelah ekstraksi URL, aplikasi secara berurutan mem-parsing semua query-items dan berdasarkan nilainya mengambil keputusan navigasi ke layar target.

Batasan panjang URI

Saat mengirim data kompleks, penting untuk mempertimbangkan batasan panjang URI. Di iOS, panjang maksimum URL Scheme dibatasi hingga 2 KB, setelah itu sistem memotong tautan. Di Android, batasnya sekitar 8 KB, tetapi nilai pastinya tergantung pada versi sistem operasi dan produsen perangkat. Untuk volume data yang besar, disarankan untuk hanya mengirim pengenal sesi melalui URL Scheme, dan memuat data lainnya dari server.

Keterbatasan dan alternatif URL Scheme

Kekurangan utama URL Scheme — ketidakmampuan untuk memproses tautan jika aplikasi tidak terinstal di perangkat. Browser menampilkan kesalahan dan pengguna kehilangan konteks transisi. Untuk mengatasi masalah ini, Apple memperkenalkan Universal Links di iOS 9, dan Google — App Links di Android 6. Kedua mekanisme didaftarkan melalui domain web yang terhubung dengan aplikasi.

Universal Links dan App Links berfungsi seperti tautan HTTPS biasa, tetapi dengan aplikasi yang terinstal, mereka membukanya tanpa dialog pemilihan. Jika aplikasi tidak terinstal, tautan membuka halaman web di domain yang sama, mempertahankan pengalaman pengguna. Ini menjadikannya alternatif yang lebih disukai untuk lingkungan produksi.

Mekanisme fallback

Untuk URL Scheme di iOS dan Android tidak ada mekanisme fallback bawaan. Pengembang menggunakan solusi server perantara: tautan mengarah ke halaman web yang memeriksa instalasi aplikasi melalui JavaScript dan mengarahkan baik ke skema atau ke toko aplikasi. Firebase Dynamic Links dan Branch.io menawarkan solusi siap pakai untuk masalah ini dengan dukungan deferred deep link, yang secara otomatis menentukan status instalasi dan mengarahkan pengguna tanpa perlu mengembangkan pipeline server sendiri.

Kompleksitas tambahan muncul saat menggunakan URL Scheme di iOS 15+ dan Android 12+, di mana aturan privasi diperketat. Safari memblokir upaya membuka skema yang tidak terdaftar tanpa konfirmasi sebelumnya, dan Android 12 membatasi visibilitas aplikasi yang terinstal melalui PackageManager. Perubahan ini membuat penggunaan URL Scheme untuk interaksi antar-aplikasi kurang dapat diandalkan dibandingkan versi sebelumnya dari platform.