Après l'installation, exécutez la skill dans votre projet :
/adapty-sdk-integration
Les onboardings sont dépréciés dans le SDK v4 et seront supprimés dans une prochaine version. Ils ne reçoivent plus de correctifs ni d’améliorations. Utilisez les flows à la place : 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 natif cohérent, des temps de chargement plus rapides et aucune dépendance au runtime WebView. Consultez Récupérer les flows & paywalls et Afficher les flows & paywalls pour commencer.
Les onboardings configurés avec le builder génèrent des événements auxquels votre application peut réagir. La manière de gérer ces événements dépend de l’approche de présentation utilisée :
Présentation modale : nécessite la mise en place de gestionnaires d’événements qui traitent les événements pour toutes les vues d’onboarding
Composant React : gère les événements via des paramètres de callback inline directement dans le widget
Pour contrôler ou surveiller les processus se déroulant sur l’écran d’onboarding dans votre application mobile, implémentez des gestionnaires d’événements :
Pour le composant React, vous gérez les événements via des props de gestionnaire d’événements individuels dans le composant AdaptyOnboardingView :
Pour la présentation modale, implémentez la méthode de gestionnaires d’événements.
Appeler setEventHandlers plusieurs fois écrasera les gestionnaires que vous avez définis, remplaçant à la fois les gestionnaires par défaut et ceux précédemment configurés pour ces événements spécifiques.
Les sections suivantes décrivent les différents types d’événements que vous pouvez gérer, quelle que soit l’approche de présentation utilisée.
Gérer les actions personnalisées
Dans le builder, vous pouvez ajouter une action custom à un bouton et lui attribuer un ID.
Vous pouvez ensuite utiliser cet ID dans votre code et le gérer comme une action personnalisée. Par exemple, si un utilisateur appuie sur un bouton personnalisé, comme Login ou Allow notifications, le gestionnaire d’événements sera déclenché avec le paramètre actionId correspondant à l’Action ID défini dans le builder. Vous pouvez créer vos propres IDs, comme “allowNotifications”.
Gérez cet événement pour ouvrir un paywall à l’intérieur de l’onboarding. Si vous souhaitez ouvrir un paywall après sa fermeture, il existe une méthode plus simple : gérez l’action de fermeture et ouvrez un paywall sans vous appuyer sur les données de l’événement.
La façon la plus fluide de travailler avec les paywalls dans les onboardings est de faire correspondre l’ID d’action à un ID de placement de paywall.
Notez que, sur iOS, une seule vue (paywall ou onboarding) peut être affichée à l’écran à la fois. Si vous affichez un paywall par-dessus un onboarding, vous ne pouvez pas contrôler l’onboarding en arrière-plan par programmation. Tenter de fermer l’onboarding fermera le paywall à la place, laissant l’onboarding visible. Pour éviter cela, fermez toujours la vue d’onboarding avant de présenter le paywall.
Notez que, sur iOS, une seule vue (paywall ou onboarding) peut être affichée à l’écran à la fois. Si vous affichez un paywall par-dessus un onboarding, vous ne pouvez pas contrôler l’onboarding en arrière-plan par programmation. Tenter de fermer l’onboarding fermera le paywall à la place, laissant l’onboarding visible. Pour éviter cela, fermez toujours la vue d’onboarding avant de présenter le paywall.
Lorsqu’un écran est terminé. Inclut un elementId optionnel (identifiant de l’élément terminé) et une reply optionnelle (réponse de l’utilisateur). Déclenché lorsque les utilisateurs effectuent une action pour quitter l’écran.
secondScreenPresented
Lorsque le deuxième écran est affiché
userEmailCollected
Déclenché lorsque l’adresse e-mail de l’utilisateur est collectée via le champ de saisie