---
title: "Récupérer les onboardings dans le SDK Capacitor"
description: "Apprenez à récupérer les onboardings dans Adapty pour Capacitor."
---

:::warning
**Les onboardings sont dépréciés dans le SDK v4 et seront supprimés dans une prochaine version.** Ils ne bénéficient plus de correctifs ni d'améliorations. Utilisez plutôt les [flows](capacitor-get-pb-paywalls) : contrairement aux onboardings qui s'exécutent dans une WebView, les flows s'affichent nativement sur l'appareil — avec des animations plus fluides, un rendu natif cohérent, des temps de chargement réduits et aucune dépendance à un runtime WebView. Consultez [Obtenir des flows & paywalls](capacitor-get-pb-paywalls) et [Afficher des flows & paywalls](capacitor-present-paywalls) pour démarrer.
:::

Après avoir [conçu la partie visuelle de votre onboarding](design-onboarding) avec le builder dans l'Adapty Dashboard, vous pouvez l'afficher dans votre application Capacitor. La première étape consiste à récupérer l'onboarding associé au placement ainsi que sa configuration d'affichage, comme décrit ci-dessous.

Avant de commencer, assurez-vous de :

1. Avoir [créé un onboarding](create-onboarding).
2. Avoir ajouté l'onboarding à un [placement](placements).

## Récupérer un onboarding \{#fetch-onboarding\}

Lorsque vous créez un [onboarding](onboardings) 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 toute l'expérience — le contenu affiché, la manière dont il est présenté, et la façon dont 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 des vues séparément.

Pour de meilleures performances, récupérez la configuration de l'onboarding en avance afin de laisser suffisamment de temps aux images pour se télécharger avant l'affichage.

Pour obtenir un onboarding, utilisez la méthode `getOnboarding` :

```typescript showLineNumbers

try {
  const onboarding = await adapty.getOnboarding({ 
    placementId: 'YOUR_PLACEMENT_ID', 
    locale: 'en',
    params: {
      fetchPolicy: 'reload_revalidating_cache_data', // Load from server, fallback to cache
      loadTimeoutMs: 5000 // 5 second timeout
    }
  });
  console.log('Onboarding fetched successfully');
} catch (error) {
  console.error('Failed to fetch onboarding:', error);
}
```

Appelez ensuite la méthode `createOnboardingView` pour créer une instance de vue.

:::warning
Le résultat de la méthode `createOnboardingView` ne peut être utilisé qu'une seule fois. Si vous avez besoin de l'utiliser à nouveau, appelez à nouveau la méthode `createOnboardingView`.
:::

```typescript showLineNumbers

if (onboarding.hasViewConfiguration) {
  try {
    const view = await createOnboardingView(onboarding);
    console.log('Onboarding view created successfully');
  } catch (error) {
    console.error('Failed to create onboarding view:', error);
  }
} else {
  // Use your custom logic
  console.log('Onboarding does not have view configuration');
}
```

Paramètres :

| Paramètre | Présence | Description |
|---------|--------|-----------|
| **placementId** | requis | L'identifiant du [Placement](placements) souhaité. C'est la valeur que vous avez indiquée lors de la création d'un placement dans l'Adapty Dashboard. |
| **locale** | <p>optionnel</p><p>par défaut : `en`</p> | <p>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.</p><p></p><p>Exemple : `en` signifie anglais, `pt-br` représente le portugais brésilien.</p><p>Consultez [Localisations et codes de langue](localizations-and-locale-codes) pour plus d'informations sur les codes de langue et nos recommandations d'utilisation.</p> |
| **params.fetchPolicy** | <p>optionnel</p><p>par défaut : `'reload_revalidating_cache_data'`</p> | <p>Par défaut, le SDK essaie de charger les données depuis le serveur et retourne les données en cache en cas d'échec. Nous recommandons cette option car elle garantit que vos utilisateurs reçoivent toujours les données les plus récentes.</p><p></p><p>Cependant, si vous pensez que vos utilisateurs ont une connexion internet instable, envisagez d'utiliser `'return_cache_data_else_load'` pour retourner les données en cache si elles existent. Dans ce cas, les utilisateurs pourraient ne pas obtenir 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 pour éviter les requêtes réseau.</p><p></p><p>Notez que le cache est conservé lors du redémarrage de l'application et n'est effacé que lors de la désinstallation ou via un nettoyage manuel.</p> |
| **params.loadTimeoutMs** | <p>optionnel</p><p>par défaut : 5000 ms</p> | <p>Cette valeur limite le délai d'attente (en millisecondes) pour cette méthode. Si le délai est dépassé, les données en cache ou le fallback local seront retournés.</p><p>Notez que dans de rares cas, cette méthode peut expirer légèrement après le délai spécifié dans `loadTimeoutMs`, car l'opération peut impliquer différentes requêtes en arrière-plan.</p> |

Paramètres de réponse :

| Paramètre | Description |
|:----------|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **onboarding** | Un objet [`AdaptyOnboarding`](https://capacitor.adapty.io/interfaces/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 d'audience par défaut \{#speed-up-onboarding-fetching-with-default-audience-onboarding\}

En général, 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 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 bonne expérience utilisateur plutôt que de n'afficher aucun onboarding.

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 cependant 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](#fetch-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 problèmes 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 s'affichent incorrectement.
- **Pas de personnalisation** : affiche uniquement le contenu pour l'audience "All Users", sans ciblage basé sur le pays, l'attribution ou des attributs personnalisés.

Si la rapidité de récupération justifie ces inconvénients pour votre cas d'usage, utilisez `getOnboardingForDefaultAudience` comme indiqué ci-dessous. Sinon, utilisez `getOnboarding` comme décrit [ci-dessus](#fetch-onboarding).
:::

```typescript showLineNumbers

try {
  const onboarding = await adapty.getOnboardingForDefaultAudience({ 
    placementId: 'YOUR_PLACEMENT_ID', 
    locale: 'en',
    params: {
      fetchPolicy: 'reload_revalidating_cache_data' // Load from server, fallback to cache
    }
  });
  console.log('Default audience onboarding fetched successfully');
} catch (error) {
  console.error('Failed to fetch default audience onboarding:', error);
}
```

Paramètres :

| Paramètre | Présence | Description |
|---------|--------|-----------|
| **placementId** | requis | L'identifiant du [Placement](placements) souhaité. C'est la valeur que vous avez indiquée lors de la création d'un placement dans l'Adapty Dashboard. |
| **locale** | <p>optionnel</p><p>par défaut : `en`</p> | <p>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.</p><p></p><p>Exemple : `en` signifie anglais, `pt-br` représente le portugais brésilien.</p><p>Consultez [Localisations et codes de langue](localizations-and-locale-codes) pour plus d'informations sur les codes de langue et nos recommandations d'utilisation.</p> |
| **params.fetchPolicy** | <p>optionnel</p><p>par défaut : `'reload_revalidating_cache_data'`</p> | <p>Par défaut, le SDK essaie de charger les données depuis le serveur et retourne les données en cache en cas d'échec. Nous recommandons cette option car elle garantit que vos utilisateurs reçoivent toujours les données les plus récentes.</p><p></p><p>Cependant, si vous pensez que vos utilisateurs ont une connexion internet instable, envisagez d'utiliser `'return_cache_data_else_load'` pour retourner les données en cache si elles existent. Dans ce cas, les utilisateurs pourraient ne pas obtenir 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 pour éviter les requêtes réseau.</p><p></p><p>Notez que le cache est conservé lors du redémarrage de l'application et n'est effacé que lors de la désinstallation ou via un nettoyage manuel.</p> |