Deep linking w iOS, Android i Windows Phone 8

Praktycznie od początku istnienia internetu bardzo duży nacisk kładzie się na to, aby poruszanie się w gąszczu przeróżnych stron było doświadczeniem możliwie jak najszybszym i intuicyjnym. W dużej mierze ułatwia to tzw. „deep linking”, czyli odnoszenie się do konkretnego zasobu zamiast do strony głównej serwisu, na którym zasób ten się znajduje. Dla przykładu, o wiele wygodniej jest zamieścić link do konkretnego klipu na YouTube, niż podać adres strony głównej z instrukcją jak ten klip odnaleźć. Implementacja takiego rozwiązania nie przedstawia większych trudności, gdyż protokół http został skonstruowany w taki sposób, żeby umożliwić prosty dostęp do każdego dokumentu, dla którego ten dostęp powinien być możliwy.

Jednak w przypadku urządzeń mobilnych sytuacja nie wygląda tak różowo. Oczywiście można dalej korzystać z deep linków osadzonych na stronach, które uruchomią zainstalowaną przeglądarkę z załadowaną odpowiednią treścią. Problem pojawia się wtedy, gdy na urządzeniu jest już zainstalowana dedykowana aplikacja, przystosowana do przeglądania danego serwisu.

Tylko po co tak właściwie upierać się przy tym, żeby systemy mobilne mogły obsługiwać deep linki w inny sposób, niż przez odpalenie przeglądarki? Jednym z argumentów za takim zachowaniem systemu jest to, że poprzez przypisanie konkretnego rodzaju odnośnika do aplikacji, użytkownicy mają możliwość w bardzo łatwy sposób dzielić się stanem, w którym taka aplikacja w danym momencie się znajduje. Sama idea uruchamiania aplikacji przez link poprawia również statystyki ich używania – a te, jak wynika z badań firmy Localytics, wypadają słabo, gdyż 60-70 proc. aplikacji nie jest uruchamiana więcej niż 10 razy od momentu zainstalowania.

Dodatkowo obsługa deep linków przez natywne aplikacji pozwala na lepsze sklasyfikowanie ich zawartości i wyświetlanie ich w różnych wynikach wyszukiwania, co jest znane jako „app indexing”. Za przykład może posłużyć tutaj Google, które nie dość, że umożliwia wyświetlanie naszej aplikacji powiązanej z zapytaniem, to dodatkowo posiada mechanizm fallbackowy, odsyłający do sklepu, w przypadku gdy nie jest ona zainstalowana. Taka funkcjonalność pozwala na dalsze zwiększenie rozpoznawalności aplikacji i przyczynia się do jeszcze większej integracji sfery mobilnej z webową. Tyle teorii…

Jak wprowadzić własne odnośniki otwierające aplikację?

Pierwsze próby umożliwienia natywnym aplikacjom obsługę deep linków podjęło Apple, wprowadzając tzw. „custom links” w postaci URI z unikalnym dla aplikacji schematem, np. fb://profile/12345678, który otwiera aplikację Facebooka na profilu o identyfikatorze 12345678. W przypadku wywołania takiego odnośnika, dane z URI można wyciągnąć w AppDelegate po nadpisaniu odpowiedniej metody.

Taki mechanizm posiada jednak kilka wad – unikalność schematu nie jest przez nikogo zagwarantowana, przez co może dojść do kolizji nazw, a brak ustalonego formatu ścieżki i zapytania w URI, może prowadzić do sytuacji, gdzie na dwóch różnych systemach na ten sam zasób, będą wskazywać dwa różne odnośniki. Mimo to custom linki są w systemie iOS wykorzystywane nie tylko jako deep linki, ale stanowią także podstawowe narzędzie do uruchamiania aplikacji z poziomu innej aplikacji. Sytuacja powoli jednak ulega zmianie, gdyż niedawno wypuszczony iOS 9 wspiera możliwość obsługi deep linków w postaci http, co w dużej mierze likwiduje powyższe problemy.

Na systemach z rodziny Android już w momencie wprowadzenia samej możliwości definiowania obsługi deep linków, wzięto pod uwagę oba schematy. Sama deklaracja takich odnośników wymaga jedynie dodania odpowiedniego <intent-filter> z kategorią “Browsable” w AndroidManifeście. Dzięki takiemu podejściu w momencie wywołania odnośnika, dane zawarte w URI można wydobyć bezpośrednio z intentu w danej aktywności.

Opcjonalnie w <intent-filter> można również umieścić kategorię “Default”, dzięki deep link może uruchomić aplikację poprzez implicit intent, bez podawania nazwy jej paczki.

Z kolei na Windows Phone 8 sytuacja wygląda dość podobnie – deklaracja obsługiwanych schematów polega na dodaniu znacznika <Protocol> z opisem URI do znacznika <Extensions> w app manifeście. Warto dodać, że system wprowadza ograniczenie dziesięciu deep linków powiązanych z daną aplikacją. Wczytywanie danych z konkretnego URI odbywa się poprzez podklasowanie klasy UriMapper i przypisanie jej do application frame.

Pomimo tego, że obsługa deep linków wygląda jak detal, to biorąc pod uwagę ich zalety, warto poświęcić trochę czasu na ich implementację. Całkiem prawdopodobne, że w przyszłości zostaną one bardziej ustandaryzowane, a ich użytkowanie będzie czymś zupełnie powszechnym.

Autor

Bartosz Żmija, Andoid/iOS Developer w Ready4S – mobile apps for business