What is deep linking and how to create deep link urls?

Deeplink types

Regular deeplink are used after your app has been installed. When a regular deeplink is opened, the system identifies and launches its associated app, and transfers the deeplink data to that app, so that it can link the user to the relevant destination content.

Regular deeplinks are often used to interact with the existing users that have already installed your app, for example, for retargeting and user retention.

The weak spot of this technology is that it can be used only if the app has already been installed. For new users that need to visit an app store, install and launch a new app, this technology fails, and the app, when launched, would display its home screen.

When used in tracking links, regular deeplinks increase the number of redirects needed to bring users to a destination page (deeplink or app store); this is due to deeplink implementation constraints and mobile platform specifications. So, for a marketing campaign that targets new users, deferred deeplinking may be a better solution, as it reduces the number of redirects and boosts conversions.

Deferred deeplinks were developed to address the main shortcoming of regular deeplinks that cannot be used to engage new users who have just installed the app. In addition to apps and operating systems, this technology involves a third element, a server that stores information about particular device/app installation and a link to the content to be displayed to the user.

Deferred deeplinking consists of the following basic steps:

  • A special link redirecting the user to an app store is generated
  • When this link is followed, the data needed for attribution and associated deeplink are saved
  • The user downloads, installs and launches your app
  • The app transmits to the server a request to check whether there is a deeplink associated with the relevant user’s device.
  • The server uses the data received from the app to complete attribution (finds the original link redirect, if any) and returns the associated deferred deeplink to the app.

Deferred deeplinks will not work without a tracking library (such as myTracker). Deferred deeplinks are used most frequently as part of a campaign aimed at acquiring new users. For example, you may place an ad for this or that product, and, after a click on the ad, the relevant product will be displayed, once your app is installed and launched.

Types of Deep Links

1. Basic Deep links

These are only opened if the recipient has the application. In this case, a message appears to allow the link to be opened in the application. Otherwise, the user will not be able to access the content. You’ll need to search and download the application from the store, either from Google Play or the App Store and reopen the link to access the content. Basic deep links are the most commonly used because they take the longest time between apps.


Source: Linkedin

2. Deferred Deep Links

This type of link will lead to the content in any way. If you already have the app, it will simply display the content of the link within the native application. So, for the example we saw at the beginning, the sports camera will be seen from the native app.

In the case of deferred deep links, if the user does not have the application installed, the link will lead to the application’s download page in the respective ‘store’. Once the app is installed, you can directly access the shared content.

3. Contextual Deep Links

This type of link has the same functionality as the deferred deep links, but also other advantages. This type of link stores information about where the user wants to go, where he clicked, who shared the link and other information.

Contextual deep links add very relevant information for both developers and users. This information will allow mobile app developers to add customized content like welcome or referral pages. Undoubtedly, very useful to improve the user experience.

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

Порт восходящей связи внешне напоминает любой другой нормальный порт концентратора или коммутатора. Кроме того, подключите порт uplink одного коммутатора к обычному порту другой кабины коммутатора, чтобы помочь расширить размер сети. Но на самом деле между ними много различий.

Рисунок 1: Порты uplink и обычный порт на коммутаторах.

Fibre Uplink Port Vs обычный порт

Дляя uplink агрегации

На оптоволоконном коммутаторе порты восходящей связи имеют большую пропускную способность по сравнению с обычными портами, поскольку они агрегируют трафик между различными уровнями. Порт восходящей связи используется для подключения устройства или меньшей локальной сети к более крупной сети или для подключения к следующему «более высокому» устройству в топологии. Например, коммутатор edge подключается «вверх » к управляемому коммутатору уровня распределения. Оптические соединения uplink на коммутаторах могут помочь увеличить пропускную способность и время реакции тех приложений, которые предъявляют повышенные требования к сети. Оптические восходящие связи 1 ГБ часто используются для увеличения пропускной способности базы данных, видео, голоса и других приложений. Это намного проще и чище, чем при использовании обычного медного порта.

Рисунок 2: Коммутатор соединения Uplink.

Для стека

Порт восходящей связи может быть стековым портом. Это один из двух способов добиться стекирования, кроме использования выделенного порта. Порт Uplink идеально подходит для стекируемых коммутаторов с большей гибкостью и меньшими затратами — просто подключите порты восходящей связи на каждом стекируемом коммутаторе с DAC/AOC или оптическими трансиверами и оптическими патч-кордами. Кроме того, использование оптических портов восходящей связи для стекирования коммутатора может реализовать стекирование на большие расстояния в различных прикладных средах.

Медный Uplink Port Vs Обычный порт

Для облегчения прокладки кабеля

Известно, что при соединении двух обычных портов Ethernet на коммутаторах, обычно используется перекрестный кабель, так что передающие pin на одном конце сетевого кабеля могут быть подключены к приемным pin на другом конце. Порт восходящей связи не пересекает pin передачи и приема, поэтому он устраняет необходимость в перекрестном кабеле. Это означает, что прямой кабель — это все, что вам нужно при соединении двух коммутаторов путем соединения порта восходящей связи и обычного порта.

Рисунок 4: Соединение прямого кабеля и перекрестного кабеля.

Для сохранения порта

Порт восходящей связи на коммутаторе используется для расширения сети. Например подключите порт восходящей связи одного коммутатора к стандартному порту другого коммутатора, с помощью которого можно сохранить обычные медные порты для подключения большего количества конечных точек. Таким образом, коммутаторы могут использовать порты восходящей связи для подключения к другим коммутаторам, чтобы увеличить максимальное количество проводных устройств, подключенных к сети.

Dynamic Link от Firebase

Создание глубинной ссылки в Firebase

Перейдя в Firebase Console -> Dynamic links вы можете приступить к созданию новой ссылки. Вы указываете желаемую целевую страницу, поведение на Android и iOS устройствах.

Создание Dynamic Link

Более того, вы можете указать, что если установленная версия вашего приложения на устройстве меньше заданной, то нужно перейти в Google play.


Настройка Deeplink для Android

При желании можно разметить ссылку UTM метками. Все, остается передать готовую ссылку потенциальным пользователям.

Программное создание Deeplink в Firebase

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

Для решения такой задачи у Firebase есть API для программного создания ссылок.

Обработка Dynamic link в приложении

<activity android:name="com.dimlix.samplesapp.MainActivity">
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>

    <intent-filter android:autoVerify="true">
        <action android:name="android.intent.action.VIEW"/>
        <category android:name="android.intent.category.DEFAULT"/>
        <category android:name="android.intent.category.BROWSABLE"/>
        <data
            android:host="dimlix.page.link"
            android:scheme="https"/>
    </intent-filter>
</activity>

Далее в заданной в обрабатываем Deeplink.

    private void handleDeepLink() {
        FirebaseDynamicLinks.getInstance()
                .getDynamicLink(getIntent())
                .addOnSuccessListener(this, new OnSuccessListener<PendingDynamicLinkData>() {
                    @Override
                    public void onSuccess(PendingDynamicLinkData pendingDynamicLinkData) {
                        // Get deep link from result (may be null if no link is found)
                        Uri deepLink;
                        if (pendingDynamicLinkData != null) {
                            deepLink = pendingDynamicLinkData.getLink();
                            if (deepLink != null) {
                                String path = deepLink.getLastPathSegment();
                                handleDynamicLinkPath(path);
                            }
                        }
                    }
                })
                .addOnFailureListener(this, new OnFailureListener() {
                    @Override
                    public void onFailure(@NonNull Exception e) {
                        Log.w(TAG, "getDynamicLink:onFailure", e);
                    }
                });
    }

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

    private void handleDynamicLinkPath(String path) {
        for (Sample sample : mSamples) {
            if (sample.dynamicLinkPath.equals(path)) {
                Intent sampleActivity = new Intent(this, sample.classtoStart);
                sampleActivity.putExtra(BaseSampleActivity.HEADER_KEY, sample.header);
                sampleActivity.putExtra(BaseSampleActivity.PATH_KEY, sample.dynamicLinkPath);
                startActivity(sampleActivity);
                return;
            }
        }
        showDynamicLinkResolveError();
    }

How does deep linking work?

In order for deep linking to perform the target app first has to be set up using the proper protocols, which is fairly simple and must be done for any deep linking to an app to work, whether from the mobile web, the Facebook app, etc. The advertiser must then provide the deep link to the specific location within the app they want as the destination. These URI (Uniform Resource Identifiers, of which URLs are a subset) formats will vary based on OS but look something like Yelp://12345.

Implementing deep linking requires you to:

  • Select the URI scheme you’ll be using, and declare it in the app’s manifest (discussed in more detail below). As discussed in Part 1.2, the scheme name must be unique to your app, otherwise conflicts with other apps may occur
  • Define the actions you want to launch by using a deep link. Make sure these actions are in accordance with the URI syntax you chose. As mentioned in Part 1.2, the use of the URL syntax is highly recommended (e.g. schemename://path?query_string)

Once that’s done, you can start implementing the code that will handle the path and query string sections of the URL to launch the intended action.

Developers can find this process easier (our team surely appreciated it) if they adhere to the instructions of the Mobile Deeplinking project, which has created a created a MobileDeepLinking library that provides a framework for mobile app deep linking for both iOS and Android. The basic implementation setup is the same for both platforms:

  • Create a deep linking URL scheme (e.g. mobiledeeplinkingprojectdemo://)
  • Update the MobileDeepLinking library JSON configuration file with the appropriate URL and parameter mappings
  • Update the app code to call the MobileDeepLinking library when the app is launched from a deep link

This specification is convoyed by libraries for both iOS and Android. Both libraries include a JSON file that configures the deep link mapping which you can find here

Once that’s done, you can start implementing the code that will handle the path and query string sections of the URL to launch the intended action.

If the setup is being done properly then the following set of rules will be valid:

Here is what the guys from Exponential suggest – add one step and ask the user if they have the target app installed after clicking on the banner, with “Yes” being the deep link. Also include an option to take them to the relevant download page in the app store if they don’t. Here is how this would look like if we take Yelp as an example:

Developers growth hackers and online marketers can refer to several other great resources to upgrade themselves on the deep linking phenomena including this great Wiki and of course Mobiledeeplinking.org

Would you like to share your experiences? While our developers are getting ready with their deep linking experience, we invite some early birds to come aboard and share their challenges in creating deep linking URLs and some cool creative hacks boarded with deep linking.

Technology

Regular deeplinks rely on a variety of platform-specific technologies. Their brief descriptions and links to additional information are provided below:

  • Android
    • App URL Schema – any app can select its unique scheme to be used in deeplinks. For example:youla://link/to/offer, tamtam://chat/chatname. In these examples, youla and tamtam are URL schemes used by an app. After that, the app may set up the Intent filter and intercept links that match the scheme specified in the filter. For more details on intent filters and their implementation, refer to https://developer.android.com/guide/components/intents-common
    • Android App Links – an extension of the technology described above, similar in essence to Universal links in iOS. In this case, the app may set intent filter to work with standard http/https links and domain names. When a link matching the filter is followed, the user will be prompted to open that link in the relevant app.
  • iOS
    • URL Schemes – just like with Android, your app may select and register a URL-scheme, and any links matching that scheme will be opened in the relevant app. For more implementation details, refer to: https://developer.apple.com/library/content/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Inter-AppCommunication/Inter-AppCommunication.html
    • Universal links – similarly to Android App Links, one or several domains can be associated with an app, after which links that match filter specifications will be opened in that application. For more information on universal links, refer to iOS documentation

Two types of deep links

There are two kinds of links: default and deferred deep links.

Default

Default deep links only direct users to an app if it’s already installed. If the app is not installed, the link can’t reach the endpoint of an app then an error message is displayed.

Default deep links are useful for retargeting campaigns where an app marketer is solely interested in finding users who have the app installed, and want them to return.

Deferred

Deferred deep links are more complex than default deep links. They can direct users to the App or Play Store if the user does not have the app installed (or to another location, such as the app’s website for more information), and then open the original page that user was directed to.

So, for example, if a user downloads an e-commerce app after clicking an ad for a pair of shoes, but doesn’t have the app installed, they will first be routed to the store for download. When they open the app after install, the product page would be shown.

Deferred deep links are only made possible through a deep linking solution like Adjust’s. They’re created via an SDK integration, and more information on this, click for Android and for iOS.

Contextual deep linking?

You may have heard the term contextual deep linking. These refer to links that ostensibly provide additional benefit, in the form of being able to store more information allowing marketers to do more with their content.

Contextual deep links are default or deferred deep links with added parameters marketers can add themselves. Such links don’t exist by themselves.

Handling Deeplinks in JavaScript

Ionic/Angular 2

note: make sure to call IonicDeeplink from a platform.ready or event


Using Ionic Native (available in 1.2.4 or greater):

import { Platform, NavController } from 'ionic-angular';
import { Deeplinks } from '@ionic-native/deeplinks';

export class MyApp {
  constructor(
    protected platform: Platform
    , protected navController: NavController
    , protected deeplinks: Deeplinks
    ) {
    this.platform.ready().then(() => {
      this.deeplinks.route({
        '/about-us': HomePage,
        '/products/:productId': HelpPage
      }).subscribe((match) => {
        // match.$route - the route we matched, which is the matched entry from the arguments to route()
        // match.$args - the args passed in the link
        // match.$link - the full link data
        console.log('Successfully matched route', match);
      },
      (nomatch) => {
        // nomatch.$link - the full link data
        console.error('Got a deeplink that didn\'t match', nomatch);
      });
    });
  }
}

// Note: routeWithNavController returns an observable from Ionic Native so it *must* be subscribed to first in order to trigger.

If you’re using Ionic 2, there is a convenience method to route automatically (see the simple Ionic 2 Deeplinks demo for an example):

import { Platform, NavController } from 'ionic-angular';
import { Deeplinks } from '@ionic-native/deeplinks';

export class MyApp {
  constructor(
    protected platform: Platform
    , protected navController: NavController
    , protected deeplinks: Deeplinks
    ) {
    this.platform.ready().then(() => {
      this.deeplinks.routeWithNavController(this.navController, {
        '/about-us': HomePage,
        '/products/:productId': HelpPage
      }).subscribe((match) => {
        // match.$route - the route we matched, which is the matched entry from the arguments to route()
        // match.$args - the args passed in the link
        // match.$link - the full link data
        console.log('Successfully matched route', match);
      },
      (nomatch) => {
        // nomatch.$link - the full link data
        console.error('Got a deeplink that didn\'t match', nomatch);
      });
    });
  }
}

// Note: routeWithNavController returns an observable from Ionic Native so it *must* be subscribed to first in order to trigger.

Ionic/Angular 1

For Ionic 1 and Angular 1 apps using Ionic Native, there are many ways we can handle deeplinks. However, we need to make sure we set up a history stack for the user, we can’t navigate directly to our page because Ionic 1’s navigation system won’t properly build the navigation stack (to show a back button, for example).

This is all fine because deeplinks should provide the user with a designed experience for what the back button should do, as we are putting them deep into the app and need to provide a natural way back to the main flow:

(See a simple demo of v1 deeplinking).

angular.module('myApp', 'ionic', 'ionic.native')

.run('$ionicPlatform', '$cordovaDeeplinks', '$state', '$timeout', function($ionicPlatform, $cordovaDeeplinks, $state, $timeout) {
  $ionicPlatform.ready(function() {
    // Note: route's first argument can take any kind of object as its data,
    // and will send along the matching object if the route matches the deeplink
    $cordovaDeeplinks.route({
      '/product/:productId': {
        target: 'product',
        parent: 'products'
      }
    }).subscribe(function(match) {
      // One of our routes matched, we will quickly navigate to our parent
      // view to give the user a natural back button flow
      $timeout(function() {
        $state.go(match.$route.parent, match.$args);

        // Finally, we will navigate to the deeplink page. Now the user has
        // the 'product' view visibile, and the back button goes back to the
        // 'products' view.
        $timeout(function() {
          $state.go(match.$route.target, match.$args);
        }, 800);
      }, 100); // Timeouts can be tweaked to customize the feel of the deeplink
    }, function(nomatch) {
      console.warn('No match', nomatch);
    });
  });
})

Non-Ionic/angular

Ionic Native works with non-Ionic/Angular projects and can be accessed at if imported.

If you don’t want to use Ionic Native, the plugin is available on with a similar API minus the observable callback:

window.addEventListener('deviceready', function() {
  IonicDeeplink.route({
    '/product/:productId': {
      target: 'product',
      parent: 'products'
    }
  }, function(match) {
  }, function(nomatch) {
  });
})

Ключевое понятие

Диплинк — маршрут пользователя к конкретным местам на веб-сайте или нативному приложению по ссылке. А вот версия термина mobile deep link говорит о том, что эта ссылка будет содержать в себе всю необходимую информацию о входе в приложение и в конкретное место в нём, а не только сам запуск установленной программы.

Таким образом, диплинкинг связан с URL-адресами и URI (англ. «универсальный идентификатор ресурсов»), которые представляют собой строку символов, используемых для идентификации имени ресурса в сети.

Приложения, которые установлены на устройстве, могут напрямую открываться через уникальную зарегистрированную схему, называемую схема URI. Можно провести аналогию между реальной почтой и веб-адресом в сети — схема URI будет работать только в том случае, если её обслуживают инженеры-«почтальоны» и номер ящика зарегистрирован в базе адресов (в данном случае — в магазине приложений).

AS-PATH Prepend

Попробуем применить этот метод в нашей сети. Для этого создадим на CSR два route-map и используем их:

Теперь в сторону ISP#1 префикс 172.16.9.0/24 будет анонсироваться с AS-PATH, удлиненным на три номера AS65000, а в сторону ISP#2 тоже самое будет делаться для префиксов 172.16.7.0/24 и 172.16.8.0/24.

Теперь, в идеале, трафик для каждой группы префиксов должен поступать через своего провайдера, а в случае падения одного из uplink, начнет работать анонс с prepend. Например, при падении ISP#2 трафик для 172.16.9.0/24 не прервется, так как весь мир все равно «видит» этот префикс через ISP#1, хоть с удлиненным AS-PATH.

Этот способ сработал бы, но тут в игру вмешиваются различные local preferences, которые провайдеры используют для клиентов и пиринга. Так как, при выборе маршрута атрибут LOCAL PREFERENCE имеет больший приоритет, чем AS-PATH, внутри каждого провайдера наш prepend не будет играть роли и трафик всегда будет направляться через клиентский канал. В нашей сети этот метод сработает только для AS65050, так как она присоединена в обоим провайдерам.

Посмотрим подробней.

Действительно, на R5 все хорошо:

На основе атрибута AS-PATH для каждой группы префиксов выбран оптимальный маршрут через своего провайдера, что подтверждает трассировка.

Но вот на R11 (AS65110) все не так радужно.

Трафик до обоих хостов идет к нам через один и тот же пятисотмегабитный стык.

Причина как раз в local preference. Смотрим на R13 провайдера ISP#2:

На маршрутизаторе все BGP-анонсы наших сетей в двух экземплярах:

  • полученные через клиентское присоединение (next-hop 192.168.103.100);
  • полученные через пиринг (next-hop 192.168.200.12).

Но, несмотря на длинный AS-PATH, для префиксов 172.16.7.0/24 и 172.16.8.0/24 best-маршрут – маршрут с local preference 120 через клиента, т.е. через нас, а не через пиринг. Получается, что ISP#2 направит весь трафик наших абонентов через канал 500Mbps. И, если за этим провайдером окажется дата-центр какого-нибудь крупного контент-провайдера (например VK.com), то это приведет к перегрузке на канале и проблемам с сервисом.

Получается, что стандартный AS-PATH prepend нам не поможет.

Уведомления

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

Для отправки APNS-уведомлений вы можете использовать локальный сервер и PusherAPI (это один из наиболее простых способов).

Мы затронем только часть между тапом по пуш-уведомлению и получением видимого результата.

Когда приложение закрыто или работает в фоновом режиме, тап по уведомлению запустит в appDelegate метод didReceiveRemoteNotification:

Для обработки уведомлений мы создадим NotificationParser:

Теперь мы можем связать этот метод с Deeplink Manager’ом:

И дополнить метод класса appDelegate didReceiveRemoteNotification:

Последним шагом будет дополнение метода разбора в NotificationParser’е. Он может различаться в зависимости от структуры ваших уведомлений, но основная техника разбора будет аналогична:

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


apns: {aps: {alert: {title: «New Message!»,subtitle: «»,body: «Hello!»},»mutable-content»: 0,category: «pusher»},data: {«messageId»: «1»}}

В этом примере для отправки уведомлений я использую локальный NodeJS-сервер и Pusher API. Настройка занимает всего несколько минут и требует базового уровня владения NodeJS или навыков копирования-вставки.

Запустите приложение, сверните его в фон и отправьте уведомление. Когда получите уведомление, коснитесь его, чтобы открыть приложение:

Вот что происходит за кадром:

  1. Когда вы касаетесь уведомления, приложение инициирует метод делегата didReceiveRemoteNotification
  2. didReceiveRemoteNotification передаёт информацию из уведомления в Deeplink Manager
  3. Deeplink Manager пробует получить Deeplink Type по Notification User Info используя NotificationParser
  4. В методе applicationDidBecomeActive мы производим проверку наличия DeeplinkType’ов
  5. Если существует DeeplinkType (т.е. шаг 3 завершился успешно), мы выполняем соответствующее действие с помощью DeeplinkNavigator’а
  6. Как только шорткат был обработан, DeeplinkManager сбрасывает значение текущего шорткат-элемента к nil, чтобы не использовать его повторно

* * *

Этот подход позволяет легко добавлять или изменять любые элементы и не требует значительных изменений кода

И, что особенно важно, вы можете разбирать deeplink, соответствующим парсером. Например, чтобы добавить “Новый запрос” в обработчик уведомлений, вам всего лишь нужно изменить метод handleNotification в NotificationParser’е:

Обратите внимание, мы не используем didFinishLaunchingWithOptions ни для одного из этих deeplink’ов. Всё обрабатывается средствами applicationDidBecomeActive

Поздравляю! Теперь ваше приложение оснащено унифицированной поддержкой шорткатов, deeplink’ов и уведомлений!

* * *

Смотрите итоговый проект здесь.

* * *

Why do you need deep linking?

Let’s assume you’ve published a music app. To celebrate the release of a new song, you’ve paid tons of money to run a campaign on a popular website. In your campaign, you feature a brief sample of the song – and you probably want the user to listen to the sample inside of your app rather than on your website, where they would only see the album cover.

In another example, let’s say you want to regain inactive users through a sales campaign. In this campaign, users would be directed to the sale products page in your app with a single click, without having to search for it or manually type a coupon code. Both of these examples are where deep links come into play: deep linking makes these campaigns possible.

Mobile app deep linking brings seamless user experience and can increase your conversion rate and retention rate significantly. If you’d like to learn more about this, take a look at our blog post discussing the effects of deep linking in campaigns.

Linking to the scheduling dialog

Note

This feature is currently in developer preview.

You can create deep links to the Teams client’s built-in scheduling dialog. This is especially useful if your app helps the user complete calendar or scheduling-related tasks.

Generating a deep link to the scheduling dialog

Use this format for a deep link that you can use in a bot, Connector, or messaging extension card:

Example:

The query parameters are:

  •  The optional comma-separated list of user IDs representing the attendees of the meeting. The user performing the action is the meeting organizer. The User ID field currently only supports the Azure AD UserPrincipalName (typically an email address).
  •  The optional start time of the event. This should be in long ISO 8601 format, for example “2018-03-12T23:55:25+02:00”.
  •  The optional end time of the event, also in ISO 8601 format.
  •  An optional field for the meeting subject.
  •  An optional field for the meeting details field.

Currently, specifying the location is not supported. When generating your start and end times be sure to specify the UTC offset (time zones).

Подготовка проекта

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

  • Страница “Мои сообщения” (предпросмотр): доступна через шорткат
  • Сообщения (определённый чат): доступны через пуш-уведомления
  • Создать новый список: доступно через шорткат только для профиля хозяина (принимающей стороны)
  • Мои последние действия: доступны через шорткат
  • Запрос брони: доступен как через email-ссылку (deep link), так и через пуш-уведомление

Для начала создайте простой проект с ViewController’ом, NavigationBar’ом и кнопкой для смены профиля “Switch Profile”:

Подготовка проекта

Во View Controller’е будет содержаться текущий тип профиля и механизм переключения профилей.

* * *

Создаём диплинки

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

  1. Традиционный диплинк ведёт на страницу/раздел в приложении, если только оно уже установлено на смартфоне.
  2. Отложенный диплинк понимает, что на смартфоне нет нужного приложения, поэтому сперва ведёт пользователя в магазин приложений, а после установки нужной программы открывает именно тот раздел, что был нужен при переходе.
  3. Контекстный диплинк является дополненной версией отложенного и позволяет отслеживать трекинг переходов, количество кликов, откуда был совершён переход, и многие другие данные.

Создавать диплинки можно как в «ручном» режиме, так и с помощью специализированных сайтов и сервисов. Например, AppsFlyer, Branch, Firebase, Yozio, Adjust.

iOS

UnityDeeplinks implements a native plugin for iOS, initialized by Assets/UnityDeeplinks/UnityDeeplinks.cs. The plugin listens for URL/Univeral Link activations and relayes them to the Unity script for processing. It, too, uses a similar approach as the one used for Android: the main Unity app controller gets subclassed.

Also, like in the Android case, if the app is currently not running, we can’t simply have the native low-level deeplinking code make calls to Unity scripts until the Unity libraries are initialized. Therefore, we store the deeplink in a variable, wait for the app to initialize the plugin (an indication that the Unity native libraries are ready), and then send the stored deeplink to the Unity script.

  • To support URL schemes, go to your Unity project’s Build => iOS Player Settings => Other Settings => Supported URL Schemes and set:
  • Size: 1
  • Element 0: your URL scheme, e.g. myapp

С этим читают