--- title: Guía social API slug: Social_API/Guide translation_of: Archive/Social_API/Guide ---

 

Borrador
Esta página no está completa.

Este artículo describe el ciclo de vida de un social service worker, como el servicio social permite al navegador interactuar con un sitio  de redes sociales y asi sucesivamente.

Ciclo de vida de un social service worker

Un proveedor de servicios sociales esta definido por un archivo de texto estructurado (JSON) incluyendo un número de URLs con llave, un nombre y un icono. Los URLs poseen el mismo orígen que el archivo JSON si es cargado remotamente.

Un social service worker es instanciado del URL de dicho service worker provisto por el proveedor de servicios; este URL  debe resolver a un archivo JavaScript que es evaluado por el trabajador de servicios. El worker es un worker compartido, renderizado "no comprable" en un estilo muy similar a la especificación de los Trabajadores Web ( aunque debe tomarse en cuenta que la implementación actual no es, de hecho, un Worker).

El service worker permanece con vida hasta finalizar, ya sea por cierre de navegador o por un comando de control explícito del usuario.

Si el navegador determina que la finalización del service worker es necesaria, todos los contenidos del servicio-nivel asociados con el service worker es descargado ( esto significa, que todos los ServiceWindows y barras laterales seran cerrados) como parte de la finalización.

Si el navegador se inicia ( o se reinicia) el servicio durante una sesión de usuario normal, el service worker es primero completamente cargado, y las barras laterales son instanciadas en ventanas existentes. Los ServiceWindows (como los chats) no son reiniciados automáticamente.

Flujo de implementación

Esta sección ilustra como el social service comenzó, como se comunica con el sitio de redes sociales, y se finaliza.

<<<añada un diagrama actual>>>

  1. El servicio es registrado con un servicio, widget de barra lateral y widget para compartir.
  2. En el momento de inicio del navegador, el trabajador de servicio es instanciado.
  3. El servicio abre un conexión a su servicio, si una sesión de usuario esta disponible, y empieza a recibir eventos de inserción.
  4. Cuando una ventana del navegador es creada, el contenido del widget de la barra lateral es instanciado.
  5. La barra lateral se registra con el servicio usando mozSocial.getWorker().postMessage("hello").
  6. El trabajador de servicios captura el mensaje "hello" y añade la sidebarContentWindow a una lista de recepción de eventos.
  7. El contenido de la barra lateral podrá entonces realizar una conformidad de conexiónes publicar-suscribir más elaboradas, para limitar que eventos este recibe.
  8. Cuando el servicio recibe eventos del servidor (o de otro contenido), invoca window.postMessage() en cada referencia de ventana que fue previamente guardada. La barra lateral se regenera segun sea necesario.
  9. Si el usuario hace click en la barra lateral para, por ejemplo, abrir una ventana de chat, window.open() se hace la llamada y una nueva ventana es creada. La ventana de chat se registra con el servicio utilizaando mozSocial.getWorker().postMessage("hello") y recibe un mensaje de vuelta indicandole con quien abrir un chat. El servicio puede entregar eventos servidor-inserción a la ventana de chat, tal vez a través de un sistema publicar-suscribir.