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 се и даље широко користе у push обавештењима, имејл кампањама и QR кодовима, где је потребан тренутни прелазак у одређени део апликације. Међутим, почевши од iOS 9 и Android 6, појавили су се алтернативни механизми који постепено допуњују и замењују голе шеме.

Синтакса URL Scheme: шема, хост и путања

Структура прилагођеног URI-ја подлеже општој спецификацији RFC 3986 и састоји се од неколико компоненти. Шема се наводи прва и одваја се двотачком од остатка адресе. Након шеме могу следити хост, порт, путања, query параметри и фрагмент, од којих је сваки опционалан.

Потпуна синтакса изгледа као 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 се преносе након знака питања у формату кључ=вредност, раздвојени амперсандом. Овај формат је идентичан 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 — немогућност обраде линка ако апликација није инсталирана на уређају. Прегледач приказује грешку и корисник губи контекст преласка. За решавање овог проблема, Apple је увео Universal Links у iOS 9, а Google — App Links у Android 6. Оба механизма се региструју путем веб домена повезаног са апликацијом.

Universal Links и App Links раде као обични HTTPS линкови, али када је апликација присутна, отварају је без дијалога избора. Ако апликација није инсталирана, линк отвара веб страницу на истом домену, чувајући корисничко искуство. То их чини пожељном алтернативом за производно окружење.

Механизми fallback

За URL Scheme на iOS и Android не постоји уграђени механизам fallback. Програмери користе посредна серверска решења: линк води до веб странице која проверава инсталацију апликације путем JavaScript-а и преусмерава било на шему, било у продавницу апликација. Firebase Dynamic Links и Branch.io нуде готова решења овог проблема са подршком за deferred deep link, који аутоматски одређују статус инсталације и усмеравају корисника без потребе за развојем сопственог серверског pipeline-а.

Додатна сложеност настаје при коришћењу URL Scheme у iOS 15+ и Android 12+, где су пооштрена правила приватности. Safari блокира покушаје отварања нерегистроване шеме без претходне потврде, а Android 12 ограничава видљивост инсталираних апликација путем PackageManager-а. Ове промене чине употребу URL Scheme за међуапликативну интеракцију мање поузданом него у ранијим верзијама платформи.