Mobile SDK Diagrammes d’événements

Cette page comporte des diagrammes et des explications sur des événements qui se produisent habituellement pendant une interaction de chat.

L’application devient active

Ce diagramme de séquence illustre le flux lorsque l'application mobile devient active, prépare le chat, gère les informations du visiteur et du client, et communique avec les Services backend. Si des erreurs se produisent, elles sont traitées et consignées dans des fichiers journaux.

Ouvrir le diagramme dans une nouvelle fenêtre

État initial :

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

  • L'application mobile passe au premier plan.

Préparation de la conversation :

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

  • Si l'état du chat n'est pas initial ou hors ligne, un IllegalChatStateError est renvoyé.

  • Sinon, le SDK définit l’état du chat sur preparing et notifie l’interface utilisateur avec onChatUpdated().

Configuration du canal :

  • Le SDK demande la configuration des canaux depuis le backend avec getChannelConfiguration()).

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

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

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

Traitement des visiteurs et des clients :

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

  • S’il y a une erreur de serveur, l’état du chat est réinitialisé sur initialize.

  • Sinon, le traitement des visiteurs et des clients est réussi.

État de préparation de la Conversation :

  • L’état initial du chat 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 le backend.

L'application passe en Arrière-plan

Ce diagramme de séquence représente le flux lorsque l'application mobile passe en arrière-plan, gère le suivi des vues de Page et communique avec les Services du backend. Si des erreurs se produisent, elles sont traitées en conséquence. 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 basculez vers une autre application. L'application de messagerie est désormais en arrière-plan. Elle est toujours en cours d’exécution, mais vous ne l’utilisez pas activement. Cela se produit lorsque vous réduisez une application, que vous basculez vers une autre application ou que vous verrouillez votre téléphone. L’application est toujours là, mais elle n’est plus au premier plan.

Ouvrir le diagramme dans une nouvelle fenêtre

L'application passe en Arrière-plan :

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

  • L’interface utilisateur indique au SDK que la vue de la page n’utilise plus pageViewEnded.

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

    • Si une erreur de serveur se produit, elle est traitée.

    • Sinon, l’événement est en succès.

Déconnexion et gestion de l'état :

  • L’interface utilisateur notifie la déconnexion avec disconnect().

  • Selon l'état actuel :

    • S’il est en cours de préparation, le SDK définit l’état sur initial.

    • S’il a déjà été préparé, le SDK déconnecte le socket et définit l’état sur prepared.

Voir 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 backend. Il affiche l'événement analytique lorsqu'un utilisateur consulte une page, suit les détails de la visite et communique avec les services back-end. Si des erreurs se produisent, elles sont traitées en conséquence.

Ouvrir le diagramme dans une nouvelle fenêtre

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

Afficher l’Événement de page :

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

  • Le mode chat est vérifié :

    • S’il n’est pas préparé, un illegalChatStateError est renvoyé.

    • Sinon, les détails de la visite sont vérifiés pour déterminer leur expiration.

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

      • S’ils sont valides, le SDK ajuste la date d’expiration actuelle.

    • Si la dernière Page vu n’a pas été envoyée, le SDK termine la vue de page.

    • Le titre, l'URI et l'estampille temporelle de la dernière Page vue actuelle sont stockés.

    • En cas d’échec, comme une erreur de serveur, il est traité.

Interactions avec le backend :

  • Le SDK communique avec les services de backend :

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

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

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

Chat ouvert

Ce diagramme de séquence capture le flux lorsque l’utilisateur ouvre le chat, traite OAuth et établit une connexion avec les services de backend. Si des erreurs se produisent, elles sont traitées en conséquence.

Ouvrir le diagramme dans une nouvelle fenêtre

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

Ouverture de la conversation :

  • L'utilisateur de l'application ouvre le chat, et l'interface utilisateur initie une connexion avec connect().

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

    • Si une connexion est en cours, le SDK établit une connexion WebSocket.

    • Si en phase initiale ou en cours de préparation, IllegalChatStateError est renvoyé.

    • Si préparé, le mode chat est vérifié :

      • Si le chat en direct et le statut du chat en direct sont « hors ligne », l’état du chat est défini sur offline.

      • Dans le cas contraire, la connexion WebSocket est établie.

      • Le traitement de OAuth varie selon que l’état est activé ou désactivé.

OAuth Traitement :

  • Si OAuth est activé :

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

    • Si une erreur de serveur se produit, elle est traitée.

    • Sinon, CustomerReconnectedEvent est reçu.

  • Si OAuth est désactivé :

    • Le SDK réalise l’autorisation avec authorizeCustomerEventData(authorizationCode:codeVerifier:).

    • S'il y a une erreur de serveur, elle est gérée.

    • Sinon, CustomerAuthorizedEvent est reçu, et le jeton d’accès, ainsi que l’identité du client sont stockés.

État connecté du chat :

Fil unique

Ce diagramme de séquence capture le flux lorsqu’un utilisateur interagit avec un chat à 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., traite la récupération des fils et communique avec les services de backend. Si des erreurs se produisent, elles sont traitées en conséquence.

Ouvrir le diagramme dans une nouvelle fenêtre

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

Récupération du fil :

  • Le SDK charge l’ID de fil depuis le stockage local.

  • Si un ID de fil provenant d’une plateforme externe est stocké localement, le SDK récupère le fil de messagerie en utilisant RecoverMessagingThreadEvent(threadId:).

  • Si aucun UUID n’est disponible, le SDK tente d’opérer 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 chat 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 chat est défini sur Prêt.

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

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

Interaction de conversation :

  • L’interface utilisateur affiche la fenêtre de chat pour permettre à l’utilisateur de communiquer avec un agent.

Multi-fil

Ce diagramme de séquence capture le flux lorsqu’un utilisateur interagit avec un chat à fils multiplesClosed 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., traite la récupération des fils et communique avec les services de backend. Si des erreurs se produisent, elles sont traitées en conséquence.

Ouvrir le diagramme dans une nouvelle fenêtre

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

Récupération de la liste de fils:

  • Le SDK extrait la liste de fils du backend en utilisant FetchThreadListEvent.

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

  • Sinon, la liste de fils est extraites.

Traitement des fils :

  • Si les fils existent :

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

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

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

  • Si aucun fil n’existe :

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

Créer ou ouvrir des fils :

  • En cas de création de fil :

    • L’utilisateur est à l’origine de la création de fil.

  • En cas d’ouverture du fil existant :

    • L’utilisateur sélectionne un fil.

    • L’interface utilisateur ouvre le fil avec openThread(thread:).

    • Le fil est récupéré depuis le backend.

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

    • Sinon, le fil est récupéré et l’état est défini sur ready.

Interaction de conversation :

  • L’utilisateur amorce un chat avec un agent.

Chat en direct

Ce diagramme de séquence présente le flux de backend d’une interaction de chat en direct. Le chat en direct désigne l’option de chat numérique en temps réel, tandis que la messagerie instantanée désigne l’option de messagerie asynchrone, qui est semblable aux messages privés ou directs.

Ouvrir le diagramme dans une nouvelle fenêtre

Créer un fil

Ce diagramme de séquence capture le flux lorsqu’un utilisateur crée un fil de chat, traite la création de fils et communique avec le SDK. Si des erreurs se produisent, elles sont traitées en conséquence.

Ouvrir le diagramme dans une nouvelle fenêtre

Détails de l’utilisateur et pré-chat :

  • Si le nom du client n’est pas fourni, l’interface utilisateur affiche la bue de formulaire de détails des utilisateurs.

  • Si les informations de préparation du chat sont disponibles, l’interface utilisateur affiche une vue de formulaire de préparation au chat.

Création des fils :

  • L’utilisateur commence une conversation.

  • L’interface utilisateur crée le fil en utilisant createThread(customFields:).

  • Si le mode de chat n’est pas multi-fil et si le fil existe déjà :

    • unsupportedChannelConfigError est renvoyé.

    • Une alerte d'erreur s'affiche.

  • Sinon :

    • 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().

Chat avec un agent

Ce diagramme de séquence capture le flux lorsqu’un utilisateur interagit avec un agent au moyen du chat, traite les messages de bienvenue et communique avec les services de backend. Si des erreurs se produisent, elles sont traitées en conséquence.

Ouvrir le diagramme dans une nouvelle fenêtre

Initialisation de la conversation :

  • L’utilisateur envoie un message utilisant sendMessage(message:).

  • Si un message de bienvenue est disponible :

    • Le SDK envoie un message de bienvenue sortant avec SendOutboundMessageEvent(welcomeMessage:).

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

    • Sinon, MessageCreatedEvent est reçu et l’interface utilisateur est mise à jour.

  • Le SDK envoie le message de l’utilisateur en utilisant sendMessageEvent.

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

    • Sinon, MessageCreatedEvent est reçu et l’interface utilisateur est mise à jour.

Terminer contact

Ce diagramme de séquence capture le flux lorsque l’utilisateur met fin au chat, traite la clôture de la conversation et communique avec les services de backend. Si des erreurs se produisent, elles sont traitées en conséquence.

Ouvrir le diagramme dans une nouvelle fenêtre

Fin de la conversation :

  • L’utilisateur appuie sur terminer la conversation.

  • L’interface utilisateur demande au SDK de mettre fin à la conversation avec endConversation().

  • Le backend reçoit EndConversationEvent.

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

    • Sinon, l’état du dossier est modifié, et l’état du fil est défini sur closed.

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

Vue de l’expérience terminer contact :

  • L’interface utilisateur affiche la vue Fin de contact.

Traiter les Événements Large

L’une des limitations de la passerelle d’API AWS est qu’elle ne peut pas envoyer plus de 128 Ko par message. Pour envoyer des événements plus volumineux du serveur au client :

  • Sur le serveur, chargez les événements plus volumineux dans un compartiment S3 disponible publiquement.

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

Ouvrir le diagramme dans une nouvelle fenêtre