Les applications Android sont le reflet du site ou du service et représentent souvent des fonctionnalités similaires dans un shell pratique. Pour cette raison, la question de la navigation entre une page sur le Web et un client installé devient urgente. Pour résoudre ce problème, des liens profonds ont été inventés. Sous la coupe, vous trouverez une histoire fascinante sur la façon dont nous les avons mis en œuvre à la maison et traité le cas lorsque l'utilisateur n'a pas encore installé notre application.
Les liens profonds ont été inventés il y a si longtemps qu'il est maintenant difficile d'imaginer une application sans eux. La technologie elle-même ne nécessite pas de nouvelle API Android, cependant, si vous terminez l'indexation des applications, vous pouvez rencontrer le fait qu'elle fonctionne avec l'API 17.
Revenons aux liens profonds. Leur configuration est un ensemble de paramètres de filtre d'intention dans le manifeste d'application, qui décrivent les modèles de liens pris en charge.
Par exemple:
<intent-filter> … <data android:host="best.memes" android:pathPrefix="/memes" android:scheme="http" /> <data android:host="best.memes" android:pathPrefix="/jokes" android:scheme="https" /> … </intent-filter>
Après ces manipulations simples, chaque fois que vous cliquez sur un lien qui correspond aux paramètres du filtre, l'utilisateur a le choix entre plusieurs applications, dont la vôtre. Ensuite, l'activité pour laquelle nous avons défini le filtre d'intention recevra une intention contenant un lien. Si vous l'obtenez à l'aide de la méthode Intent # getData et analysez les paramètres nécessaires, vous pouvez diriger immédiatement l'utilisateur vers la section qui vous intéresse.
Après la mise en œuvre, une question raisonnable peut se poser: que faire si l'utilisateur n'a pas encore l'application? La réponse sera des diplinks spéciaux, qui dans ce cas peuvent diriger une personne vers le marché. Avec une diligence raisonnable, vous pouvez générer un tel lien vous-même, mais rien ne garantit qu'il fonctionnera avec tous les navigateurs et sur toutes les versions d'Android. Maintenant, il existe de nombreux services offrant une solution à au moins une partie de ces problèmes, par exemple, AppsFlyer avec leur OneLink ou Firebase avec DynamicLink. Tous fonctionnent à peu près de la même manière, seul DynamicLink utilise des services Google préinstallés pour traiter les diplinks.
Onelink
OneLink lui-même mène aux serveurs AppsFlyer; ils déterminent à partir de quel appareil l'utilisateur est entré sur le réseau et le redirigent vers l'adresse appropriée. Vous pouvez définir des redirections pour le bureau, Android et iOS. Lorsque l'application Android est installée, le lien y circule via Intent comme un lien profond régulier. Lorsqu'il n'y a pas d'application, Google Chrome et Google Play entrent en jeu.
La présence de l'application est vérifiée par le navigateur. Chrome a une spécification pour un format de lien spécifique, qui est ensuite converti en intention et envoyé au système. Il permet de définir un lien vers Google Play au cas où l'application ne serait pas installée. Plus de détails peuvent être trouvés
ici .
En général, sur Google Play, vous pouvez transférer le lien vers l'application de telle manière qu'après l'installation et le lancement, il en sautera une partie plus loin. Ceci est implémenté à l'aide du paramètre de requête url et ressemblera à ceci:
play.google.com/store/apps/details?id=memes.best&url=https%3A%2F%2Fbest.memes%2FjokesDans ce cas,
best.memes / jokes va pénétrer dans l'application après son installation en tant que lien profond. Par défaut, AppsFlyer ne fonctionne pas de cette façon: il propose d'obtenir le lien via l'interface de la bibliothèque. Le lien profond lui-même est apparemment transféré vers l'application via les serveurs de service.
AppsFlyerLib.getInstance().init(KEY, new AppsFlyerConversionListener() { @Override public void onInstallConversionDataLoaded(final Map<String, String> map) { } @Override public void onInstallConversionFailure(final String s) { } @Override public void onAppOpenAttribution(final Map<String, String> map) { } @Override public void onAttributionFailure(final String s) { } }, mContext);
C'est très gênant, car, tout d'abord, nous ne pouvons pas savoir avec certitude si nous devons attendre certains paramètres ou si l'utilisateur vient de cliquer sur l'icône et qu'il n'y aura pas de paramètres. Deuxièmement, nous voulons ouvrir immédiatement la section souhaitée de l'application, sans verrous ni attentes inutiles. AppsFlyer propose d'ouvrir l'écran principal, et lorsque les paramètres sont arrivés (et s'ils sont arrivés), puis rediriger. Cette approche ne nous convenait pas, nous avons donc généré notre URL sur Google Play avec un paramètre pour le cas où un utilisateur clique sur le diplink depuis un appareil Android et n'a pas d'application. Nous l'avons défini dans Onelink pour obtenir un lien profond dans l'application sans avoir à attendre la bibliothèque.
OneLink a bien fonctionné jusqu'à ce que nous essayions de le fouiller dans Slack. Le fait est qu'il ouvre des liens dans son navigateur intégré via les onglets personnalisés de Chrome. En bref, il s'agit d'un onglet de navigateur qui s'ouvre lors de votre candidature et peut être personnalisé afin de ne pas sortir du style général (plus de détails peuvent être trouvés
ici ). Dans ce cas, la version Web de Google Play s'ouvrira et le lien vers l'application après l'installation ne sera pas transmis. De même, le navigateur se comporte si vous copiez OneLink dans la barre d'adresse et suivez le lien. À propos de ce cas, les développeurs Chrome ont écrit dans les notes de publication il y a plusieurs versions. L'essentiel est qu'avec cette approche, la redirection Google Play ne fonctionne pas lorsque l'application n'est pas installée et que l'utilisateur reste sur le Web. OneLink n'a pas réussi à surmonter ce problème, nous nous sommes donc tournés vers DynamicLink.
Dynamiclink
L'intégration profonde des services Google Play dans le système leur permet d'optimiser la disponibilité de l'application cible sur l'appareil. Il s'agit d'un écosystème plutôt fermé, il n'a donc pas été possible de bien comprendre les principes de son travail.Toutefois, tout indique que Chrome ouvre une activité avec progrès, détenue par Google Play Services, qui détermine comment y faire face avec un lien profond. Après cela, une redirection se produit soit sur Google Play, soit dans l'application. Dans ce cas, le lien profond entre ensuite dans l'application via Intent, c'est-à-dire sans béquilles de bibliothèque supplémentaires.
Subjectivement, cette approche ne fonctionne pas plus rapidement que OneLink, mais elle fonctionne lorsque vous ouvrez des liens dans les onglets personnalisés de Chrome, ce qui est un avantage important car de nombreuses applications les utilisent.
Entre autres choses, Firebase vous permet de voir comment fonctionne le lien et où l'utilisateur sera redirigé sur chaque plate-forme dans chaque cas. Cela ressemble à ceci:
Conclusions
En résumé, j'ai préparé un tableau croisé dynamique. Je pense que OneLink peut être compris comme n'importe quelle solution compétitive, car seul DynamicLink a accès aux services Google Play, en conséquence, il ne devrait pas y avoir de différences significatives entre les autres services.
Le tableau montre que dans l'implémentation avec DynamicLinks tout fonctionne sans béquilles et dans tous les cas intéressant pour nous.
Liens utiles:
Merci de votre attention! Je serai heureux de discuter dans les commentaires de la manière dont vous avez résolu des problèmes similaires.