Url scheme ios android

Fokke Zandbergen

Learn. Improve. Share.

Published

26/08/2013

Updated

26/02/2017

by Fokke Zandbergen | 26/08/2013

URL schemes for iOS and Android (1/2)

Most apps have a website. It could be just a launch page, but also a full web-version of the app, like YouTube. In that case, the app is often the prefered way to view the content. But to share it you’d want to use the web URL so that people without the app can also get to it. So how to automatically open the content of a specific webpage in the app for the people who have it, without constantly disturbing the ones who don’t or visit the webpage on their desktop or another unsupported device?

NOTE: This post is outdated. There have been lots of issues and changes related to opening apps via intents and responding to URL schemes. See TIMOB-20490 for more information.

URL Schemes

The key to launching an app is to define an use a custom URL scheme. Like websites URLs start with the http:// scheme, every app can register its own, like myapp:// .

Jason Kneen did an excellent talk explaining what more can be done using URL schemes except just opening an app.

The goal

What we want is to open the app with myapp://view?id=123 when an user with the app installed visits http://myapp.com/view?id=123 . In this first blog, I will give a very detailed recipe on how to define, receive and parse a custom URL. In a next blog, I will show how to set up your web page in such a way that the flow from email/webpage to app using these URLs is as seamless as we can get it.

1. Defining the URL scheme

Define your scheme in tiapp.xml like shown in the next snippet. The CFBundleURLName could be anything but best keep it the same as your app’s id. If you’re using the Facebook module or another module exposing it’s own custom URL scheme for your app, don’t forget to add that one as well. You’ll find out by first building your app without this modification and then opening build/iphone/Info.plist .

Android

LaunchMode

By default, when launching your app via another app, e.g. using the URL scheme in the browser, your apps main activity will be stacked onto the current app’s task. This might be what you want if the launched activity is for showing a map or sending a tweet, but as for your main app activity, this means that if your app was already running in the background or is launched directly later, you will have two instances of it!

Unfortunately, if your app uses heavyweight windows, using the singleTask launchMode will cause your app to hang after its first launch. So make all windows lightweight if you can and please watch the JIRA ticket for further updates on this bug.

2. Receiving the URL

When your app is opened using its URL scheme, you can find out what the exact URL was and act on it accordingly. This is a different process on both Android and iOS. On iOS, you can read Ti.App.getArguments().url both when the app is first opened and when it resumes. On Android, you have to read Ti.Android.currentActivity.intent.data asap. In the next Alloy example this means you have to read it in alloy.js before your index controller gets created and then store it in Alloy.Globals for later use. In a classic Titanium project you would do all this in app.js .

app/alloy.js

app/controllers/index.js

3. Parsing the URL

Because URL schemes can be used by other apps to open your app, it is wise to follow the x-callback-url standard. I won’t get into that now, but in the code above I do use a slightly modified version of their Titanium URL parser, which can be found in my UTiL repo. This would parse myapp://view?id=123 in such a way that you can get view using action() , all parameters via params() or a single one using param(‘id’) . Of course directly using these to open a controller is not the most wise thing to do.

Part 2

In part 2 I’ll show you how to open your app from an email or webpage with minimal effort.

Источник

Deep Linking для мобильных приложений

На WWDC 2015 инженеры компании Apple заявили, что пересмотрели подход к Deep Linking, в прошлом году компания Google анонсировала App Index — как новый взгляд на глубинные ссылки, в начале 2015 года в мире мобильной разработки заговорили о контекстных Deep Links. Что это за инструмент и как с ним работать применительно к iOS — расскажу в этой статье.

Что это?

Один из способов увеличения конверсии при продвижении IT-продукта — уменьшение барьеров для достижения пользователями искомой цели. В мобильной разработке эта проблема еще актуальней. При использовании e-mail, push или sms-рассылок с информацией о промо-акциях упрощение доступа к функционалу приложения просто необходимо. В такой ситуации просто запуск приложения из внешнего источника — не решение, ведь промо-акция — это конкретное спец.предложение в конкретном разделе. Чтобы после запуска приложения пользователю не пришлось по нему бродить, искать и раздражаться, нужен дополнительный инструмент, предопределяющий навигацию. И такой инструмент есть.
Deep Linking (глубинное связывание) — технология, благодаря которой пользователь может перемещаться между приложениями в заранее определенные разделы.

Как это работает?

Представим, что пиццерия решила провести рекламную кампанию, в рамках которой предлагает всем желающим купить пиццу «Маргарита» с 50% скидкой. У пиццерии есть веб-сайт и мобильное приложение (последнее, конечно, предпочтительнее для работы с клиентом по маркетинговым соображениям, да и операции с банковской картой в приложении гораздо удобнее, чем в браузере). Компания делает sms-рассылку по своей клиентской базе с информацией о спец.предложении и дает ссылку на нужный раздел сайта. Если на смартфоне клиента установлено приложение пиццерии, то при переходе по ссылке сервер сайта отправит клиента сразу в нужный раздел аппа для оформления заказа (это и есть механизм Deep Linking), если приложения на смартфоне нет, клиенту предложат установить его в сторе и затем повторно перейти по ссылке в sms (или продолжить пользоваться веб-версией).

В концепции всемирного Web механизм Deep Linking был заложен в HTTP и URL, как возможность перемещения между любыми документами в сети, а не только корневыми страницами. В мобильных операционных системах данный механизм реализуется разными способами.

Как это сделать в iOS

Принцип работы Deep Linking заключается в следующем: пользователь инициирует переход по URL, ресурс, находящийся по этой URL, определяет операционную систему и соответствующим образом осуществляет переход в приложение в заранее определенный раздел.

URL — ссылка, указывающая на местонахождение какого-либо ресурса. Используется преимущественно для адресации в сети, но может быть использована для указания местоположения в файловой системе.

У этой технологии есть несколько способов реализации:

• Классический подход
• Сторонние решения
• Новые веянья с IT-полей

Классическая реализация в iOS

Общепринятая реализация состоит из следующих этапов:

1. Перевод запроса в URL-схему, её исполнение с возможностью обработки отсутствия схемы.
2. Обработка схемы и навигация внутри приложения к заданному разделу/экрану.

URL-схема (URL scheme) — часть URL до ://, ответственная за схему взаимодействия с ресурсом, на который ведет сама ссылка, в большинстве случаев имеется ввиду протокол.

Существует ряд зарегистрированных схем, к примеру http, ftp, tel, mailto , и т.д.

Создание, выполнение и обработка результата выполнения URL-схемы

Для правильной конвертации HTTP-запроса в URL-схему необходимо хранить на сервере таблицу соответствия и/или заданное правило перевода.

Способов правильно выполнить URL-схему и обработать результат существует несколько. Все зависит от того, из какой среды URL-схема выполняется. Если это происходит в iOS приложении, то существуют стандартные способы проверить, зарегистрирована ли URL-схема в системе:

Если же схема выполняется из веб-среды, то оптимально использовать JS-скрипт, который либо запустит приложение, либо отправит на нужный ресурс.

Если через 500 мс не выполнится переход по схеме “myapp://» (ранее сгенерированная схема), то будет осуществлен переход на “fallback.html”.

Данный скрипт необходимо встроить в ресурс, ответственный за переход.
На GitHub есть несколько более или менее удачных реализаций подобных решений.

Обработка полученной URL-схемы и навигация внутри приложения

Эта часть реализации механизма Deep Linking относится исключительно к приложению, которое должно обработать запрос пользователя и перевести его в нужный раздел.

Для этого, в первую очередь, необходимо зарегистрировать собственную URL-схему, которая будет проассоциирована с приложением.
В настройках основного таргета проекта в разделе Info необходимо добавить в пункте URL Types —URL тип вашей схемы (рис 2.)

В поле Identifier необходимо указать bundleID приложения, а в поле URL Schemes — схему, с которой будет связано ваше приложение. Дальше необходимо реализовать механизм навигации в приложении. Для этого надо обработать возможную передачу в приложение URL. Передать её можно многими способами, мы рассмотрим непосредственное исполнение схемы в системе.

Для того чтобы обработать запуск приложения через URL, надо в AppDelegate приложения в методе:

Из словаря lauchOptions достать объект по ключу UIApplicationLaunchOptionsURLKey . Если объект существует, это означает, что приложение запущено посредством URL-схемы и данную схему можно обработать. Если же приложение запущено в момент исполнения схемы, то URL надо извлекать в том же AppDelegate в методе:

Здесь необходимо использовать параметр url для дальнейшей навигации. Навигация в приложении — выбор исключительно личный, но я рекомендовал бы использовать шаблон Router. Во-первых, это не нарушает принцип Single Responsibility, во-вторых, позволит инкапсулировать и в дальнейшем эту навигацию использовать из любого места. Роутер должен принимать в себя URL (как ключ) и выдавать ViewController или же эту навигацию осуществлять.

Сторонние решения

Из сторонних решений можно рассмотреть Mobile Deeplinking (AppURL, AppLinks, UrbanAirShip и т.д.), данные фреймворки являются полноценными решениями для реализации всех компонент технологии Deep Linking. Содержат отдельные библиотеки со своими обработчиками внешних URL и механизмом навигации в приложении. Соответственно, подобные решения требуют интеграции своих SDK в проект.

Отдельно стоит рассмотреть решение, которое не требует интеграции: Deep Link Me сервис предоставляющий возможность запускать приложение с определенной ссылкой, при этом в случае, если приложение не установлено, совершить редирект в магазин. Все настройки происходят непосредственно на сайте, из возможных опций:

• добавление правил соответствия «HTTP-запрос — URL-схема»;
• переход на альтернативный ресурс, включая магазин приложений;
• поддержка iOS/Android.

Единственное неудобство данного решения в том, что весь транзит происходит через deeplink.me, что несомненно увидит пользователь. Для использования этого инструмента необходимо реализовать поддержку URL-схем и навигацию в приложении самостоятельно.

Новый взгляд на Deep Linking

Что нам предлагает Google в технологии глубокого связывания.

Совсем недавно Google стартовал новое направление App Indexing. Конечно, по большей части оно нацелено на Android-разработку и реализовано максимально удобно именно для нее, но и iOS осталась не забыта, правда в ограниченой beta-версии.

Итак:
Помимо работоспособного Deep Linking появилось еще и индексирование приложения в поисковой системе Google. В результате поиска во всемирной сети будут отображаться ссылки на разделы приложения.

Для реализации необходимо:

1. Зарегистрировать еще одну URL-схему в проекте в формате:
gsd-

где, “scheme” — ваша схема, зарегистрированная выше.
2. Подключить фреймворк GoogleAppIndexing (можно через CocoaPods)
3. В вышеуказанных методах вашего приложения обработать переход следующим образом:

Это поможет связать ваше приложение c Google App Indexing и создаст панель для возврата в поиск.
4. Необходимо настроить ваш сайт, на который совершается переход. Для этого в хедер сайта надо добавить:

Также можно дать доступ GoogleBot к вашему сайту для полноценного индексирования.

Все эти способы основаны на работе с URL-схемами. Она давно известна и практикуется. Известны и проблемы, которые могут возникнуть с ними. К примеру, совершенно не определенно поведение, если два разных приложения зарегистрируют одну схему. Также надо обработать альтернативное поведение, если ваше приложение не установлено. В подобных ситуациях вся ответственность ложится на разработчика и ошибки реализации, к сожалению, становятся общей практикой.

Как избежать подобных ситуаций?

И вновь Apple нас не разочаровывает — начиная с iOS 9 добавлена поддержка HTTP и HTTPS с прямым переходом в приложение.
В июне 2015 года на WWDC “парни из Купертино” рассказали нам о новом подходе к реализации такого удобного механизма промоутинга мобильного приложения.

Назвали они его Seamless Linking, что можно перевести как “бесшовные ссылки”. Данный механизм позволяет использовать те же самые веб URL, что и при переходе по разделам вашего сайта, кроме того, связь между приложением и веб ресурсом происходит через Bundle ID приложения, что дает этой связи уникальность, также вы можете указать те разделы сайта, которые представлены в вашем мобильном приложении, и Deep Linking будет работать только для них. Ну круто же.

Как это работает?

Ссылка обрабатывается в системе и из нее извлекается домен (или хост) и непосредственно путь, через который вы можете управлять навигацией в приложении:

https://n-pizza.com/margarita_new

n-pizza и является в данном случае доменом. Домен должен быть проассоциирован с приложением посредством специального файла, защищенного SSL-сертификатом, который хранится на сервере сайта. Называться он должен apple-app-site-association и содержать специальную JSON структуру.

Где 123456.npizza.com — app_bundle_id
“path” : [“*”] — говорит о том, что ваше приложение поддерживает все разделы веб-ресурса, в противном случае, вы можете указать, определенные пути:

Далее созданный JSON необходимо подписать тем сертификатом, который используется на вашем веб-ресурсе, либо сгенерировать новый (допустимо использовать WildCard сертификат) подписать им JSON и добавить его на сервер. Сертификат, которым подписывается приложение в данном случае не используется.

Важно понимать, что для каждого домена должен быть уникальный apple-app-site-association файл

В приложении необходимо установить ассоциации с доменами, которые вы поддерживаете в пункте “Associated Domains”, в настройках проекта. А универсальные ссылки необходимо обрабатывать в методе AppDelegate:

Где, тип активности для универсальных ссылок будет:

Декомпозировать URL можно будет с помощью нативных средств, таких как: класс или сторонних фреймворков, как Bolts от Facebook. Далее навигация должна происходить по уже известной схеме, изложенной выше.

В результате пользователь, переходя по ссылке, или оказывается на том ресурсе, куда эта ссылка вела, или в приложении. Огромный плюс этого решения в том, что URL-схемы не используются. Но не меньший минус, что решение только для iOS и только с 9 версии.

Контекстные Deep Linking

Все, что написано выше, прекрасно работает и дает необходимый эффект проникновения в приложение, только если приложение уже установлено. Если задуматься, то реальная польза будет для крупных компаний, чьи приложения установлены у большинства пользователей смартфонов, а их не больше 40-50 штук.

Если же приложение не установлено, а таких большинство в AppStore или Google Play, то пользователь окажется на странице сайта, либо в магазине приложений, что тоже не очень хорошо, т.к. после установки и запуска приложения будет показан главный экран. Любой из сценариев равносилен не работающему Deep Linking.

Для достижения полного эффекта работы Deep Linking существуют контекстные глубокие ссылки. Суть их работы заключается в том, что условие перехода в приложение (параметры в URL-схеме), по которому строится дальнейшая навигация, и идентификатор устройства сохраняются на серверной стороне. После установки и запуска приложения, это условие запрашивается и строится навигация. Для пользователя все выглядит аккуратно и бесшовно.

Можно реализовать данный подход совместно с любым вышеуказанным методом. Или воспользоваться готовым решением, встроив SDK.

Источник