Récupérer les onboardings dans le SDK Android

À partir du SDK v4, vous pouvez créer des flows comme alternative plus puissante aux onboardings. Contrairement aux onboardings qui s’exécutent dans une WebView, les flows s’affichent nativement sur l’appareil — offrant des animations plus fluides, un rendu cohérent avec Android, des temps de chargement plus rapides et aucune dépendance au runtime WebView. Consultez Récupérer les flows et paywalls et Afficher les flows et paywalls pour démarrer.

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 Android. 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 :

  1. Vous avez installé le SDK Adapty Android version 3.8.0 ou supérieure.
  2. Vous avez créé un onboarding.
  3. Vous avez ajouté l’onboarding à un placement.

Récupérer un onboarding

Lorsque vous créez un onboarding avec notre builder no-code, il est stocké sous forme de conteneur avec une configuration que votre application doit récupérer et afficher. Ce conteneur gère l’intégralité de l’expérience : quel contenu s’affiche, comment il est présenté et comment les interactions utilisateur (comme les réponses à un quiz ou les saisies de formulaire) sont traitées. Le conteneur suit également automatiquement les événements analytiques, vous n’avez donc pas besoin d’implémenter un suivi séparé des vues.

Pour de meilleures performances, récupérez la configuration de l’onboarding tôt afin de laisser suffisamment de temps aux images pour se télécharger avant de les afficher aux utilisateurs.

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

Adapty.getOnboarding("YOUR_PLACEMENT_ID") { result ->
    when (result) {
        is AdaptyResult.Success -> {
            val onboarding = result.value
            // the requested onboarding
        }
        is AdaptyResult.Error -> {
            val error = result.error
            // handle the error
        }
    }
}

Paramètres :

ParamètrePrésenceDescription
placementIdrequisL’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

par 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 signifie anglais, pt-br représente le portugais brésilien.

Consultez Localisations et codes de langue pour plus d’informations sur les codes de langue et nos recommandations d’utilisation.

fetchPolicypar 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 obtiennent toujours les données les plus récentes.

Cependant, si vos utilisateurs ont 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 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 safe de l’utiliser pendant la session pour éviter des requêtes réseau.

Notez que le cache est conservé au 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 et un serveur de secours indépendant si le CDN est inaccessible. Ce système garantit que vous obtenez toujours la dernière version de vos onboardings, même en cas de connexion internet limitée.

loadTimeoutpar défaut : 5 s

Cette valeur limite le délai d’attente de cette méthode. Si le délai est atteint, les données en cache ou le fallback local sont renvoyés.

Notez que dans de rares cas, cette méthode peut dépasser légèrement le délai spécifié dans loadTimeout, car l’opération peut impliquer plusieurs requêtes en interne.

Pour Android : vous pouvez créer un TimeInterval avec des fonctions d’extension (comme 5.seconds, où .seconds provient de import com.adapty.utils.seconds), ou TimeInterval.seconds(5). Pour ne pas définir de limite, utilisez TimeInterval.INFINITE.

Paramètres de la réponse :

ParamètreDescription
OnboardingUn 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 général, les onboardings sont récupérés presque instantanément, vous n’avez donc pas à vous soucier d’optimiser ce processus. Cependant, si vous avez de nombreuses audiences et onboardings et que vos utilisateurs ont une connexion internet faible, la récupération d’un onboarding peut prendre plus de temps que souhaité. Dans ce cas, vous pouvez afficher un onboarding par défaut pour garantir une expérience utilisateur fluide plutôt que de ne rien afficher.

Pour 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 reste de récupérer l’onboarding avec la méthode getOnboarding, comme décrit dans la section Récupérer un onboarding ci-dessus.

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 de l’application, nécessitant soit des designs rétrocompatibles, soit d’accepter que les anciennes versions puissent s’afficher incorrectement.
  • Aucune personnalisation : affiche uniquement le contenu pour l’audience “All Users”, sans ciblage basé sur le pays, l’attribution ou les attributs personnalisés.

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

Adapty.getOnboardingForDefaultAudience("YOUR_PLACEMENT_ID") { result ->
    when (result) {
        is AdaptyResult.Success -> {
            val onboarding = result.value
            // Handle successful onboarding retrieval
        }
        is AdaptyResult.Error -> {
            val error = result.error
            // Handle error case
        }
    }
}

Paramètres :

ParamètrePrésenceDescription
placementIdrequisL’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

par 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 signifie anglais, pt-br représente le portugais brésilien.

Consultez Localisations et codes de langue pour plus d’informations sur les codes de langue et nos recommandations d’utilisation.

fetchPolicypar 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 obtiennent toujours les données les plus récentes.

Cependant, si vos utilisateurs ont 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 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 safe de l’utiliser pendant la session pour éviter des requêtes réseau.

Notez que le cache est conservé au 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 et un serveur de secours indépendant si le CDN est inaccessible. Ce système garantit que vous obtenez toujours la dernière version de vos onboardings, même en cas de connexion internet limitée.