Mobile SDK Diagrammes d’événements

Cette page fournit des diagrammes et des explications sur les événements courants qui se produisent au cours d’une interaction par clavardage.

L’application devient active

Ce diagramme de séquence illustre le flux qui se produit lorsque l’application mobile devient active, prépare le clavardage, traite les informations du visiteur et du client, et communique avec les Services d’arrière-plan. Si des erreurs surviennent, elles sont gérées et consignées de façon appropriée.

Open diagram in new window

État initial :

  • L’état initial du SDK est défini sur initial.

  • L’application mobile passe au premier plan.

Préparation du clavardage :

  • L’utilisateur lance la préparation du clavardage en appelant prepare(brandId:channelId:).

  • Si l’état du clavardage n’est pas initial ou hors ligne, l’erreur IllegalChatStateError est renvoyée.

  • Dans le cas contraire, le SDK attribue la valeur preparing à l’état du clavardage et notifie l’interface utilisateur avec onChatUpdated().

Configuration du canal :

  • Le SDK demande la configuration du canal au serveur dorsal avec getChannelConfiguration().

  • S’il y a une erreur de serveur, un ServerError est renvoyé, et l’état du clavardage est réinitialisé à initialize.

  • Sinon, la configuration du canal est reçue et le SDK crée un ID de destination.

  • Si l’ID du visiteur ou du client est null, il est créé et stocké localement.

Gestion des visiteurs et des Clients :

  • Le SDK appelle createOrUpdateVisitor(visitorId:customerId:deviceToken:) sur le serveur dorsal.

  • En cas d’erreur du serveur, l’état du clavardage est réinitialisé à initialize.

  • Dans le cas contraire, la gestion des visiteurs et des clients est réussie.

État de clavardage préparé :

  • L’état du clavardage est défini sur prepared.

  • L’interface utilisateur est notifiée avec onChatUpdated().

  • Analytics pour les vues de Page sont suivis entre l’application mobile et l’arrière-plan.

L’application passe en Arrière-plan

Ce diagramme de séquence illustre le flux qui se produit lorsque l’application mobile passe en arrière-plan, gère le suivi des vues de Page et communique avec les Services d’arrière-plan. Si des erreurs surviennent, elles sont gérées de façon appropriée. Lorsqu’une application passe en arrière-plan, cela signifie qu’elle n’est plus l’élément principal que vous voyez ou avec lequel vous interagissez sur votre appareil. Imaginez que vous utilisez une Application de messagerie, puis que vous appuyez sur le bouton d’accueil ou que vous passez à une autre Application. L’Application de messagerie est maintenant en arrière-plan. Elle continue de s’exécuter, mais vous ne l’utilisez pas activement. Cela se produit lorsque vous réduisez une Application, passez à une autre Application ou verrouillez votre téléphone. L’Application est toujours présente, mais elle n’est plus au premier plan.

Open diagram in new window

L’application entre en Arrière-plan :

  • L’interface utilisateur affiche une fenêtre indiquant que l’application passe en arrière-plan.

  • L’interface utilisateur informe le SDK que la consultation de la page est terminée avec pageViewEnded.

  • Le serveur dorsal reçoit l’événement pageViewEnded.

    • S’il y a une erreur de serveur, elle est traitée.

    • Dans le cas contraire, l’événement est réussi.

Déconnexion et gestion des états :

  • L’interface utilisateur initie la déconnexion en utilisant disconnect().

  • En fonction de l’état actuel :

    • En cas de préparation, le SDK attribue la valeur initial à l’état.

    • S’il est déjà préparé, le SDK déconnecte le connecteur logiciel et définit l’état à prepared.

Afficher la page

Ce diagramme de séquence représente le flux lorsqu’un utilisateur consulte une page dans l’application mobile, y compris les interactions avec le SDK et les services back-end. Il illustre l’événement d’analyse lorsqu’un utilisateur consulte une page, effectue le suivi des détails de la visite et communique avec les services back-end. Si des erreurs surviennent, elles sont traitées de manière appropriée.

Ouvrir le diagramme dans une nouvelle fenêtre

Référence de l’activation de l’application :

Événement de consultation de page :

  • L’utilisateur consulte une page et l’interface utilisateur notifie le SDK avec viewPage(title:url:).

  • Le mode de clavardage est vérifié :

    • S’il n’est pas préparé, une erreur illegalChatStateError est renvoyée.

    • Dans le cas contraire, l’expiration des détails de la visite est vérifiée.

      • S’ils sont expirés, de nouveaux détails de la visite sont créés (UUID et expiration).

      • S’ils sont valides, le SDK ajuste l’expiration actuelle.

    • Si la dernière page consultée n’a pas été envoyée, le SDK met fin à la consultation de la page.

    • Le titre, l’URI et l’horodatage de la dernière page consultée sont stockés.

    • Tout échec, comme une erreur de serveur, est traité.

Interaction dorsale :

  • Le SDK communique avec les services dorsaux :

    • visitorVisit(date:) est appelé pour enregistrer la visite.

    • pageView(title:uri:timestamp) est appelé pour enregistrer la consultation de la page.

    • S’il y a une erreur de serveur, elle est traitée.

Ouvrir le clavardage

Ce diagramme de séquence illustre le flux lorsqu’un utilisateur ouvre le clavardage, gère les OAuth, et établit une connexion avec les services back-end. Si des erreurs surviennent, elles sont traitées de manière appropriée.

Ouvrir le diagramme dans une nouvelle fenêtre

Référence de l’activation de l’application :

Ouverture du clavardage :

  • L’utilisateur de l’application ouvre le clavardage, et l’interface utilisateur lance une connexion avec connect().

  • L’état du clavardage est vérifié :

    • En cas de connexion, le SDK établit une connexion WebSocket.

    • S’il est initial ou en cours de préparation, une erreur IllegalChatStateError est renvoyée.

    • S’il est préparé, le mode clavardage est vérifié :

      • S’il s’agit d’un clavardage en direct et que l’état du clavardage en direct est hors ligne, l’état du clavardage est défini sur offline.

      • Sinon, la connexion WebSocket est établie.

      • Le traitement d’OAuth varie selon qu’il est activé ou désactivé.

OAuth Traitement :

  • Si OAuth est activé :

    • Le SDK se reconnecte avec reconnectCustomerEventData(accessToken:).

    • S’il y a une erreur de serveur, elle est traitée.

    • Dans le cas contraire, CustomerReconnectedEvent est reçu.

  • Si OAuth est désactivé :

    • Le SDK autorise avec authorizeCustomerEventData(authorizationCode:codeVerifier:).

    • S’il y a une erreur de serveur, elle est traitée.

    • Dans le cas contraire, CustomerAuthorizedEvent est reçu et le jeton d’accès et l’identité du client sont stockés.

État de clavardage connecté :

Fil unique

Ce diagramme de séquence illustre le flux lorsqu’un utilisateur interagit avec un clavardage à fil uniqueClosed Dans une application à un seul thread, chaque contact dispose d’un seul thread de clavardage qui gère toute interaction qu’il a avec votre organisation., gère la récupération du fil et communique avec les services dorsaux. Si des erreurs surviennent, elles sont gérées de manière appropriée.

Ouvrir le diagramme dans une nouvelle fenêtre

Référence de l’activation de l’application :

Récupération de fil :

  • Le SDK charge l’id du fil à partir du stockage local.

  • Si un id du fil provenant d’une plateforme externe est stocké localement, le SDK récupère le fil de messagerie à l’aide de RecoverMessagingThreadEvent(threadId:).

  • Si aucun UUID n’est disponible, le SDK tente une récupération avec RecoverMessagingThreadEvent(nil).

Vérification de l’existence du fil :

  • Si le fil existe, ThreadRecoveredEvent est reçu.

    • Les états du clavardage et du fil sont définis sur ready.

    • L’interface utilisateur est notifiée avec onThreadUpdated().

  • Si le fil n’existe pas, ThreadRecoverFailedEvent est reçu.

    • L’état du clavardage est défini sur Prêt.

    • L’interface utilisateur est notifiée avec onChatUpdated().

    • Une note indique qu’aucune récupération de fil n’est nécessaire.

Interaction par clavardage :

  • L’interface utilisateur affiche la fenêtre de clavardage permettant à l’utilisateur d’interagir avec un agent.

Multi-fils

Ce diagramme de séquence illustre le flux lorsqu’un utilisateur interagit avec un clavardage multi-filsClosed Dans une application multithread, les contacts peuvent créer autant de fils de discussion qu’ils le souhaitent pour discuter de nouveaux sujets. Ces fils peuvent être actifs en même temps., gère la récupération du fil et communique avec les services dorsaux. Si des erreurs surviennent, elles sont gérées de manière appropriée.

Ouvrir le diagramme dans une nouvelle fenêtre

Référence de l’activation de l’application :

Récupération de la liste des fils :

  • Le SDK récupère la liste des fils du serveur dorsal avec FetchThreadListEvent.

  • S’il y a une erreur de serveur, elle est traitée.

  • Dans le cas contraire, la liste des fils est récupérée.

Gestion des fils :

  • Si des fils existent :

    • Le SDK définit l’état de chaque fil sur received et charge les derniers messages.

    • Les métadonnées du fil sont chargées et l’état est défini sur loaded.

    • L’état du clavardage est défini sur ready et l’interface utilisateur est notifiée.

  • Si aucun fil n’existe :

    • L’état du clavardage est défini sur ready et l’interface utilisateur est notifiée.

Créer ou ouvrir des fils :

  • Pour créer un nouveau fil :

    • L’utilisateur lance la création du fil.

  • Pour ouvrir un fil existant :

    • L’utilisateur sélectionne un fil.

    • L’interface utilisateur ouvre le fil à l’aide de openThread(thread:).

    • Le fil est récupéré sur le serveur dorsal.

    • S’il y a une erreur de serveur, elle est traitée.

    • Dans le cas contraire, le fil est récupéré et l’état est définit sur ready.

Interaction par clavardage :

  • L’utilisateur entame un clavardage avec un agent.

Clavardage en direct

Ce diagramme de séquence illustre le flux dorsal d’une interaction par clavardage en direct. Le clavardage en direct est l’option de clavardage numérique en temps réel, tandis que la messagerie de clavardage est l’option de messagerie asynchrone, semblable aux messages privés ou aux messages directs.

Ouvrir le diagramme dans une nouvelle fenêtre

Créer un fil

Ce diagramme de séquence illustre le flux lorsqu’un utilisateur crée un nouveau fil de clavardage, gère la création du fil et communique avec le SDK. Si des erreurs surviennent, elles sont gérées de manière appropriée.

Ouvrir le diagramme dans une nouvelle fenêtre

Détails de l’utilisateur et formulaire préalable au clavardage :

  • Si le nom du client n’est pas fourni, l’interface utilisateur affiche un formulaire de détails sur l’utilisateur.

  • Si des informations préalables au clavardage sont disponibles, l’interface utilisateur affiche un formulaire préalable au clavardage.

Création d’un fil :

  • L’utilisateur entame une conversation.

  • L’interface utilisateur initie la création du fil à l’aide de createThread(customFields:).

  • Si le mode de clavardage n’est pas multi-fils et que le fil existe déjà :

    • Une erreur unsupportedChannelConfigError est renvoyée.

    • Une alerte d’erreur s’affiche.

  • Dans le cas contraire :

    • Le SDK crée le fil localement avec un UUID.

    • L’UUID est stocké localement.

    • L’état du fil est défini sur pending.

    • L’interface utilisateur est notifiée avec onThreadUpdated().

Clavardage avec un agent

Ce diagramme de séquence illustre le flux lorsqu’un utilisateur final interagit avec un agent par clavardage, gère les messages d’accueil et communique avec les services backend. Si des erreurs surviennent, elles sont gérées de façon appropriée.

Ouvrir le diagramme dans une nouvelle fenêtre

Initialisation du clavardage :

  • L’utilisateur envoie un message à l’aide de sendMessage(message:).

  • Si un message de bienvenue est disponible :

    • Le SDK envoie un message de bienvenue sortant à l’aide de SendOutboundMessageEvent(welcomeMessage:).

    • S’il y a une erreur de serveur, elle est traitée.

    • Dans le cas contraire, MessageCreatedEvent est reçu et l’interface utilisateur est mise à jour.

  • Le SDK envoie le message de l’utilisateur à l’aide de sendMessageEvent.

    • S’il y a une erreur de serveur, elle est traitée.

    • Dans le cas contraire, MessageCreatedEvent est reçu et l’interface utilisateur est mise à jour.

Terminer contact

Ce diagramme de séquence illustre le flux lorsqu’un utilisateur termine une conversation par clavardage, gère la fermeture de la Conversation et communique avec les services backend. Si des erreurs surviennent, elles sont gérées de façon appropriée.

Ouvrir le diagramme dans une nouvelle fenêtre

Fin du clavardage :

  • L’utilisateur appuie sur Terminer la conversation.

  • L’interface utilisateur notifie au SDK de mettre fin à la conversation à l’aide de endConversation().

  • Le serveur dorsal reçoit EndConversationEvent.

    • S’il y a une erreur de serveur, elle est traitée.

    • Dans le cas contraire, l’état du cas est modifié et l’état du fil est définit sur closed.

    • L’interface utilisateur est notifiée avec onThreadUpdated().

vue de l’expérience Terminer le contact :

  • L’interface utilisateur affiche la vue Terminer le contact.

Traiter les Événements volumineux

Une des limites de AWS API Gateway est qu’elle ne peut envoyer que maximum 128 Ko dans un Message. Pour envoyer des événements plus volumineux du serveur au client :

  • Sur le serveur, téléversez les événements les plus importants dans un compartiment S3 accessible au public.

  • Le client peut ensuite recevoir uniquement l’URL de ce fichier via WebSocket et télécharger le corps réel de l’événement par REST.

Ouvrir le diagramme dans une nouvelle fenêtre