Mobile SDK Diagramas de eventos

Esta página proporciona diagramas y explicaciones de eventos comunes que ocurren durante una interacción de chat.

La aplicación Se Vuelve Activo

Este diagrama de secuencia captura el flujo cuando la aplicación móvil se activa, prepara el chat, gestiona la información del visitante y del cliente, y se comunica con los servicios de backend. Si ocurren errores, estos se manejan y registran de manera adecuada.

Abrir diagrama en nueva ventana

Estado inicial:

  • El estado inicial del SDK se establece en initial.

  • La aplicación móvil pasa a primer plano.

Preparación de conversación:

  • El usuario inicia la preparación del chat llamando a prepare(brandId:channelId:).

  • Si el estado del chat no es inicial o desconectado, se devuelve un IllegalChatStateError.

  • De lo contrario, el SDK define el estado de chat a preparing y notifica a la interfaz de usuario con onChatUpdated().

Configuración de canal:

  • El SDK solicita la configuración del canal al backend con getChannelConfiguration()).

  • Si se produce un error en el servidor, se devuelve un ServerError y el estado del chat se restablece a initialize.

  • De lo contrario, se recibe la configuración del canal y el SDK crea un id de destino.

  • Si el ID de visitante o de cliente es null, se crean y almacenan de forma local.

Manejo de Visitante y Cliente:

  • El SDK llama a createOrUpdateVisitor(visitorId:customerId:deviceToken:) en el backend.

  • Si se produce un error en el servidor, el estado del chat se restablece a initialize.

  • De lo contrario, el manejo de visitantes y clientes se realiza con éxito.

Estado de conversación Preparado:

  • El estado del chat se define a prepared.

  • La interfaz de usuario recibe una notificación con onChatUpdated().

  • Los Analytics para las vistas de página se registran entre la aplicación móvil y el backend.

La aplicación entra en Fondo

Este diagrama de secuencia captura el flujo cuando la aplicación móvil entra en segundo plano, gestiona el seguimiento de vistas de página y se comunica con los servicios de backend. Si se produce algún error, este se maneja de forma adecuada. Cuando una aplicación entra en fondo, significa que ya no es lo principal que usted ve o con lo que interactúa en su dispositivo. Imagine que está usando una aplicación de mensajería y luego presiona el botón de inicio o cambia a otra aplicación. La aplicación de mensajería ahora está en segundo plano. Sigue ejecutándose, pero no la está utilizando activamente. Esto ocurre cuando minimiza una aplicación, Cambia a una aplicación diferente o bloquea su teléfono. La aplicación todavía está ahí, pero ya no está en primer plano.

Abrir diagrama en nueva ventana

Aplicación entrando en Fondo:

  • La interfaz de usuario muestra un cuadro que indica que la aplicación está entrando en fondo.

  • La interfaz de usuario notifica al SDK que la vista de página ha finalizado utilizando pageViewEnded.

  • El backend recibe el evento pageViewEnded.

    • Si se produce un error en el servidor, este se gestiona.

    • De lo contrario, el evento se completa con éxito.

Desconexión y manejo de estado:

  • La interfaz de usuario inicia la desconexión usando disconnect().

  • Dependiendo del estado actual:

    • Si se está preparando, el SDK define el estado a initial.

    • Si ya está preparado, el SDK desconecta el socket y establece el estado a prepared.

Ver Página

Este diagrama de secuencia representa el flujo cuando un usuario visualiza una página en la aplicación móvil, incluidas las interacciones con el SDK y los servicios de backend. Muestra el evento de analítica cuando un usuario visualiza una página, registra los detalles de la visita y se comunica con los servicios de backend. Si ocurre algún error, este se maneja de manera adecuada.

Abrir diagrama en nueva ventana

Referencia de activación de aplicación:

Evento Ver Página:

  • El usuario ve una página, y la interfaz de usuario notifica al SDK con viewPage(title:url:).

  • Se comprueba el modo de chat:

    • Si no está preparado, se devuelve un illegalChatStateError.

    • En caso contrario, se comprueba si los detalles de la visita han caducado.

      • Si han caducado, se crean nuevos detalles de visita (UUID y caducidad).

      • Si son válidos, el SDK ajusta la caducidad actual.

    • Si no se envió la última página Vista, el SDK finaliza la vista de página.

    • Se almacenan el título, el URI y el sello de tiempo de la última página vista actual.

    • Si hay un fallo, como un error en el servidor, se maneja.

Interacción con el backend:

  • El SDK se comunica con los servicios backend:

    • Se llama a visitorVisit(date:) para registrar la visita.

    • Se llama a pageView(title:uri:timestamp) para registrar la vista de la página.

    • Si hay un error en el servidor, se maneja.

Abrir chat

Este diagrama de secuencia captura el flujo cuando un usuario abre el chat, maneja OAuth y establece una conexión con los servicios de backend. Si ocurren errores, se manejan adecuadamente.

Abrir diagrama en nueva ventana

Referencia de activación de aplicación:

Apertura de la conversación:

  • El usuario de la aplicación abre el chat, y la interfaz de usuario inicia una conexión con connect().

  • Se comprueba el estado del chat:

    • Si está conectando, el SDK establece una conexión WebSocket.

    • Si es inicial o en preparación, se devuelve un IllegalChatStateError.

    • Si está preparado, se comprueba el modo de chat:

      • Si el chat en vivo y el estado del chat en vivo es desconectado, el estado del chat se establece en offline.

      • De lo contrario, se establece la conexión WebSocket.

      • El manejo de OAuth depende de si está activado o desactivado.

OAuth Manejo:

  • Si OAuth está activado:

    • El SDK se vuelve a conectar con reconnectCustomerEventData(accessToken:).

    • Si hay un error en el servidor, se maneja.

    • De lo contrario, se recibe CustomerReconnectedEvent.

  • Si OAuth está desactivado:

    • El SDK autoriza con authorizeCustomerEventData(authorizationCode:codeVerifier:).

    • Si hay un error en el servidor, se gestiona.

    • En caso contrario, se recibe el CustomerAuthorizedEvent y se almacenan el token de acceso y la identidad del cliente.

Estado de chat conectado:

Un solo hilo

Este diagrama de secuencia captura el flujo cuando un usuario interactúa con un chat de hilo únicoClosed En una aplicación de un solo hilo, cada contacto tiene un hilo de chat que maneja cualquier interacción que tenga con su organización., gestiona la recuperación de hilos y se comunica con los servicios de backend. Si ocurren errores, se gestionan de manera adecuada.

Abrir diagrama en nueva ventana

Referencia de activación de la aplicación:

Recuperación de hilos:

  • El SDK carga el id de hilo del almacenamiento local.

  • Si cualquier id de hilo de una plataforma externa está almacenado de forma local, el SDK recupera el hilo de mensajería utilizando RecoverMessagingThreadEvent(threadId:).

  • Si no hay ningún UUID disponible, el SDK intenta la recuperación con RecoverMessagingThreadEvent(nil).

Comprobación de existencia del hilo:

  • Si el hilo existe, se recibe ThreadRecoveredEvent.

    • Los estados del chat y del hilo se definen en ready.

    • La interfaz de usuario recibe una notificación con onThreadUpdated().

  • Si el hilo no existe, se recibe ThreadRecoverFailedEvent.

    • El estado del chat pasa a listo.

    • La interfaz de usuario recibe una notificación con onChatUpdated().

    • Una nota indica que no es necesario recuperar el hilo.

Interacción de conversación:

  • La interfaz de usuario muestra la ventana de chat para que el usuario interactúe con un agente.

Múltiples hilos

Este diagrama de secuencia captura el flujo cuando un usuario interactúa con un chat multi-threadedClosed En una aplicación de subprocesos múltiples, los contactos pueden crear tantos subprocesos como deseen para discutir nuevos temas. Estos subprocesos pueden estar activos al mismo tiempo., gestiona la recuperación de hilos y se comunica con los servicios de backend. Si se producen errores, se manejan de manera adecuada.

Abrir diagrama en nueva ventana

Referencia de activación de aplicación:

Recuperación de la lista de hilos:

  • El SDK obtiene la lista de hilos desde el backend usando FetchThreadListEvent.

  • Si hay un error en el servidor, se gestiona.

  • De lo contrario, se obtiene la lista de hilos.

Manejo de hilos:

  • Si existen hilos:

    • El SDK define el estado de cada hilo a received y carga los últimos mensajes.

    • Se cargan los metadatos del hilo y el estado se define a loaded.

    • El estado del chat se establece a ready y se notifica a la interfaz de usuario.

  • Si no existe ningún hilo:

    • El estado del chat se establece a ready y se notifica a la interfaz de usuario.

Crear o abrir Hilos:

  • Si se crea un nuevo hilo:

    • El usuario inicia la creación del hilo.

  • Si se abre un hilo existente:

    • El usuario selecciona un hilo.

    • La interfaz de usuario abre el hilo mediante openThread(thread:).

    • El hilo se recupera desde el backend.

    • Si hay un error en el servidor, se maneja.

    • De lo contrario, el hilo se recupera, y el estado se define a ready.

Interacción de conversación:

  • El usuario participa en un chat con un agente.

Chat en vivo

Este diagrama de secuencia muestra el flujo de back-end de una interacción de Live Chat. Live Chat es la opción de conversación digital en tiempo real, mientras que Chat Messaging es la opción de mensajería asíncrona, similar a los mensajes privados o mensajes directos.

Abrir diagrama en una nueva ventana

Crear hilo

Este diagrama de secuencia captura el flujo que ocurre cuando un usuario crea un nuevo hilo de chat, gestiona la creación del hilo y se comunica con el SDK. Si ocurre algún error, este se gestiona de manera adecuada.

Abrir diagrama en nueva ventana

Detalles del usuario y previos al chat:

  • Si no se proporciona el nombre del cliente, la interfaz de usuario muestra una vista de formulario de detalles del usuario.

  • Si la información previa al chat está disponible, la interfaz muestra un formulario de la información previa al chat.

Creación de hilos:

  • El usuario inicia una conversación.

  • La interfaz de usuario inicia la creación del hilo usando createThread(customFields:).

  • Si el modo de chat no es de múltiples hilos y el hilo ya existe:

    • Se devuelve unsupportedChannelConfigError.

    • Se muestra una alerta de error.

  • De lo contrario:

    • El SDK crea el hilo localmente con un UUID.

    • El UUID se almacena localmente.

    • El estado del hilo se define a pending.

    • La interfaz de usuario recibe una notificación con onThreadUpdated().

Chatear con un Agente

Este diagrama de secuencia captura el flujo cuando un usuario final interactúa con un agente a través del chat, gestiona los mensajes de Bienvenido(a) y se comunica con los servicios de backend. Si ocurren errores, estos se gestionan de manera adecuada.

Abrir diagrama en una nueva ventana

Inicialización de la conversación:

  • El usuario envía un mensaje utilizando sendMessage(message:).

  • Si existe un mensaje de bienvenida:

    • El SDK envía un mensaje de bienvenida usando SendOutboundMessageEvent(welcomeMessage:).

    • Si hay un error en el servidor, se maneja.

    • De lo contrario, se recibe MessageCreatedEvent y se actualiza la interfaz de usuario.

  • El SDK envía el mensaje del usuario utilizando sendMessageEvent.

    • Si hay un error en el servidor, se gestiona.

    • De lo contrario, se recibe MessageCreatedEvent y se actualiza la interfaz de usuario.

Finalizar contacto

Este diagrama de secuencia captura el flujo cuando un usuario finaliza un chat, gestiona el cierre de la conversación y se comunica con los servicios de backend. Si se producen errores, se gestionan de forma adecuada.

Abrir diagrama en nueva ventana

Finalización de la conversación:

  • El usuario presiona finalizar conversación.

  • La interfaz de usuario notifica al SDK que finalice la conversación usando endConversation().

  • El backend recibe el EndConversationEvent.

    • Si hay un error en el servidor, se maneja.

    • De lo contrario, se cambia el estado del caso y el estado del hilo se establece en closed.

    • La interfaz de usuario recibe una notificación con onThreadUpdated().

Vista de experiencia de finalizar contacto:

  • La interfaz de usuario muestra la vista del contacto final.

Procesar Eventos Grandes

Una de las limitaciones de AWS API Gateway es que sólo puede enviar un máximo de 128 KB en un mensaje. Para enviar eventos de mayor tamaño desde el servidor al cliente:

  • En el servidor, cargue los eventos de mayor tamaño en un depósito S3 disponible públicamente.

  • El cliente puede entonces recibir solo la URL de este archivo a través de WebSocket y descargar el cuerpo del evento real mediante REST.

Abrir diagrama en nueva ventana