Récupérer les onboardings dans le SDK Kotlin Multiplatform

Warning

Les onboardings sont dépréciés à partir du SDK Adapty v4. Créez des flows à la place : contrairement aux onboardings, qui s’exécutent dans une WebView, les flows s’affichent nativement sur l’appareil — animations plus fluides, aspect natif cohérent, temps de chargement réduits et aucune dépendance à l’environnement WebView.

Après avoir conçu la partie visuelle de votre onboarding avec le builder dans l’Adapty Dashboard, vous pouvez l’afficher dans votre application Kotlin Multiplatform. La première étape consiste à récupérer l’onboarding associé au placement et sa configuration d’affichage, comme décrit ci-dessous.

Avant de commencer, assurez-vous que :

Vous avez installé le SDK Adapty Kotlin Multiplatform version 3.15.0 ou supérieure.
Vous avez créé un onboarding.
Vous avez ajouté l’onboarding à un placement.

Récupérer l’onboarding

Quand vous créez un onboarding avec notre éditeur no-code, il est stocké sous forme de conteneur contenant la configuration que votre application doit récupérer et afficher. Ce conteneur gère l’intégralité de l’expérience : le contenu affiché, la façon dont il est présenté, et le traitement des interactions utilisateur (réponses à un quiz, saisies de formulaires, etc.). Il suit également les événements analytics automatiquement, vous n’avez donc pas besoin d’implémenter un suivi des vues séparé.

Pour de meilleures performances, récupérez la configuration de l’onboarding le plus tôt possible afin que les images aient le temps de se télécharger avant d’être affichées aux utilisateurs.

Pour récupérer un onboarding, utilisez la méthode getOnboarding :


Adapty.getOnboarding(
    placementId = "YOUR_PLACEMENT_ID",
    locale = "en",
    fetchPolicy = AdaptyPaywallFetchPolicy.Default,
    loadTimeout = 5.seconds
).onSuccess { onboarding ->
    // the requested onboarding
}.onError { error ->
    // handle the error
}

Paramètres :

Paramètre	Présence	Description
placementId	obligatoire	L’identifiant du Placement souhaité. Il s’agit de la valeur que vous avez indiquée lors de la création d’un placement dans l’Adapty Dashboard.
locale	optionnel défaut : `en`	L’identifiant de la localisation de l’onboarding. Ce paramètre doit être un code de langue composé d’un ou deux sous-tags séparés par le caractère moins (-). Le premier sous-tag correspond à la langue, le second à la région. Exemple : `en` désigne l’anglais, `pt-br` représente le portugais brésilien.
fetchPolicy	défaut : `.reloadRevalidatingCacheData`	Par défaut, le SDK tente de charger les données depuis le serveur et renvoie les données en cache en cas d’échec. Nous recommandons cette option, car elle garantit que vos utilisateurs disposent toujours des données les plus récentes. Toutefois, si vous pensez que vos utilisateurs ont une connexion internet instable, envisagez d’utiliser `.returnCacheDataElseLoad` pour renvoyer les données en cache lorsqu’elles existent. Dans ce cas, les utilisateurs n’auront peut-être pas les toutes dernières données, mais les temps de chargement seront plus rapides, quelle que soit la qualité de leur connexion. Le cache est mis à jour régulièrement, il est donc sûr de l’utiliser pendant la session afin d’éviter les requêtes réseau. Le cache reste intact après un redémarrage de l’application et n’est effacé que lors d’une réinstallation ou d’un nettoyage manuel. Le SDK Adapty stocke les onboardings localement sur deux niveaux : le cache mis à jour régulièrement décrit ci-dessus et les onboardings de secours. Nous utilisons également un CDN pour récupérer les onboardings plus rapidement, ainsi qu’un serveur de secours indépendant en cas d’indisponibilité du CDN. Ce système est conçu pour vous garantir toujours la dernière version de vos onboardings, tout en assurant la fiabilité même lorsque la connexion internet est limitée.
loadTimeout	défaut : 5 sec	Cette valeur limite le délai d’attente de cette méthode. Si le délai est dépassé, les données en cache ou le fallback local sont renvoyés. Notez que dans de rares cas, cette méthode peut expirer légèrement après le délai indiqué dans `loadTimeout`, car l’opération peut impliquer plusieurs requêtes en coulisses.

Paramètres de réponse

Paramètre	Description
Onboarding	Un objet `AdaptyOnboarding` contenant : l’identifiant et la configuration de l’onboarding, le Remote Config, et plusieurs autres propriétés.

Accélérer la récupération de l’onboarding avec l’onboarding de l’audience par défaut

En règle générale, les onboardings sont récupérés presque instantanément, vous n’avez donc pas à vous soucier d’accélérer ce processus. Cependant, si vous avez de nombreuses audiences et onboardings, et que vos utilisateurs disposent d’une connexion internet faible, la récupération d’un onboarding peut prendre plus de temps que souhaité. Dans ces situations, vous pourriez vouloir afficher un onboarding par défaut afin de garantir une expérience utilisateur fluide plutôt que de ne rien afficher.

Pour remédier à cela, vous pouvez utiliser la méthode getOnboardingForDefaultAudience, qui récupère l’onboarding du placement spécifié pour l’audience All Users. Il est toutefois essentiel de comprendre que l’approche recommandée est de récupérer l’onboarding via la méthode getOnboarding, comme décrit dans la section Récupérer l’onboarding ci-dessus.

Warning

Préférez getOnboarding à getOnboardingForDefaultAudience, car cette dernière présente des limitations importantes :

Problèmes de compatibilité : Peut créer des difficultés lors de la prise en charge de plusieurs versions d’application, nécessitant soit des designs rétrocompatibles, soit d’accepter que les anciennes versions s’affichent incorrectement.
Pas de personnalisation : Affiche uniquement le contenu pour l’audience « Tous les utilisateurs », supprimant le ciblage basé sur le pays, l’attribution ou les attributs personnalisés.

Si une récupération plus rapide compense ces inconvénients pour votre cas d’usage, utilisez getOnboardingForDefaultAudience comme indiqué ci-dessous. Sinon, utilisez getOnboarding comme décrit ci-dessus.


Adapty.getOnboardingForDefaultAudience(
    placementId = "YOUR_PLACEMENT_ID",
    locale = "en",
    fetchPolicy = AdaptyPaywallFetchPolicy.Default,
).onSuccess { paywall ->
    // the requested paywall
}.onError { error ->
    // handle the error
}

Paramètres :

Paramètre Présence Description

placementId requis L’identifiant du Placement souhaité. Il s’agit de la valeur que vous avez indiquée lors de la création d’un placement dans l’Adapty Dashboard.

Paramètre	Présence	Description
placementId	requis	L’identifiant du Placement souhaité. Il s’agit de la valeur que vous avez indiquée lors de la création d’un placement dans l’Adapty Dashboard.
locale	optionnel défaut : `en`	L’identifiant de la localisation de l’onboarding. Ce paramètre doit être un code de langue composé d’un ou deux sous-tags séparés par le caractère moins (-). Le premier sous-tag correspond à la langue, le second à la région. Exemple : `en` désigne l’anglais, `pt-br` représente le portugais brésilien.
fetchPolicy	défaut : `.reloadRevalidatingCacheData`	Par défaut, le SDK tentera de charger les données depuis le serveur et renverra les données en cache en cas d’échec. Nous recommandons cette option car elle garantit que vos utilisateurs disposent toujours des données les plus récentes. Toutefois, si vous pensez que vos utilisateurs sont soumis à une connexion Internet instable, envisagez d’utiliser `.returnCacheDataElseLoad` pour renvoyer les données en cache si elles existent. Dans ce cas, les utilisateurs pourraient ne pas obtenir les toutes dernières données, mais ils bénéficieront de temps de chargement plus rapides, quelle que soit la qualité de leur connexion. Le cache est mis à jour régulièrement, il est donc sûr de l’utiliser pendant la session pour éviter les requêtes réseau. Notez que le cache reste intact lors du redémarrage de l’application et n’est effacé qu’à la réinstallation de l’application ou lors d’un nettoyage manuel. Le SDK Adapty stocke les onboardings localement en deux couches : le cache mis à jour régulièrement décrit ci-dessus et les onboardings de secours. Nous utilisons également un CDN pour récupérer les onboardings plus rapidement, ainsi qu’un serveur de secours indépendant en cas d’inaccessibilité du CDN. Ce système est conçu pour garantir que vous obtenez toujours la dernière version de vos onboardings, tout en assurant la fiabilité même lorsque la connexion Internet est limitée.

locale

optionnel

défaut : en

L’identifiant de la localisation de l’onboarding. Ce paramètre doit être un code de langue composé d’un ou deux sous-tags séparés par le caractère moins (-). Le premier sous-tag correspond à la langue, le second à la région.
Exemple : en désigne l’anglais, pt-br représente le portugais brésilien.

fetchPolicy

défaut : .reloadRevalidatingCacheData

Par défaut, le SDK tentera de charger les données depuis le serveur et renverra les données en cache en cas d’échec. Nous recommandons cette option car elle garantit que vos utilisateurs disposent toujours des données les plus récentes.

Toutefois, si vous pensez que vos utilisateurs sont soumis à une connexion Internet instable, envisagez d’utiliser .returnCacheDataElseLoad pour renvoyer les données en cache si elles existent. Dans ce cas, les utilisateurs pourraient ne pas obtenir les toutes dernières données, mais ils bénéficieront de temps de chargement plus rapides, quelle que soit la qualité de leur connexion. Le cache est mis à jour régulièrement, il est donc sûr de l’utiliser pendant la session pour éviter les requêtes réseau.

Notez que le cache reste intact lors du redémarrage de l’application et n’est effacé qu’à la réinstallation de l’application ou lors d’un nettoyage manuel.

Le SDK Adapty stocke les onboardings localement en deux couches : le cache mis à jour régulièrement décrit ci-dessus et les onboardings de secours. Nous utilisons également un CDN pour récupérer les onboardings plus rapidement, ainsi qu’un serveur de secours indépendant en cas d’inaccessibilité du CDN. Ce système est conçu pour garantir que vous obtenez toujours la dernière version de vos onboardings, tout en assurant la fiabilité même lorsque la connexion Internet est limitée.