IMPLEMENTACIÓN DE NOTIFICACIONES PUSH

EN UNA PLATAFORMA E-LEARNING

José Ángel Regueiro Janeiro

Trabajo de Fin de Grado

Escuela de Ingeniería de Telecomunicación
Grado en Ingeniería de Tecnologías de Telecomunicación

Tutores
Miguel Rodríguez Pérez

2017
 Escola de Grao en Enxeñaría
Mención:
Enxeñaría de de Tecnoloxías de
Telemática
Telecomunicación Telecomunicación

IMPLEMENTACIÓN DE
NOTIFICACIONES PUSH EN UNA
PLATAFORMA E-LEARNING
Autor: José Ángel Regueiro Janeiro
Tutor: Miguel Rodríguez Pérez
Curso: 2016-2017

I. Introducción
En este trabajo se presenta el desarrollo e incorporación de un módulo funcional de
notificaciones de nuevos eventos para una plataforma de autoaprendizaje, e-learning, basada
en una de red social.

Si bien originalmente la web no estaba pensada para dar soporte a sistemas de aprendizaje en
línea como e-learning, su evolución a lo largo de la historia hizo posible la aparición del e-
learning. En sus primeras etapas, la web se caracterizaba por presentar una descentralización y
unidireccionalidad de los recursos. Sin embargo, las nuevas versiones posibilitaron que se
consolidara como un medio más interactivo, en el que cualquier persona podía convertirse en
creador o consumidor de recursos, dando lugar a nuevas modalidades de aprendizaje, que ahora
podía realizarse en línea [1]. Nace así el denominado e-learning [2], en el que se modifican los
roles de profesor y alumno. De este modo, el alumno se responsabiliza de autogestionar su
propio aprendizaje, convirtiéndose así en el centro del proceso de enseñanza, mientras que el
profesor se encarga de guiarlo y orientarlo [3]. La interacción entre ambos se realiza a través de
distintas plataformas virtuales o redes sociales, que acostumbran contar, además, con foros o
chats [4]. En la actualidad, existe una gran cantidad de software dedicado al desarrollo y control
de las redes sociales o plataformas dedicadas al e-learning. Entre estos, Elgg se ha consolidado
como uno de los recursos más populares para la creación de redes sociales en línea [5], gracias
a las funcionalidades que ofrece:

Elgg es un framework de redes sociales de código abierto, el cual ofrece el servicio

de creación de redes sociales, gestión avanzada de usuarios y su administración;
además hace uso de una API que permite la instalación de una gran cantidad de
plugins, que dan a Elgg la capacidad de adaptarse a las necesidades de los usuarios
[6].
Esta característica de adaptabilidad es la que consolida a Elgg “como buena aplicación Web 2.0
para crear redes sociales basadas en la Web, con la que se pueden soportar ciertos elementos
de aprendizaje colaborativo” [7].

Nuestro sistema de notificaciones está desarrollado para una red social de aprendizaje,
SocialWire, que se enmarca dentro del framework de desarrollo de Elgg.

SocialWire es un entorno de aprendizaje colaborativo que fue diseñado con el propósito inicial
de combinar actividades de aprendizaje informal y formal, añadiendo, al mismo tiempo, el
componente de la gamificación [8]. Este entorno se apoya en el núcleo de Elgg, lo que permite
crear y modificar diferentes módulos o plugins para dotar a la red social de las funcionalidades
que el usuario requiere en cada momento [5]. Sin embargo, una carencia de Elgg, que
trataremos de suplir con este trabajo, es la falta de un sistema de notificaciones para los
usuarios.

Hoy en día, disponemos de diversos métodos que nos permiten comunicarle a un usuario una
determinada información a través de notificaciones. Destacan, por ejemplo, las notificaciones
por correo electrónico, el envío de SMS, las notificaciones nativas (notificaciones propias de un
sistema operativo) o las notificaciones basadas en aplicaciones Web (el sistema de notificaciones
que utilizan los navegadores) [9].

Atendiendo a la frecuencia de uso, el correo electrónico constituye generalmente el método

más habitual. Se emplea en la comunicación de sugerencias, anuncios, confirmaciones de
compra, entre otros. Una de las características más importantes del correo electrónico es que
permite almacenar los mensajes en la bandeja de entrada del correo, lo que facilita su consulta
en cualquier momento [10].

El envío de SMS como método de notificación consiste en la intercepción del mensaje por parte
de la aplicación cuando este llega al dispositivo móvil. Este sistema presenta, sin embargo, varios
inconvenientes. Por un lado, el envío masivo de mensajes a una gran cantidad de usuarios
supone un coste muy elevado. Por otro lado, no existen garantías de que el mensaje llegue a su
destino dentro del periodo de tiempo acotado, debido a la interacción de otros elementos, como
la disponibilidad de cobertura o el correcto funcionamiento de las estaciones base de telefonía
[10].

La principal diferencia entre las notificaciones nativas y las notificaciones basadas en

aplicaciones Web es que las primeras permiten el envío de notificaciones push, que no necesitan
una consulta del usuario, de modo que avisan de un suceso de forma rápida. A su vez, cuentan
con la función de recibir estas notificaciones cuando el navegador está cerrado. Por el contrario,
aquellas basadas en aplicaciones Web no admiten el uso de notificaciones push, y tan solo
reciben notificaciones si el navegador se encuentra abierto y con la aplicación cargada [11].

En este trabajo presentamos el desarrollo e implementación de un plugin encargado de

gestionar el envío y recepción de notificaciones push, notificaciones nativas, con la finalidad de
notificar al usuario de nuevos eventos ocurridos en la plataforma SocialWire.

Para el desarrollo de este proyecto, se consideran, en primer lugar, los objetivos principales del
mismo, así como los objetivos operativos planteados para alcanzar nuestros propósitos. En
segundo lugar, se detallan las tecnologías empleadas y se examina el diseño y desarrollo del
proyecto. Finalmente, se presentan los resultados y se aportan las conclusiones extraídas del
estudio, así como las referencias bibliográficas citadas a lo largo del trabajo.

II. Objetivos
El objetivo principal de este trabajo es contribuir al desarrollo de un módulo de comunicación
funcional para una plataforma de redes sociales, SocialWire. Este módulo se basa en un sistema
de notificaciones tanto para escritorio como para dispositivos móviles, teniendo en cuenta la
existencia previa de un módulo de comunicaciones basado en notificaciones por correo
electrónico.

Para alcanzar nuestro objetivo principal, se han considerado los siguientes objetivos operativos:

• Crear, implementar e incorporar un módulo de notificaciones de escritorio para la

plataforma, con aplicación en ordenadores y dispositivos móviles.
• Realizar las modificaciones necesarias en la vista de configuración de notificaciones
por correo que existía previamente, para incluir nuevos parámetros que le permitan
al usuario controlar el nuevo sistema de notificaciones.
• Dotar al módulo de notificaciones de la capacidad de extraer de la base de datos la
información relativa al usuario al que van dirigidas, así como el dispositivo al que
enviar la notificación.
• Desarrollar una interfaz de configuración para permitir a cada usuario habilitar el
envío de notificaciones por parte del sistema.
• Desarrollar la vista necesaria para conseguir que el administrador del sistema la
configure fácilmente cuando decida implementar este módulo en su plataforma.
III. Tecnologías empleadas
En esta sección, se consideran las tecnologías empleadas para el desarrollo del módulo de
notificaciones de nuestro proyecto:

III.1. Elgg
Elgg es una plataforma de código abierto para la creación y desarrollo de sitios web sociales.
Esto significa que cualquiera puede descargarlo y modificarlo según las funcionalidades que
necesite [12].

La plataforma Elgg puede dividirse en dos partes; por un lado, dispone del núcleo o motor, por
otro, se encuentran los plugins o módulos. El núcleo de Elgg ofrece los mecanismos necesarios
para crear una red social y, además, cuenta con un framework para que los desarrolladores
puedan implementar nuevas funcionalidades mediante plugins [13].

Esta posibilidad de crear módulos o plugins adicionales es lo que hace posible que la plataforma
pueda personalizarse y disponer de aquellas funcionalidades que los usuarios necesiten en cada
momento [13].

Tras presentar la base sobre la que hemos instalado y configurado una versión de SocialWire,
procedemos a tratar las tecnologías empleadas para el envío de notificaciones.
III.2. Notificaciones Push
A la hora de dotar a la red social SocialWire de un módulo de notificaciones, disponíamos de dos
posibilidades: incrustar una vista web en una aplicación nativa del sistema operativo o utilizar
una nueva API experimental multiplataforma.

El principal problema de la primera opción es que no era multiplataforma. Por el contrario, la

segunda posibilidad, consistente en emplear una API experimental, permitía que nuestro
sistema fuera multiplataforma. Esta API experimental se basaba en la utilización de
notificaciones Push [14].

Las notificaciones Push son una tecnología de mensajería que permite el envío de paquetes de
información, basándose en un método de publicador y suscriptor cuando se da una determinada
condición [15]. Entre las características más importantes de esta tecnología se encuentran:

• Es una tecnología multiplataforma, es decir, es compatible con más de un sistema

operativo (Ubuntu, Windows, Android, entre otros).

• Proporciona las mismas capacidades que una aplicación nativa [14].

• Reduce la carga de mensajes duplicados en el servidor, pues permite el envío del mismo
mensaje a diferentes dispositivos [16].

• Requiere del uso de una API, la Push API, que no necesita la instalación de ningún tipo
de aplicación, puesto que la proporciona el propio sistema operativo o el navegador.
Esta API es la que ofrece la posibilidad de recibir las notificaciones en el dispositivo del
usuario [15].

• Permite firmar los mensajes push, de manera que se garantiza la identidad del emisor y
se protege, a su vez, la integridad del mensaje [17]. Si bien esta característica es
opcional, se ha implementado en nuestro proyecto para ofrecer más seguridad al
servicio.

Esta tecnología se puede dividir en tres partes: envío, recepción y visualización de la notificación.
El envío de la notificación lo realiza el servidor web (Application Server) utilizando la tecnología
push. De la recepción del mensaje se encarga un service worker, que está a la escucha de la
llegada de nuevas peticiones [14]. La visualización del mensaje se logra mediante el uso de la
tecnología de notification, que se encarga de mostrar una información por pantalla al usuario
una vez que es recibida en el service worker [18].
III.2.1. Tecnología Push: Push API
La Push API proporciona a las aplicaciones web la funcionalidad de recibir mensajes enviados
desde un servidor. Además, esta API ofrece la posibilidad de recibir notificaciones aun cuando
la aplicación no esté en primer plano o cargada [14]. En la siguiente imagen se observa un
esquema de la arquitectura del sistema Push:

Figura 1: Esquema Push [19]

Tal y como se puede observar en la figura anterior (Figura 1), el sistema consta de los siguientes
elementos (Tabla I):

Tabla I: Descripción de la tecnología Push [19].

Nombre del elemento Descripción

Application Server Servicio back-end que genera la suscripción para enviarla a través
del servidor Push. En nuestro caso sería el servidor de SocialWire.

Subscription Solicitud enviada al usuario para obtener una información sobre

un determinado tema. Supone la creación de un Endpoint al que
se envía la suscripción de actualización (Subscription Update).

Endpoint URL específica que se emplea para el envío de la Subscription

Update. La proporciona el desarrollador del agente del usuario,
normalmente un navegador, y es utilizada por el Application
Server para el envío de las notificaciones al proveedor del sistema
Push.

Push Server Servidor que maneja los eventos y el envío de estos hacia su
correcto suscriptor. Cada navegador tiene su propio Push Server:
Firebase Cloud Messaging (Google), Autopush (Mozilla), entre
otros.

Push Sistema encargado del envío de los eventos desde el Application

Server hacia la Application.
 Subscription Provider Encargado de enviar los Push Messages a los User Agents para ser
leídos por el cliente correspondiente.

Subscription Update Mensaje enviado por el Subscription Provider al Push Server.

Push Message Mensaje enviado por el Application Server a la aplicación, a través

del servicio Push.

User Agent El navegador del cliente, generalmente, es un código interno que

procesa y envía Push Message a la aplicación.

Tal y como se ha mencionado con anterioridad, el lenguaje de programación que se ha utilizado

en nuestro proyecto es PHP, dado que es el empleado en el Application Server. Por este motivo,
era necesario un protocolo de comunicación que fuera compatible con la Push API y, al mismo
tiempo, dispusiera de una versión compatible con PHP. De este modo, se empleó el protocolo
Web Push, que permite la comunicación entre nuestro servidor y el servicio push (Google,
Mozilla, Apple, etc.). Esto facilita la tarea del desarrollador, que no tiene que ocuparse de
averiguar a qué servidor push se le está pidiendo servicio [20].

III.2.2. Tecnología Push: Firma de mensajes

Recientemente, los servidores Push han modificado su configuración y la forma en la que se
establecía la comunicación. Cuando antes ocurría un problema en el envío de la notificación
Push, no existía la posibilidad de comunicar el error al propietario. Ahora sí se introduce una
función para identificar al propietario del contenido, VAPID (Voluntary Application Server
Identification). Esta funcionalidad es opcional, pero dota al servicio de un mayor nivel de
seguridad [17].

VAPID es una nueva especificación que permite a una página web que utilice notificaciones push
autentificarse más fácilmente ante servicios push. Consiste en una serie de valores que
describen, definen e indican donde se ha creado la suscripción. Estos valores se sitúan en la
cabecera del mensaje, y se envían en el momento de realizar la suscripción [19]. Esta
especificación funciona esencialmente como mecanismo de handshake entre el Application
Server y el Push Server. Además, permite al Push Server confirmar a qué sitio está enviando los
mensajes [21]. Si el Push Server encuentra algo inusual en el contenido, VAPID ofrece la
información necesaria para poder contactar con el propietario del mensaje, indicándole qué
problema ha ocurrido con su mensaje [19].

Además, VAPID evita que un posible atacante pudiera robarle a un usuario del sistema su
suscripción. Esta suscripción contiene toda la información que el Push Service necesita para
enviar mensajes push al navegador del usuario y su intercepción permitiría enviar al usuario
mensajes push desde otro servidor.

III.2.3. Tecnología Push: Recepción del mensaje en el navegador

Para que la Push API funcione correctamente es necesario que se asocie el agente de usuario,
normalmente un navegador web, con un service worker [22]. Un service worker es una tarea
orientada a eventos que se ejecuta en segundo plano. Consiste en un script en JavaScript que
controla e intercepta los mensajes y modifica las peticiones de la página a la que se encuentra
asociada [23]. Entre las características más destacables del service worker se encuentran [24]:

• La ejecución corre sobre un hilo distinto al de los otros códigos JavaScript de los que
dispone la aplicación. Esto lo convierte en una tarea no bloqueante y asíncrona, es decir,
que su ejecución no paraliza o bloquea la aplicación [25]

• Por motivos de seguridad, utiliza un canal de comunicación seguro. Esta funcionalidad

evita que el service worker, que controla tanto la página asociada como su información,
sea vulnerable a ataques Man in the Middle [23]. Como se ha mencionado, el uso de un
canal de comunicación seguro es el motivo por el que este proyecto requería del uso del
protocolo TLS.

A la hora de enlazar una página web con un service worker (suscripción), existen dos parámetros
opcionales: “userVisibleOnly” y “applicationServerKey”. El primer parámetro es un booleano que
indica que la recepción de un mensaje push va a originar que se le muestre una notificación al
usuario receptor. El segundo parámetro es un factor de autenticación que emplea la aplicación
del servidor y que indica la clave pública con la que el servidor push enviará mensajes a la
aplicación del cliente [23].

Todas estas tecnologías funcionan conjuntamente de la siguiente manera: cuando un usuario

entra por primera vez en la página web de la plataforma SocialWire, esta registra, si es posible,
el service worker, que queda activado y asociado con la página web correspondiente. Una vez
realizada la asociación entre la página web y el service worker, este se queda a la espera de la
recepción de los mensajes push que correspondan con la clave VAPID con la que se registró. A
continuación, la Push API se suscribe al service worker para comenzar a utilizar las notificaciones
push. El resultado de esta suscripción es un método Push Subscription, que incluye toda la
información que la aplicación necesita para el envío del mensaje push, es decir, el endpoint y las
claves de encriptación (token y key) [23]. Estos parámetros son enviados y almacenados en
nuestro servidor. Cuando el servidor desea enviar un mensaje a ese service worker, se le
proporcionan al protocolo Web Push los parámetros anteriores y la clave pública y privada
correspondiente de VAPID, y este enviará el mensaje. A partir de ese momento, el service worker
está preparado para controlar los mensajes push entrantes que correspondan con su clave
VAPID, y mostrarlos utilizando la tecnología de notificación.

III.3. Visualización de los mensajes: Notification API.

Una vez que el service worker recibe un evento de notificación debe mostrárselo al usuario por
pantalla. Para esto es necesario que el usuario acepte la recepción y visualización de las
notificaciones en su dispositivo [26].

La Notification API permite que las páginas web controlen la presentación de notificaciones
fuera del contexto de la ventana de navegación principal del usuario. Esto permite mostrar las
notificaciones aun cuando el usuario cambie o cierre la pestaña correspondiente a la página web
de SocialWire. Además, esta API está diseñada para ser compatible con los sistemas de
notificación existentes en diferentes plataformas, llegando incluso a mostrarse como
notificaciones nativas en algunos dispositivos móviles [26].
En este proyecto, Notification API se emplea para solicitar los permisos y mostrar las
notificaciones por pantalla.

IV. Diseño y desarrollo

SocialWire carece de una funcionalidad nativa de envío de notificaciones. No obstante, dispone
de una serie de plugins que permiten la comunicación de nuevos eventos a los usuarios
mediante correo electrónico.

A continuación, se presenta el desarrollo de nuestro módulo de notificaciones. Si bien, es

necesario indicar que, para un funcionamiento adecuado del módulo, es necesario haber
activado previamente tanto el módulo encargado del envío de las notificaciones de correo
electrónico, notifications, como el módulo encargado de la gestión y envío de notas internas
entre usuario, thewire_tools, dado que nuestro módulo extenderá y modificará algunas de sus
vistas.

IV.1. Plugin
Al ser una plataforma basada en Elgg, SocialWire requiere de la configuración y programación
de plugins o módulos para dotar a la red social de diferentes funcionalidades. Estos plugins
tienen una estructura modular y deben ser programados en PHP, por ser este el lenguaje de
programación que se utiliza en el servidor de la plataforma.

Para crear un plugin en Elgg se necesitan dos archivos fundamentales: manifest.xml y start.php.
El primero es un archivo XML donde aparecen todos los datos que necesita el plugin para su
correcto funcionamiento, por ejemplo: qué otros plugins deben ser instalados en la plataforma
o qué versión de PHP requiere. Además, también ofrece información sobre el nombre del plugin
y del autor, entre otros. El segundo archivo, start.php es el archivo principal y contiene toda la
funcionalidad del plugin.

La programación de este plugin podemos dividirla en dos partes: por un lado, la parte encargada
de la recepción de eventos y, por otra, la encargada de su envío.

IV.2. Recepción de eventos

Para poder realizar correctamente la recepción de eventos en nuestro plugin fue necesario
realizar los siguientes pasos: registrar el service worker y enviar los datos del registro a
SocialWire.

En primer lugar, programamos tanto el código JavaScript del service worker como el script
necesario para su ejecución y asociación con la página web. Este código se ejecuta cada vez que
un usuario accede a la página web de SocialWire y tiene permitida la recepción de notificaciones
push. Para ello, es necesario que el service worker disponga de la clave pública de VAPID. Con el
propósito de lograr que el service worker dispusiera de esta clave, fue necesario añadirla
previamente a una serie de variables globales que dispone Elgg, a las que se puede acceder
desde cualquier plugin.

En segundo lugar, programamos un script en JavaScript que se encargara del envío de los datos
del navegador (endpoint, key y token) correspondientes a cada usuario, para hacer posible el
envío de notificaciones push más adelante. Sin estos datos, no se sabría a qué navegador va
dirigida cada notificación.

Por último, se necesitaba que los datos enviados en el apartado anterior se pudieran recibir en
el servidor y, posteriormente, almacenarlos en la base de datos para tenerlos disponibles y
accesibles a la hora de realizar el envío de una notificación. Para esto, se utilizó una serie de
actions. Un action es un código que nos ofrece Elgg para poder modificar la base de datos cuando
un usuario realiza una acción en la plataforma. En concreto, necesitamos la configuración de dos
actions. El primero de ellos se ocupará de recibir los parámetros del navegador (endpoint, token
y key) y almacenarlos en una variable JSON. Además de estos datos, también se guardará la
información que se pueda obtener del User Agent sobre el navegador con el que está
accediendo el usuario, por ejemplo: tipo de sistema o tipo de navegador. El segundo action se
encargará de actualizar, a petición del usuario, en cuál o cuáles de los navegadores asociados
quiere recibir las notificaciones.

Así se han configurado todas las funcionalidades de nuestro plugin con respecto a la recepción
de eventos y la obtención de los parámetros necesarios para poder realizar el envío de
notificaciones push correctamente.

IV.3. Envío de eventos

Para poder realizar el envío de notificaciones, fue necesario hacer uso de una funcionalidad que
ofrece Elgg, que permite, mediante la utilización de hooks, que un plugin sea capaz de capturar
un evento creado por otro. Por eso, se configuró un hook para que capturara el evento de
notificación, la Web Push y la Notification API.

En primer lugar, se configuró y registró el hook en el fichero de configuración start.php. Este

hook es una función que está a la escucha de que suceda un determinado evento. Si este ocurre,
ejecuta otra función que es la que ofrece la funcionalidad correspondiente. En nuestro caso,
nuestro hook está a la escucha de eventos dentro de la página web del tipo notification:notifier.
Este tipo de eventos serán los que nosotros notificaremos al usuario mediante notificaciones
push.

En segundo lugar, una vez que nuestro hook captura un evento de ese tipo, ejecuta una función
que utiliza los datos que contiene el evento capturado (usuario receptor, usuario emisor, etc.) y
busca en la base de datos el fichero Json, correspondiente al usuario receptor, que incluye toda
la información de los navegadores del usuario en los que tiene permitido la recepción de esta
clase de notificaciones. Estos datos (endpoint, key, token) se le pasan a la Web Push API que se
encarga de enviar la notificación al navegador correspondiente.

En tercer lugar, una vez que la notificación ha sido enviada y el service worker del navegador
correspondiente la recibe, mediante la utilización de la Notification API esta mostrará la
notificación al usuario. Como se ha mencionado anteriormente, para que sea posible la
visualización de notificaciones por parte del usuario es necesario que este haya permitido su
uso.
IV.4. Administración
Para adaptar nuestro plugin a la versión de SocialWire, se ha optado por configurar una vista
que resulte fácil y sencilla tanto para el usuario como para el administrador del sistema. A
continuación, se presentan cada una de las vistas:

IV.4.1. Cambios visuales a nivel de usuario

Este apartado parte de la vista de configuración de un sistema de notificaciones de correo
electrónico ya existente.

A partir de este sistema, para la realización de este proyecto se copiaron los archivos
correspondientes a esas vistas y se situaron en la misma ruta, views, pero dentro de nuestro
plugin. Posteriormente, se modificó el archivo, añadiendo los nuevos parámetros
correspondientes a la configuración del plugin. Los cambios realizados en esos ficheros
consistieron en pequeñas modificaciones estéticas, así como en añadir información relacionada
con la configuración de qué dispositivos y qué tipo de notificaciones desearía recibir el usuario.
Estas modificaciones estéticas consistieron en la incorporación de los dispositivos disponibles
para el usuario en los que recibir notificaciones, así como un checkbox asociado, que permite
habilitarlos y deshabilitarlos cuando se desee.

Esto se debe al propio funcionamiento de Elgg, que sobrescribiría el fichero antiguo con nuestro
fichero modificado a la hora de cargarlo. Elgg carga los ficheros de los plugins según el orden en
el que estén colocados en el sistema de administrador de Elgg. De este modo, en el caso de que
dos archivos estén en la misma ruta y se nombren de la misma manera, pero se encuentren en
distintos plugins, el usuario solo verá la configuración del segundo fichero, es decir, el que se ha
cargado más recientemente.

Al haber realizado modificaciones en la vista, fue necesario añadir también ciertos criterios de
verificación mediante un fichero JavaScript, que comprobaba las acciones que el usuario
realizaba o quería realizar, evitando que este seleccionara aquellas no permitidas o ilógicas,
como sería el caso, por ejemplo, de solicitar recibir notificaciones, pero no haber seleccionado
ningún dispositivo que las reciba, o viceversa.

IV.4.2. Cambios visuales a nivel de administrador

Para poder instalar y configurar el plugin y que este funcionara correctamente con VAPID, se
optó por crear una interfaz de configuración amigable, a la que solo pudiera acceder el
administrador del sistema.

Una vez que el responsable del sistema tuviera creada su clave pública y privada de VAPID, este
solo tendría que dirigirse a la pantalla de configuración del plugin y escribir estos parámetros,
además del “subject” que puede ser bien un correo electrónico, bien una URL. Este “subject”
constituye la dirección con la que el servidor Push contactaría en caso de que ocurriera un error
durante el envío de una notificación.

Una vez escritas y aceptadas las claves, el sistema completa de forma dinámica, con la clave
pública, el archivo JavaScript que se usa para el registro ante el service worker. De este modo,
se evita que tenga que ser el administrador quien busque dicho fichero para completarlo.
Así, se facilita al responsable una configuración sencilla y rápida del plugin compatible con
cualquier navegador que permita y soporte el uso de esta tecnología.

IV.5. Compatibilidad del plugin con todos los navegadores

Uno de los principales inconvenientes de este sistema de notificaciones es que todavía no es
compatible con todos los navegadores de todos los sistemas operativos. Así, por ejemplo, no es
compatible con Safari (Apple) o Edge (Microsoft), entre otros, dado que algunos navegadores
todavía están implementando esta tecnología.

Tras comprobar la compatibilidad de los distintos navegadores haciendo uso de la web Can I Use
[27], se procedió a realizar la primera prueba del sistema de notificaciones en Mozilla Firefox.
Más concretamente, se empleó una versión de desarrolladores Nightly, dado que cuando se
empezó a trabajar en la demo era uno de los pocos navegadores que tenían disponible la
utilización de la tecnología Push al completo.

V. Resultados
A continuación, se presentan los resultados de nuestro proyecto, considerando, en primer lugar,
aquellos cambios que se realizaron en la vista de configuración de las notificaciones de cara al
usuario. Seguidamente, se expondrán los cambios realizados en la vista de configuración del
plugin, para facilitar la configuración del mismo por parte del administrador. Por último, se
presentará cómo se muestran las notificaciones y cómo se visualizan una vez que son recibidas
por el correspondiente dispositivo del usuario.

V.1. Pantalla de configuración del plugin (Usuario).

Tal y como se ha expuesto en apartados anteriores, en la pantalla de configuración los cambios
que se presentan a nivel estético son: la incorporación de los dispositivos que tiene el usuario
registrados con posibilidad de recibir notificaciones, así como los checkboxes correspondientes
para controlar su funcionamiento y activación. Además, se han facilitado mensajes de ayuda
para el usuario, indicándole qué puede hacer en caso de que ocurra algún error relacionado con
el uso de las notificaciones.

Figura 2: Punto de partida de la configuración de las notificaciones.

 Figura 3: Configuración final de las notificaciones.
En la primera de las imágenes anteriores (Figura 2), se presenta el punto de partida, mostrando
cómo se encontraba la página antes de que el plugin estuviera habilitado. En la segunda imagen
(Figura 3), se recoge el nuevo aspecto que presenta la página una vez que nuestro plugin está
activado.

Como se puede apreciar, se ha introducido la presentación de los dispositivos que tiene el

usuario asociados, así como sus correspondientes checkboxes.

Lo primero que el usuario visualiza al entrar por primera vez en la vista de configuración de
notificaciones es un pop-up, por parte del navegador, que le solicita al usuario permiso para
poder recibir notificaciones en ese dispositivo (Figura 4).

Figura 4: Solicitud de petición para recibir notificaciones

Esta solicitud le presenta al usuario distintas posibilidades que pueden cambiar dependiendo
del navegador. En el caso de Firefox, se ofrecen las opciones: recibir notificaciones siempre,
bloquear siempre notificaciones y esta vez no (Figura 5).

Figura 5: Lista de opciones a la hora de permitir el uso de notificaciones.

Dependiendo de la opción seleccionada por el usuario, la página mostrará una información u

otra.

En caso de que el usuario, por alguna razón, bloquee o deniegue el uso de notificaciones, el
mensaje informativo que aparecerá en ese caso le indicará que no tiene habilitado el uso de
notificaciones, y le informará de cómo podría habilitarlas en el caso de que lo desee (Figura 6).
 Figura 6: Mensaje de error de la página

En apartados anteriores se ha comentado que cada navegador es diferente y la forma de

habilitar el uso de las notificaciones es distinta. Por ese motivo, el mensaje resultante es
personalizado para cada tipo de navegador (Figura 7 y Figura 8).

Figura 7: Mensaje informativo de cómo activar las notificaciones en Firefox

Figura 8: Mensaje informativo de cómo activar las notificaciones en Google Chrome

V.2. Pantalla de configuración del plugin (Administrador).

Para facilitar la configuración del plugin por parte del administrador se ha añadido un panel, solo
accesible para este, en el que se le permite introducir los datos necesarios para la configuración
de VAPID.
 Figura 9: Panel de configuración para el administrador.

Tal y como se puede apreciar en la figura superior (Figura 9), estos campos son la dirección de
correo electrónico, junto con una ayuda que indica qué forma debe tener ese campo, la clave
pública y privada de VAPID.

Al guardarse la configuración, los ficheros que necesitan esas claves se actualizan

dinámicamente para que todo funcione de manera adecuada.

V.3. Visualización de las notificaciones.

Una vez que sucede un nuevo evento en el servidor, este tiene que encargarse de notificárselo
al usuario correspondiente. Para ello, el servidor, envía un evento de notificación al endpoint del
navegador del usuario en concreto. Cuando el mensaje llega al service worker asociado, este se
lo muestra por pantalla al usuario.

A continuación, se presentan dos imágenes, una correspondiente a la notificación que le llega a

un usuario que cuenta con un navegador Mozilla en un portátil (Figura 10), y otra en la que la
notificación la recibe un usuario que tiene asociado un navegador Google Chrome en un
dispositivo Android (Figura 11).

Figura 10: Notificación Mozilla

 Figura 11: Notificación Google Chrome, Android
Como se puede apreciar, ambas notificaciones hacen referencia a una solicitud de amistad que
ha recibido el usuario.
VI. Conclusiones
Este trabajo nos ha permitido indagar en el funcionamiento interno de Elgg, así como
implementar un sistema de notificaciones en la nube.

En cuanto a nuestro objetivo principal, contribuir al desarrollo de un módulo de comunicación

funcional para la plataforma de redes sociales SocialWire, hemos comprobado que este se ha
cumplido, dado que nuestros resultados indican que las notificaciones pueden ser recibidas en
cualquier tipo de plataforma compatible con esta tecnología. Esto incluye cualquier dispositivo
Android, con versión superior a la 5.0, así como cualquier sistema operativo de escritorio que
tenga instalado Firefox o Chrome en su versión actual.

Con respecto a nuestros objetivos operativos, desarrollar tanto un módulo de notificaciones

para permitir a cada usuario habilitar el envío de notificaciones por parte del sistema, como una
vista para conseguir una fácil configuración por parte del administrador del sistema cuando este
decida implementar el módulo en su plataforma, ambos se han implementado correctamente y
permiten a cada usuario administrar toda esta información.

Al mismo tiempo, nuestro objetivo relacionado con dotar al módulo de la capacidad de extraer
de la base de datos la información relativa a qué usuario van dirigidas, así como el dispositivo al
que poder enviar la notificación correspondiente, se ha alcanzado tras comprobar con los
resultados el correcto funcionamiento del módulo.

Finalmente, concluimos este trabajo con una serie de consideraciones con respecto a las
limitaciones del mismo, con vistas a futuras líneas de investigación. Nuestro trabajo se
encuentra limitado por la dependencia de los servicios de Google y Firefox [28]. Sin embargo,
aunque exista esta dependencia, al tratarse de una API estandarizada no necesitaría cambios en
el caso de que se incorporaran nuevos proveedores.

Al mismo tiempo, la API empleada en nuestro proyecto, la Push API se encuentra en una etapa
experimental, lo que supone que en un futuro puedan originarse cambios en su funcionamiento.

De cara a futuras líneas de trabajo, en el caso de que Microsoft termine de implementar la

compatibilidad de su navegador, Microsoft Edge, con la Push API, se podría comprobar si el
funcionamiento de nuestro trabajo en él es adecuado. En caso de que no sea compatible, se
podrían llevar a cabo las adaptaciones necesarias en nuestro plugin, para extender su
funcionalidad en este sistema.

Por último, se podría considerar también adaptar nuestro sistema para que funcione en el
navegador Safari, de Apple, que dispone de un método de notificaciones push distinto al que se
ha empleado en este trabajo. En última instancia, la extensión de la funcionalidad de nuestro
sistema de notificaciones a otros sistemas operativos permitiría mejorar la experiencia de los
usuarios de la plataforma.

VII. Referencias bibliográficas

[1] Cormode, G. & Krishnamurthy, B. (2008). Key differences between Web 1.0 and Web 2.0.
First Monday, 13 (6). doi: 10.5210/fm.v13i6.2125.

[2] Area Moreira, M. y Adell Segura, J. (2009). E-Learning: enseñar y aprender en espacios
virtuales. Tecnología Educativa. La formación del profesorado en la era de Internet, pp.391-424.

[3] Marisa Pagano, C. (2008). Los tutores en la educación a distancia. Un aporte teórico. Revista
de Universidad y Sociedad de Conocimiento, 4 (2), pp. 1-11.

[4] Fernández-Pampillón Cesteros, Ana (2009). “Las plataformas e-learning para la enseñanza y
el aprendizaje universitario en Internet”. Las plataformas de aprendizaje. Del mito a la realidad.
Madrid: Biblioteca Nueva, pp. 45-73.

[5] Sousa Vieira, M. E., López Ardao, J. C., Fernández Veiga, M., Rodríguez Pérez, M. y López
García, C. (2015). Using social learning methodologies in higher education. International Journal
of Engineering Pedagogy, 5 (2), pp. 64-72. doi: 10.3991/ijep.v5i2.4645

[6] López Galíndez, F. A., Rebolledo Fuentes, A., Burbano Fernández, M. F. & Solarte Sarasty, M.
(2014). Integración de servicios web 2.0 al software de redes sociales Elgg para el apoyo a
procesos de enseñanza y aprendizaje en educación matemática. En: Cuarta Conferencia de
Directores de Tecnología de Información, TICAL2014 Gestión de las TICs para la Investigación y
la Colaboración, Cancún.
[7] Mohammed Abdul, J. F. y Ramirez Velarded, R. V. (2009). Herramientas Web 2.0 para el
Aprendizaje Colaborativo. CYTED. Consultado el día 29 de mayo de 2017. Recuperado de:
http://remo.det.uvigo.es/solite/attachments/038_Web%202.0.pdf

[8] Sousa Vieira, M. E., López Ardao, J. C., Fernández Veiga, M., Rodríguez Pérez, M. and Herrería
Alonso, S. (2016), An open-source platform for using gamification and social learning
methodologies in engineering education: Design and experience. Comput Appl Eng Educ, 24:
813–826. Consultado el día 29 de mayo de 2017. doi:10.1002/cae.21746

[9] Tolentino, J. (2015). SMS vs. Push notification vs. Email: When should your app use what?
Consultado el día 29 de mayo de 2017. Recuperado de: https://thenextweb.com/future-of-
communications/2015/02/09/sms-vs-push-vs-email/

[10] Nawrocki, P., Jakubowski, M. y Godzik, T. (2015, septiembre). Analysis of notification

methods with respect to mobile system characteristics Piotr Nawrocki, Mikolaj Jakubowski y
Tomasz Godzik. Comunicación presentada en el Federated Conference on Computer Science and
Information Systems: FedCSIS, 2015 13-16 de septiembre. Lodz, Poland, pp. 1183-1189. doi:
10.15439/2015F6.

[11] Novia Sari, M. y Mohamad Ali, N. A. B. (2013). The Suitability of Native Application for
University E-Learning Compared to Web-Based Application. International Journal of Science and
Research, 4 (1), pp. 2045-2049.

[12] Elgg (2014). Elgg master Documentacion. Consultado el día 26 de mayo de 2017.
Recuperado de: http://learn.elgg.org/en/stable/

[13] Costello, C. y Sharma, M. (2012). Elgg 1.8 Social Networking: Create, Customize, and Deploy
Your Very Own Social Networking Site With Elgg (2ª edición). Birmingham: Packt Publishing

[14] Mozilla Developer Network (2017). Push API. Consultado el día 29 de mayo de 2017.
Recuperado de: https://developer.mozilla.org/en-US/docs/Web/API/Push_API

[15] Beverloo, P., Thomson, M., van Ouwerkerk, M., Sullivan, B. y Fullea, E. (2017). Push API. The
World Wide Web Consortium. Consultado el día 29 de mayo de 2017. Recuperado de:
https://www.w3.org/TR/push-api/

[16] Suhas Bharadwaj, R., Raghvendra Rao, G. (2016). Activity based Push Notification.
International Journal of Engineering and Science and Computing, 6 (6). pp. 6403-6405. doi:
10.4010/2016.1539

[17] Thomson, M. y Beverloo, P. (2017). Voluntary Application Server Identification for Web
Push. IETF Tools. Consultado el día 29 de mayo de 2017. Recuperado de:
https://tools.ietf.org/html/draft-ietf-webpush-vapid-02

[18] Medley J. (2016) Notificaciones push en la web: Oportunas, relevantes y precisas.

Consultado el día 29 de mayo de 2017. Recuperado de:
https://developers.google.com/web/fundamentals/engage-and-retain/push-notifications/

[19] Colin, J. R. (2016). Sending VAPID identified WebPush Notifications via Mozilla Push Service.
Consultado el día 26 de mayo de 2017. Recuperado de:
https://blog.mozilla.org/services/2016/08/23/sending-vapid-identified-webpush-notifications-
via-mozillas-push-service/

[20] Sullivan, B., Fullea, E. y van Ouwerkerk, M. (2015). Web Push API. Consultado el día 29 de
mayo de 2017. Recuperado de: https://w3c.github.io/push-api/

[21] Gaunt, M. y Medley, J. (2017). Web Push Interoperability Wins. Consultado el día 29 de
mayo de 2017. Recuperado de: https://developers.google.com/web/updates/2016/07/web-
push-interop-wins

[22] Gaunt, M. (2015). Push Notifications on the Open Web. Consultado el día 26 de mayo de
2017. Consultado el día 29 de mayo de 2017. Recuperado de:
https://developers.google.com/web/updates/2015/03/push-notifications-on-the-open-web

[23] Mozilla Developer Network (2017). Service Worker API. Consultado el día 29 de mayo de
2017. Recuperado de: https://developer.mozilla.org/en-
US/docs/Web/API/Service_Worker_API

[24] Russell, A., Song, J., y Archibald, J., (2015). Service workers. The World Wide Web
Consortium. Consultado el día 29 de mayo de 2017. Recuperado de:
https://www.w3.org/TR/service-workers/

[25] Mozilla Developer Network (2017). Worker. Consultado el día 29 de mayo de 2017.
Recuperado de: https://developer.mozilla.org/en-US/docs/Web/API/Worker

[26] Mozilla Developer Network (2017). Notifications API. Consultado el día 29 de mayo de 2017.
Recuperado de: https://developer.mozilla.org/en-US/docs/Web/API/Notifications_API

[27] Deberia, A. (2017). Push API. Consultado el día 26 de mayo de 2017. Recuperado de:
http://caniuse.com/#search=push%20api

[28] Google Cloud Messaging (2017). GCM and FCM Frequently Asked Questions. Consultado el
día 29 de mayo de 2017. Recuperado de: https://developers.google.com/cloud-messaging/faq