URL Scheme: ano ito, paano gumagana at ginagamit sa pag-develop

Ano ang URL Scheme?

URL Scheme — ay isang natatanging identifier ng protocol na inirerehistro ng application sa operating system para makatanggap ng mga tawag sa pamamagitan ng custom na mga link. Kapag nag-click ang user sa isang link tulad ng myapp://profile/123, tinutukoy ng system ang application na nagrehistro ng scheme na myapp at inililipat dito ang kontrol na may kumpletong URI. Ang mekanismong ito ay nagpapahintulot sa mga application na magpalitan ng data at magbukas ng isa't isa nang walang server infrastructure.

Ang konsepto ng URL Scheme ay direktang kinuha mula sa mga web standard ng RFC 3986, kung saan ang URI scheme ay ang unang bahagi ng bawat universal resource identifier. Sa mobile development, ang ideyang ito ay inangkop para sa inter-application communication, kung saan sa halip na HTTP server ay ang application mismo na nagpoproseso ng link ang gumaganap.

Mga halimbawa ng kilalang URL Scheme

Maraming sikat na application ang nagrerehistro ng kanilang sariling URL Scheme para sa pagsasama sa mga third-party na serbisyo. Halimbawa, ginagamit ng Spotify ang scheme na spotify://, Telegram — tg://, at Instagram — instagram://. Madalas ding gumagawa ang mga developer ng scheme na may anyong appname:// para sa internal navigation at pagsubok ng mga screen.

Ang URL Scheme ay malawakang ginagamit pa rin sa push notification, mga email campaign at QR code, kung saan kinakailangan ang agarang paglipat sa isang partikular na seksyon ng application. Gayunpaman, simula sa iOS 9 at Android 6, lumitaw ang mga alternatibong mekanismo na unti-unting nagpupuno at pumapalit sa mga simpleng scheme.

Syntax ng URL Scheme: scheme, host at path

Ang istraktura ng custom na URI ay sumusunod sa pangkalahatang detalye ng RFC 3986 at binubuo ng ilang bahagi. Ang scheme ay tinutukoy muna at pinaghihiwalay ng tutuldok mula sa natitirang bahagi ng address. Pagkatapos ng scheme ay maaaring sumunod ang host, port, path, query-parameters at fragment, na ang bawat isa ay opsyonal.

Ang kumpletong syntax ay mukhang scheme://host/path?key=value#fragment. Ang scheme ay ang tanging mandatoryong elemento, ang iba ay tinutukoy ng mga pangangailangan ng partikular na implementasyon. Ang dobleng slash pagkatapos ng scheme ay nagmula sa kasaysayan mula sa HTTP at hindi mahigpit na mandatory ayon sa detalye, ngunit ginagamit sa lahat ng dako bilang kombensyon.

Mga bahagi ng URI

Para sa visual na representasyon ng istraktura ng URI ay ginagamit ang isang talahanayan ng mga bahagi. Ang bawat elemento ay may sariling layunin at antas ng obligasyon.

Malayang mapipili ng mga developer ang istraktura ng URI, na nagbibigay ng flexibility ngunit nagdudulot ng mga problema sa compatibility sa pagitan ng iba't ibang bersyon ng application. Inirerekomenda na idokumento ang format ng URL Scheme bilang bahagi ng pampublikong API ng application at i-version ito kapag nagbago.

Paano gumagana ang URL Scheme sa iOS

Ang iOS ay nangangailangan ng malinaw na pagrerehistro ng bawat URL Scheme sa Info.plist file ng proyekto. Ang developer ay nagdaragdag ng array na CFBundleURLTypes, na ang bawat elemento ay naglalaman ng identifier (CFBundleURLName) at listahan ng mga suportadong scheme (CFBundleURLSchemes). Pagkatapos ng pagrerehistro, awtomatikong idinidirekta ng system ang lahat ng papasok na tawag sa mga naka-rehistrong scheme patungo sa application.

Ang pagproseso ng papasok na URL Scheme ay nangyayari sa delegate ng application sa pamamagitan ng method na application(_:open:options:). Ang method na ito ay tumatanggap ng URL object kung saan kinukuha ang path at query-parameters para gumawa ng desisyon sa navigation. Ang pagproseso ay dapat magbalik ng Bool value na nagpapahiwatig ng tagumpay ng operasyon.

Pagproseso sa AppDelegate

Sa ibaba ay isang halimbawa ng implementasyon ng URL Scheme handler sa wikang Swift. Ipinapakita ng code ang pagkuha ng host at query-parameters mula sa papasok na URI gamit ang 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
}

Gumagamit ang method ng URLComponents para sa ligtas na pag-parse ng query-parameters. Ang approach na ito ay mas mainam kaysa sa manual na pag-parse ng string, dahil awtomatiko nitong pinangangasiwaan ang percent encoding at decoding ng mga espesyal na character sa mga halaga ng parameter.

Paano gumagana ang URL Scheme sa Android

Ang Android ay gumagamit ng Intent Filter system para sa pagruta ng deep link batay sa URL Scheme. Idineklara ng developer ang filter sa AndroidManifest.xml sa loob ng tag ng Activity na dapat magproseso ng link. Ang filter ay naglalaman ng action VIEW, mga kategoryang BROWSABLE at DEFAULT, pati na rin ang tag data na may pagtukoy ng scheme, host at pathPrefix.

Kapag nag-click ang user sa isang link na may custom na scheme, sinusuri ng system ang Intent Filter ng lahat ng naka-install na application. Kung maraming angkop na application ang natagpuan, ipapakita sa user ang isang dialog ng pagpili. Ang kategoryang BROWSABLE ay nagpapahintulot sa pagproseso ng link mula sa browser.

Pag-configure ng Intent Filter

Halimbawa ng deklarasyon ng Intent Filter sa AndroidManifest.xml para sa pagproseso ng scheme na myapp sa isang Activity. Ang kombinasyon ng action at category ay mandatory para sa tamang pagruta ng 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>

Pagkatapos i-configure ang filter, sa Activity ay dapat tawagin ang intent.getData() para makuha ang URI. Mahalagang suriin ang intent at data para sa null, dahil ang Activity ay maaaring ilunsad nang walang papasok na deep link, halimbawa sa karaniwang paglulunsad mula sa launcher.

Pagpapadala ng parameter sa pamamagitan ng URL Scheme

Ang query-parameters sa URL Scheme ay ipinapadala pagkatapos ng tandang pananong sa format na key=value, na pinaghihiwalay ng ampersand. Ang format na ito ay kapareho ng HTTP requests at madaling napoproseso ng mga karaniwang tool ng platform. Ang mga parameter ay dapat i-encode gamit ang percent encoding para sa lahat ng character na hindi kabilang sa pinapayagang set ng URI.

Halimbawa ng kumpletong link na may mga parameter: myapp://profile?userId=42&source=email&ref=abc123. Pagkatapos ng pagkuha ng URL, sunod-sunod na ini-parse ng application ang lahat ng query-items at batay sa kanilang mga halaga ay gumagawa ng desisyon sa navigation patungo sa target na screen.

Limitasyon sa haba ng URI

Sa pagpapadala ng kumplikadong data, mahalagang isaalang-alang ang limitasyon sa haba ng URI. Sa iOS, ang maximum na haba ng URL Scheme ay limitado sa 2 KB, pagkatapos nito ay pinuputol ng system ang link. Sa Android, ang limitasyon ay humigit-kumulang 8 KB, ngunit ang eksaktong halaga ay depende sa bersyon ng operating system at manufacturer ng device. Para sa malalaking volume ng data, inirerekomenda na ipadala lamang ang session identifier sa pamamagitan ng URL Scheme, at i-load ang iba pang data mula sa server.

Mga limitasyon at alternatibo ng URL Scheme

Ang pangunahing disbentaha ng URL Scheme — ang kawalan ng kakayahang iproseso ang link kung hindi naka-install ang application sa device. Ang browser ay nagpapakita ng error at nawawala ang konteksto ng paglipat ng user. Upang malutas ang problemang ito, ipinakilala ng Apple ang Universal Links sa iOS 9, at Google — App Links sa Android 6. Ang parehong mekanismo ay nirerehistro sa pamamagitan ng web domain na naka-link sa application.

Ang Universal Links at App Links ay gumagana tulad ng mga ordinaryong HTTPS link, ngunit kapag mayroong naka-install na application, binubuksan nila ito nang walang dialog ng pagpili. Kung hindi naka-install ang application, binubuksan ng link ang isang web page sa parehong domain, na pinapanatili ang karanasan ng user. Ginagawa nitong mas mainam na alternatibo para sa production environment.

Mga mekanismo ng fallback

Para sa URL Scheme sa iOS at Android ay walang built-in na mekanismo ng fallback. Ang mga developer ay gumagamit ng intermediate server solutions: ang link ay humahantong sa isang web page na sumusuri sa pag-install ng application sa pamamagitan ng JavaScript at nagre-redirect alinman sa scheme o sa app store. Ang Firebase Dynamic Links at Branch.io ay nag-aalok ng mga handa na solusyon para sa problemang ito na may suporta para sa deferred deep link, na awtomatikong tinutukoy ang status ng pag-install at nagre-redirect sa user nang hindi kinakailangang bumuo ng sariling server pipeline.

Ang karagdagang komplikasyon ay lumilitaw kapag gumagamit ng URL Scheme sa iOS 15+ at Android 12+, kung saan pinahigpit ang mga patakaran sa privacy. Hinaharangan ng Safari ang mga pagtatangka na buksan ang isang hindi naka-rehistrong scheme nang walang paunang kumpirmasyon, at nililimitahan ng Android 12 ang visibility ng mga naka-install na application sa pamamagitan ng PackageManager. Ang mga pagbabagong ito ay ginagawang hindi gaanong maaasahan ang paggamit ng URL Scheme para sa inter-application interaction kumpara sa mga naunang bersyon ng mga platform.