Aller au contenu principal
DocumentationFAQ du SDK mobile

FAQ et dépannage du SDK

Trouvez les versions minimales, les règles d'authentification, les limites de cycle de vie et les premiers contrôles pour les erreurs d'intégration courantes.

Sur cette page

Vous pouvez déterminer si un problème vient de la configuration de l'hôte, de l'identité, du cycle natif ou d'un état réseau récupérable.

Questions d'intégration courantes

  • Le widget web peut-il être anonyme ? Oui. Les intégrations web peuvent commencer anonymement puis joindre une identité signée courte après la connexion de l'hôte. Les intégrations natives exigent un token d'identité client signé avant les opérations réseau.
  • Le mobile rend-il le widget web dans une WebView ? Non. iOS, Android, Flutter, React Native, NativeScript et Capacitor présentent le widget et le transport natifs partagés. Capacitor peut toutefois héberger le reste de l'interface dans sa WebView normale.
  • Quelles versions minimales sont prises en charge ? iOS 15.1, Android API 26, Flutter 3.22.3 ou ultérieur avec Dart 3.4 à 3.x, React Native 0.76 à 0.87 avec New Architecture, NativeScript 8.9 à 9.x et Capacitor 6 à 8.
  • Puis-je garder plusieurs conversations actives dans un client ? Non. Un accountScope possède une session native active et une outbox durable. Terminez ou réinitialisez la session actuelle avant d'en démarrer une autre et appelez logout avant de changer d'identité.
  • Le SDK public diffuse-t-il les tokens IA ? Non. L'API publique renvoie des snapshots typés et des résultats wait-for-assistant. Ne construisez pas une interface token par token à partir des événements de polling.
  • Push et voice sont-ils inclus dans le package de base ? Non. Ce sont des capacités natives optionnelles avec leur propre configuration de fournisseur et leurs permissions.

Associer les erreurs à l'action sûre suivante

Lisez le code d'erreur typé et conservez l'identité de la requête. Les états network, reconnecting et rate-limited peuvent être réessayés selon les règles du SDK. session-expired exige un nouveau token pour le même compte. field-invalid, payload-too-large et message-rejected exigent une correction de l'hôte ou du client. idempotency-conflict signifie que l'hôte doit examiner la clé originale plutôt que d'envoyer un nouveau message.

Limite d'erreur de l'hôte
import { DobroDeskSdkError } from "@dobrodesk/mobile-protocol";

try {
  await client.sendMessage(text, idempotencyKey);
} catch (error) {
  // These host functions render controls; they do not retry inside catch.
  if (!(error instanceof DobroDeskSdkError)) {
    showRecoverableSdkError(error);
    return;
  }
  switch (error.details.code) {
    case "network":
    case "rate-limited":
      showRetryControl();
      break;
    case "session-expired":
      showRefreshAndRetryControlForTheSameAccount();
      break;
    case "field-invalid":
    case "payload-too-large":
    case "message-rejected":
      showCorrection(error.details);
      break;
    case "idempotency-conflict":
      investigateOriginalRequest(error.details);
      break;
    default:
      showRecoverableSdkError(error);
  }
}

Vérifier l'hôte avant d'ouvrir une demande de support

  1. Confirmez que apiOrigin est un origin HTTPS sans chemin, query ni credential et que integrationId est l'intégration DobroDesk visée.
  2. Confirmez que le token signé a été émis par le backend de l'hôte pour le client actuel et que accountScope est stable et réservé à ce client.
  3. Confirmez que le presenter natif est appelé depuis un écran au premier plan et que l'hôte n'a pas monté un second client pour le même compte.
  4. Confirmez qu'une nouvelle tentative réutilise l'idempotency key d'origine et que logout ou reset n'a pas été appelé alors que l'opération était simplement hors ligne.