Как открыть диплинк на андроиде

Deeplink – как сделать переход по ссылке в приложение

Реклама

Что такое DeepLink?

DeepLink – это глубинные ссылки. Но что такое глубинные ссылки? – сейчас объясню.

Это такие ссылки, которое обеспечивают внешнее связывание, т. е. связывание вашей ссылки с приложением (или другим сайтом) напрямую. Наверняка, вы нажимали на ссылки на своем смартфоне, и он открывал приложение вместо сайта. Так, например, если вы перейдете на сайт links.glimake.ru и нажмете на любую иконку, то откроется соответствующее приложение, если оное у вас установлено. Ранее Deeplink-ами называли любые прямые ссылки с одного сайта на другой, например, instagram.com/glimake/. Т.е. с одного сайты Вы переходите на конкретную страницу другого ресурса внутри своего браузера.

Зачем нужны Deeplink-и?

Простой ответ — для увеличения конверсии. Чаще Deeplink используют коммерческие компании на своих сайтах, чтобы получить больший охват в социальных сетях. Сами подумайте, вам было бы проще нажать на сайте какой бы то ни было компании на иконку Вк и попасть в приложение Вконтакте или если открылся бы браузер и загрузилась страница vk.com? Логично, что первый вариант, так как приложения более удобны для пользователя.

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

При создании ссылки указывается не просто тело с URL, а добавляются специальные значения, которые переадресуют пользователя на необходимое приложение, если оно у вас установлено. Если нет, то откроется браузер с переходом на веб версию приложения. Например, Вы хотите переадресовать пользователя на свой Instagram аккаунт:
1 способ: [Instagram] Вы указываете обычную ссылку, нажав на нее, откроется браузер с соответствующим профилем.
2 способ: [ Instagram ] «Волшебная ссылка» откроет приложение, если у вас установлен Instagram, если нет, то также откроется профиль в браузере.

P.S. 2-й способ нужно пробовать через смартфон, чтобы увидеть эффект.

Как сделать Deeplink?

Есть 3 способа сделать свои DeepLink:

Как сделать Deeplink самому?

Также необходимо в любое место кода между тегами и

Источник

Делюсь небольшим, но полезным плагином: Deeplink Helper для Android Studio

DRY. Don’t Repeat Yourself. Принцип, призывающий разработчика не дублировать код. DRY часто можно распространить шире, не только на код. Сегодня расскажу о личном проекте, который уже помог мне и другим разработчикам избавиться от последовательности рутинных действий при разработке и отладке приложений для Android. И не просто расскажу — а ещё и поделюсь этим инструментом и его исходным кодом.

Рассмотрим проблему на примере нашего продукта. Яндекс.Маркет — приложение большое, но стандартное с точки зрения разработки. Оно состоит из множества связанных между собой экранов с различными состояниями. Разработчик, создавая функциональность, часто имеет дело с экранами, до которых можно добраться только после множества действий в интерфейсе приложения. Пользовательские сценарии порой состоят из десятков действий, и все их нужно воспроизводить при отладке или проверке приложения. Согласитесь, это даже звучит больно.

Если при работе над приложением вы хотите уменьшить количество таких действий и переключений фокуса с IDE на Android-устройство, то прошу под кат.

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

Напомню, что диплинк — это специальным образом сформированный URI. Чтобы приложение его поддерживало, нужно зарегистрировать схему URI в манифесте приложения и реализовать логику обработки. Более подробная документация тут. Как правило, диплинки используются, чтобы открывать приложение на определённом экране после клика на сайте или в рассылке. Для тестирования диплинков в Android можно имитировать переход по диплинку через ADB-команду.

На тот момент в нашем приложении уже поддерживался ряд диплинков, но покрывали они только часть необходимой мне функциональности. Поэтому для описанного выше сценария создали два новых диплинка: переключение региона и добавление товара в корзину. Такие диплинки необходимы только для отладки и тестирования, поэтому мы называем их отладочными, они недоступны пользователям в релизной сборке. Логика обработки стандартных диплинков — это действия, связанные с навигацией внутри приложения. Отладочные диплинки, как правило, оперируют с логикой, не связанной с UI.

Несмотря на то что создавать диплинки просто, управлять ими через ADB крайне неудобно. Нужно каждый раз искать в истории терминала команду с определёнными параметрами, вспоминая соответствие параметров и результата. Вот эту проблему я и решил с помощью плагина для Android Studio.

Чем плагин лучше приложения:

Таким образом получается автоматизировать целые сценарии. Я редко пользуюсь выполнением сценариев полностью, за раз. Как правило, удобнее поочерёдно выполнять команды. Сценариями особенно трудновоспроизводимых случаев можно делиться с тестировщиками. Экономим их время.

В какой-то момент возникла потребность добавить в плагин возможность выполнения произвольных ADB-команд. И это было сделано. И конечно же, помимо диплинков, можно добавлять произвольные ADB/shell-команды. Задаётся это всё в едином конфигурационном файле формата JSON, в котором следует указать packageName приложения. Также доступно редактирование конфигурации, туда можно добавить и свои диплинки, и полезные ADB-команды (примеры тут).

Я чаще всего использую такие сценарии, состоящие только из ADB-команд:

Плагин продолжает разрабатываться. Например, пока нельзя выбрать из нескольких подключённых устройств, обрабатываются диплинки не более чем с одним аргументом. Если вам интересно присоединиться к доработке Deeplink Helper, присылайте пул-реквесты на гитхабе. Сам плагин можно скачать тут.

Надеюсь, этот простой инструмент сэкономит время и вам. Уверен, существуют альтернативные варианты решения этой проблемы — буду рад обсудить их в комментариях.

Источник

От веба до приложения за один DeepLink

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

Диплинки были придуманы так давно, что сейчас уже сложно представить приложение без них. Сама по себе технология не требует свежего Android API, однако если допиливать App Indexing, то можно столкнуться с тем, что работает оно с API 17.

Вернёмся к диплинкам. Их конфигурация представляет собой набор настроек для intent-filter в манифесте приложения, которые описывают паттерны поддерживаемых ссылок.

После этих нехитрых манипуляций при каждом нажатии на ссылку, удовлетворяющую настройкам фильтра, пользователю предлагается выбор между несколькими приложениями, в том числе и вашим. Далее активити, для которой мы задали intent-filter, получит Intent, содержащий в себе линк. Если достать его методом Intent#getData и распарсить необходимые параметры, то можно направить пользователя сразу в интересующий раздел.

После реализации может возникнуть вполне резонный вопрос: что делать, если у пользователя ещё нет приложения? Ответом будут особые диплинки, которые в этом случае умеют направлять человека в Маркет. При должном усердии такую ссылку можно генерировать самим, но нет никаких гарантий, что она будет работать со всеми браузерами и на всех версиях Android. Сейчас довольно много сервисов, предлагающих решение по крайней мере части этих проблем, например, AppsFlyer с их OneLink или Firebase с DynamicLink. Все они работают примерно одинаково, только DynamicLink использует для обработки диплинков предустановленные сервисы Google.

OneLink

Сам по себе OneLink ведёт на серверы AppsFlyer; они определяют, с какого устройства пользователь вышел в сеть, и перенаправляют его на соответствующий адрес. Можно задать редиректы для десктопа, Android и iOS. Когда Android-приложение установлено, линк прилетает в него через Intent как обычный диплинк. Когда приложения нет, в работу вступают Google Chrome и Google Play.

Наличие приложения проверяется браузером. У Chrome есть спецификация особого формата ссылок, которые потом конвертируются им в Intent и отправляются в систему. Она предусматривает задание ссылки на Google Play в случае, если приложение не установлено. Подробнее с ней можно ознакомиться тут.

Вообще в Google Play можно передать ссылку на приложение таким образом, чтобы после установки и запуска он прокинул часть её дальше. Это реализуется с помощью query-параметра url и будет выглядеть примерно так:

В этом случае best.memes/jokes попадёт внутрь приложения после его установки в виде диплинка. По умолчанию AppsFlyer работает не так: он предлагает получить ссылку через интерфейс библиотеки. Сам диплинк при этом, видимо, передаётся в приложение через серверы сервиса.

Это очень неудобно, потому что, во-первых, мы не можем понять наверняка, надо ли нам ждать какие-то параметры или пользователь просто тыкнул в иконку и параметров не будет. Во-вторых, мы хотим сразу открывать нужный раздел приложения, без лишних блокировок и ожиданий. AppsFlyer же предлагает открывать главный экран, а когда пришли (и если пришли) параметры, то редиректить. Нас такой подход не устроил, поэтому мы сгенерировали свой url в Google Play с параметром для случая, когда пользователь переходит по диплинку с Android-устройства и у него нет приложения. Его мы задали в Onelink, чтобы получать диплинк в приложении без необходимости дожидаться библиотеку.

OneLink работал отлично, пока мы не попробовали пошарить его в Slack. Дело в том, что он открывает ссылки в своём встроенном браузере через Chrome Custom Tabs. Если коротко, то это вкладка браузера, которая открывается в процессе вашего приложения и может быть кастомизирована, чтобы не выбиваться из общего стиля (подробнее можно почитать тут). В этом случае откроется веб-версия Google Play и диплинк в приложение после установки проброшен не будет. Аналогично браузер ведёт себя, если руками скопировать OneLink в адресную строку и перейти по ссылке. Об этом случае разработчики Chrome писали в Release Notes несколько версий назад. Суть в том, что при таком подходе в браузере не срабатывает редирект в Google Play, когда приложение не установлено, и пользователь остаётся в вебе. Силами OneLink побороть это поведение не удалось, поэтому мы обратились к DynamicLink.

DynamicLink

Глубокая интеграция Google Play Services в систему позволяет им оптимизировать проверку наличия целевого приложения на устройстве. Это довольно закрытая экосистема, поэтому досконально разобраться в принципах её работы не удалось, однако всё указывает на то, что Chrome открывает активити с прогрессом, принадлежащую Google Play Services, которая определяет, как ей поступить с диплинком. После этого либо происходит редирект либо в Google Play, либо в приложение. При этом диплинк потом попадает в приложение через Intent, то есть без дополнительных библиотечных костылей.

Субъективно, такой подход функционирует не быстрее, чем OneLink, однако он работает при открытии ссылки в Chrome Custom Tabs, что является существенным преимуществом, потому что их используют многие приложения.

Кроме прочего, Firebase позволяет посмотреть схему работы ссылки и куда редиректится пользователь на каждой платформе в каждом случае. Выглядит это примерно так:

Выводы

Из таблицы видно, что в реализации с DynamicLinks всё работает без костылей и во всех интересных нам случаях.

Источник

Открытие URL-ссылок с помощью Android-приложения (Deep Links)

Что такое Deep Links и как интегрировать их в своё приложение

Apr 28, 2018 · 3 min read

Как работает открытие ссылок через приложение и зачем оно вообще нужно?

Нередко бывает так, что определённому контенту соответствует и страница на сайте, и экран в приложен и и. В таких случаях пользователю, у которого установлено приложение, удобно будет открывать ссылку на этот контент через приложение. Как пример можно взять интернет-магазин. Пользователь может нажать на ссылку в браузере, после чего ему предложит просмотреть страницу товара через приложение. Также это хорошо используется с шарингом ссылок. Пример: Петя увидел классные кроссовки на сайте и скинул ссылку на них Васе в Telegram. У Васи уже установлено приложение интернет-магазина, поэтому он нажав на ссылку в Telegram попадает на экран приложения, в котором отображается вся информация об этих замечательных кроссовках. Удобно, не правда ли?

Разделение на Deep Links и Android App Links

Перед тем, как мы займемся реализацией, важно понять, что есть два способа обработки ссылок:

1. Deep Links

Глубокие ссылки (Deep Links) — это URL, которые направляют пользователя на определённый контент в вашем приложении. Они реализуются созданием интент-фильтра и извлечением информации из входящих интентов. Если на телефоне установлены приложения, которые могут обрабатывать такие же интенты, то пользователю будет предложено несколько приложений на выбор, и он сможет выбрать через какое открыть ссылку.

2. Android App Links

Android App Links доступны только с Android 6.0 (API 23) и позволяют назначать приложение дефолтным обработчиком ссылок определённого типа. Главное отличие от Deep Links заключается в том, что никакое другое приложение кроме вашего не сможет обработать ссылку.

В этой статье будет рассматриваться первый тип ссылок — Deep Links.

Постановка задачи

Давайте на простом и типичном примере посмотрим как можно добавить обработку глубоких ссылок в приложение.

Допустим, у нас есть сайт с вакансиями, на котором каждой вакансии соответствует ссылка вида https://awesomejobs.com/jobs/. Мы хотим, чтобы пользователям, у которых установленно наше приложение, при клике на ссылку предлагалось открыть её или через наше приложение, или через браузер.

Реализация

category android.intent.category.DEFAULT требуется если вы хотите чтобы приложение обрабатывало ссылку с любого ссылающегося сайта. Интент, который используется при переходе из результатов поиска Google знает, что должен открыть именно ваше приложение, поэтому явно указывает на него как на получателя. Ссылки же с других сайтов не знают ничего о вашем приложении, поэтому категория DEFAULT говорит о том, что приложение способно принять неявный Intent от них.

2. Наше приложение научилось ловить интенты извне, теперь нам нужно написать код для того, чтобы перехватывать их, доставать id вакансии и с ним уже делать всё, что нам захочется (запрашивать с сервера информацию о вакансии с таким id и отображать её, например).

Для этого в метод onCreate активити, которую мы использовали в манифесте, добавим следующий код:

Активити запускается интентом, содержащем в себе ссылку. data — это и есть не что иное, как наша ссылка. Получив её и выполнив необходимые проверки, мы вырезаем из неё id вакансии, подтягиваем её детали с сервера и отображаем на экране. Всё предельно просто.

Источник

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, определяет операционную систему и соответствующим образом осуществляет переход в приложение в заранее определенный раздел.

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

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

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

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

Создание, выполнение и обработка результата выполнения 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 приложения в методе:

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

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

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

Новый взгляд на 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 структуру.

Далее созданный 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.

Источник