DemoCritics
Aplicación Android de participación poĺıtica con edición

colaborativa en tiempo real

Jaime Ramos Romero

Javier Bastarrica Lacalle

Grado en Ingenieŕıa Informática

Facultad de Informática

UNIVERSIDAD COMPLUTENSE DE MADRID

Trabajo de Fin de Grado
Madrid, Junio 2015

Directores:
Samer Hassan Collado

Pablo Ojanguren Menéndez





Autorización de Difusión y Uso

Autorizo a la Universidad Complutense de Madrid a difundir y utilizar con
fines académicos, no comerciales y mencionando expresamente a su autor,
tanto la propia memoria, como el código, la documentación y/o el software
desarrollado.

Jaime Ramos Romero

Javier Bastarrica Lacalle

Madrid, Junio 2015

Copyleft by Jaime Ramos Romero and Javier Bastarrica Lacalle, released
under the license Creative Commons Attribution Share-Alike International
4.0 available at:

https://creativecommons.org/licenses/by-sa/4.0/

III

https://creativecommons.org/licenses/by-sa/4.0/




Agradecimientos

Dejando a un lado su obligatoriedad, no suele ser tarea sencilla sacar adelante
un proyecto de estas caracteŕısticas, cuya finalidad entendemos que es com-
binar gran parte de los conocimientos que hemos aprendido durante nuestro
paso por las aulas y lanzarnos por primera vez al desarrollo de un trabajo
formal. Exige, entre otras cualidades, curiosidad, trabajo duro, investigación,
empeño, dedicación...

Queremos expresar nuestro agradecimiento a todas aquellas personas que han
colaborado para que este trabajo, pese a algunas complicaciones surgidas por
el camino, haya llegado a buen destino.

Lo primero, a los directores Pablo y Samer, sin cuyos consejos, orientaciones
y ayuda no habŕıamos sido capaces de finalizar este trabajo.

Lo segundo, a los chicos de Labodemo y a Javier de la Cueva, por su inestima-
ble colaboración al dedicarnos un poco de su preciado tiempo para compartir
ideas, aportar nuevos puntos de vista al proyecto y de paso ponernos un poco
los pies sobre la tierra.

Lo tercero, a amigos y familiares, por apoyarnos y hacernos más llevadero el
arduo proceso de terminar un proyecto como este.

Y por último, pero no por ello menos importante, a ti, lector, por invertir
un poco de tu valioso tiempo en prestar atenćıón a lo que se expone en
estas páginas. Esperemos que encuentres en su lectura algo que haga volar
tu imaginación, reflexionar y quién sabe si aprender tanto como nos lo ha
hecho hacer a nosotros.

”Cuanto más siniestros son los deseos de un poĺıtico, más pomposa, en ge-
neral, se vuelve la nobleza de su lenguaje.”

Aldous Huxley. Un Mundo Feliz.

V





Índice general

Page

Autorización de Difusión y Uso III

Agradecimientos V

Abstract IX

Resumen XI

1. Introducción 1

1.1. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1. Marco teórico: Poĺıtica en el mundo de la Informática . 1

1.1.2. Idea detrás de DemoCritics . . . . . . . . . . . . . . . 2

1.2. Objetivos del Proyecto . . . . . . . . . . . . . . . . . . . . . . 3

1.3. Estructura del Documento . . . . . . . . . . . . . . . . . . . . 4

2. Estado del Arte 7

2.1. Edición Colaborativa en Tiempo Real . . . . . . . . . . . . . . 7

2.1.1. APIs Centralizadas . . . . . . . . . . . . . . . . . . . . 8

2.1.1.1. Google Realtime API . . . . . . . . . . . . . . 8

2.1.1.2. Microsoft RTC Client API . . . . . . . . . . . 9

2.1.1.3. WebRTC . . . . . . . . . . . . . . . . . . . . 9

2.1.1.4. Mozilla TogetherJS . . . . . . . . . . . . . . . 9

2.1.1.5. ShareJS . . . . . . . . . . . . . . . . . . . . . 9

2.1.1.6. Goodow . . . . . . . . . . . . . . . . . . . . . 10

2.1.2. Plataformas Web y Android . . . . . . . . . . . . . . . 10

2.1.2.1. Wave: Wave In A Box (WIAB) . . . . . . . . 10

VII



2.1.2.2. Google Docs . . . . . . . . . . . . . . . . . . 10

2.1.2.3. Etherpad . . . . . . . . . . . . . . . . . . . . 12

2.1.2.4. Colorillo . . . . . . . . . . . . . . . . . . . . . 12

2.1.2.5. ShareLaTeX . . . . . . . . . . . . . . . . . . . 12

2.1.2.6. Samepage . . . . . . . . . . . . . . . . . . . . 14

2.1.2.7. Quip . . . . . . . . . . . . . . . . . . . . . . . 14

2.2. Aplicaciones de Participación Poĺıtica y Ciudadana . . . . . . 15

2.2.1. Programas Poĺıticos . . . . . . . . . . . . . . . . . . . . 15

2.2.1.1. UPyD Parla . . . . . . . . . . . . . . . . . . . 16

2.2.1.2. ]RecuperaCórdoba . . . . . . . . . . . . . . . 17

2.2.1.3. PSOE Andalućıa . . . . . . . . . . . . . . . . 18

2.2.1.4. PP Canarias . . . . . . . . . . . . . . . . . . 19

2.2.2. Participación Ciudadana . . . . . . . . . . . . . . . . . 20

2.2.2.1. Reddit . . . . . . . . . . . . . . . . . . . . . . 20

2.2.2.2. Change.org . . . . . . . . . . . . . . . . . . . 21

2.2.2.3. Programas Colaborativos de Ahora Madrid y
Zaragoza en Común . . . . . . . . . . . . . . 23

2.2.2.4. Appgree . . . . . . . . . . . . . . . . . . . . . 25

3. Metodoloǵıas del Proyecto 27

3.1. Uso de Software Libre . . . . . . . . . . . . . . . . . . . . . . 27

3.2. Migración de Wave/SwellRT a Android . . . . . . . . . . . . . 28

3.3. Diseño de la Aplicación . . . . . . . . . . . . . . . . . . . . . . 28

3.3.1. Brainstorming . . . . . . . . . . . . . . . . . . . . . . . 28

3.3.2. Diseño Guiado por Objetivos (DGO) . . . . . . . . . . 29

3.3.3. Brainstorming . . . . . . . . . . . . . . . . . . . . . . . 29

3.3.4. Diseño Guiado por Objetivos (DGO) . . . . . . . . . . 29

3.4. Implementación de la Aplicación . . . . . . . . . . . . . . . . . 30

3.4.1. Control de versiones . . . . . . . . . . . . . . . . . . . 31

3.4.2. GitHub . . . . . . . . . . . . . . . . . . . . . . . . . . 31



3.4.3. Reparto de tareas . . . . . . . . . . . . . . . . . . . . . 31

3.4.4. Revisiones de código . . . . . . . . . . . . . . . . . . . 31

3.4.5. Evaluaciones de usabilidad . . . . . . . . . . . . . . . . 32

3.5. Patrones de Diseño . . . . . . . . . . . . . . . . . . . . . . . . 32

4. Tecnoloǵıas del Proyecto 33

4.1. Tecnoloǵıas de Wave . . . . . . . . . . . . . . . . . . . . . . . 35

4.1.1. Google Wave . . . . . . . . . . . . . . . . . . . . . . . 35

4.1.2. Apache Wave . . . . . . . . . . . . . . . . . . . . . . . 35

4.1.3. Caracteŕısticas de Wave . . . . . . . . . . . . . . . . . 35

4.1.3.1. Federación . . . . . . . . . . . . . . . . . . . 35

4.1.3.2. Consistencia en tiempo real . . . . . . . . . . 36

4.1.3.3. Escalabilidad . . . . . . . . . . . . . . . . . . 37

4.1.4. Servidores Wave: SwellRT . . . . . . . . . . . . . . . . 37

4.1.5. Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.1.6. Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.1.7. GWT . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.1.8. JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.1.9. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.1.10. WebSocket . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.1.11. Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.1.12. GitHub . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.2. Tecnoloǵıas de la Aplicación Android . . . . . . . . . . . . . . 41

4.2.1. Android Studio . . . . . . . . . . . . . . . . . . . . . . 41

4.2.2. Android . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.2.3. XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.2.4. JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.2.5. SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.2.6. MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.2.7. PhpMyAdmin . . . . . . . . . . . . . . . . . . . . . . . 44



4.2.8. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.2.9. Laravel 5 . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.2.10. OpenShift . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.2.11. Sublime Text . . . . . . . . . . . . . . . . . . . . . . . 46

4.2.12. POP: Prototyping On Paper . . . . . . . . . . . . . . . 47

5. Migración de SwellRT a Android 49

5.1. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.1.1. Migración: Identificación y Solución de Problemas . . . 49

5.1.1.1. Construcción y Depuración . . . . . . . . . . 50

5.1.1.2. Conexión HTTP . . . . . . . . . . . . . . . . 51

5.1.1.3. Conexión WebSocket . . . . . . . . . . . . . . 53

5.1.1.4. Conexión final y Logging . . . . . . . . . . . . 55

5.1.1.5. Organización del código: Servicio Android . . 57

5.1.2. Dependencias . . . . . . . . . . . . . . . . . . . . . . . 59

5.1.3. Resultado de la Migración . . . . . . . . . . . . . . . . 60

6. Diseño de la Aplicación 63

6.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6.2. Brainstorming de ideas . . . . . . . . . . . . . . . . . . . . . . 63

6.3. Diseño Guiado Por Objetivos (DGO) . . . . . . . . . . . . . . 65

6.3.1. Investigación . . . . . . . . . . . . . . . . . . . . . . . 66

6.3.2. Investigación . . . . . . . . . . . . . . . . . . . . . . . 66

6.3.2.1. Intención Inicial: Prototipo básico . . . . . . . 66

6.3.2.2. Hipótesis de personas . . . . . . . . . . . . . 67

6.3.2.3. Entrevistas . . . . . . . . . . . . . . . . . . . 68

6.3.3. Modelado y Definición de Personas . . . . . . . . . . . 72

6.3.4. Definición de Escenarios y Requisitos . . . . . . . . . . 75

6.3.5. Framework de diseño . . . . . . . . . . . . . . . . . . . 77

6.3.5.1. Framework de interacción . . . . . . . . . . . 77



6.3.6. Verificación: Principios de Diseño . . . . . . . . . . . . 86

7. Arquitectura del Proyecto 91

7.1. Arquitectura de Wave . . . . . . . . . . . . . . . . . . . . . . 91

7.1.1. Modelo Conversacional Wave . . . . . . . . . . . . . . 92

7.1.2. Modelo de Contenidos SwellRT . . . . . . . . . . . . . 93

7.2. Arquitectura de la aplicación . . . . . . . . . . . . . . . . . . . 94

7.2.1. Base de datos . . . . . . . . . . . . . . . . . . . . . . . 95

7.2.1.1. political party . . . . . . . . . . . . . . . . . . 97

7.2.1.2. section . . . . . . . . . . . . . . . . . . . . . . 97

7.2.1.3. proposal . . . . . . . . . . . . . . . . . . . . . 97

7.2.1.4. comment . . . . . . . . . . . . . . . . . . . . 98

7.2.1.5. opinion . . . . . . . . . . . . . . . . . . . . . 98

7.2.2. Servicio Web REST . . . . . . . . . . . . . . . . . . . . 98

7.2.2.1. Arquitectura . . . . . . . . . . . . . . . . . . 100

7.2.2.2. Rutas . . . . . . . . . . . . . . . . . . . . . . 102

7.2.2.3. Controladores . . . . . . . . . . . . . . . . . . 103

7.2.3. Cliente Android . . . . . . . . . . . . . . . . . . . . . . 105

7.2.3.1. Interfaz Gráfica . . . . . . . . . . . . . . . . . 105

7.2.3.2. Estructuración de Programas Poĺıticos . . . . 110

7.2.3.3. Conexión y Peticiones a Service REST y Base
de Datos . . . . . . . . . . . . . . . . . . . . 113

7.2.3.4. Gestión de Usuarios: ID de Android . . . . . 115

7.2.3.5. Servicio Android, Conexión con Wave/SwellRT
y Gestión de Propuestas Colaborativas . . . . 115

8. Evaluación con Usuarios 121

8.1. Propósitos y objetivos de la evaluación . . . . . . . . . . . . . 121

8.2. Preguntas de evaluación . . . . . . . . . . . . . . . . . . . . . 121

8.3. Requisitos para los participantes de la evaluación . . . . . . . 122

8.4. Diseño experimental . . . . . . . . . . . . . . . . . . . . . . . 123



8.5. Lista de tareas a realizar . . . . . . . . . . . . . . . . . . . . . 123

8.6. Entorno y herramientas empleadas . . . . . . . . . . . . . . . 124

8.7. Tareas del moderador . . . . . . . . . . . . . . . . . . . . . . . 125

8.8. Resultados de la evaluación con los usuarios . . . . . . . . . . 125

8.8.1. Comentarios sobre la interfaz . . . . . . . . . . . . . . 126

8.8.2. Resultados de las tareas . . . . . . . . . . . . . . . . . 127

9. Resultados y Trabajo Futuro 129

9.1. Discusión de Resultados . . . . . . . . . . . . . . . . . . . . . 129

9.1.1. Resultados de la Evaluación con usuarios . . . . . . . . 130

9.2. Reparto de Trabajo entre los componentes del grupo . . . . . 132

9.3. Trabajo Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . 133

9.3.1. Mejoras a la versión actual . . . . . . . . . . . . . . . . 135

9.3.2. Nuevas caracteŕısticas . . . . . . . . . . . . . . . . . . 135

Conclusions 137

Conclusiones 139

A. Listados de Código Fuente 141

A.1. Migración de Wave a Android: SwellRT . . . . . . . . . . . . . 141

A.1.1. Esquema de conexión HTTP . . . . . . . . . . . . . . . 141

A.1.2. Esquema de conexión con AsyncTask . . . . . . . . . . 142

A.1.3. Esquema de uso de WAsync . . . . . . . . . . . . . . . 143

A.2. Servicio Web REST (Laravel) . . . . . . . . . . . . . . . . . . 144

A.2.1. Esquema de Rutas Simple . . . . . . . . . . . . . . . . 144

A.2.2. Esquema de Rutas Agrupadas . . . . . . . . . . . . . . 144

A.2.3. Esquema de Rutas de Propuestas Agrupadas . . . . . . 144

A.2.4. Esquema de Controlador de Propuestas . . . . . . . . . 145

A.3. Aplicación Android . . . . . . . . . . . . . . . . . . . . . . . . 145

A.3.1. Función de construcción del árbol de Programa Poĺıtico 145



A.3.2. Registrar Usuario en SwellRT . . . . . . . . . . . . . . 146

A.3.3. Crear nueva Wave (Model) en SwellRT . . . . . . . . . 148

A.3.4. Abrir Pad colaborativo en SwellRT . . . . . . . . . . . 150

Bibliograf́ıa 151



Índice de figuras

2.1. Tipos de Arquitecturas de Red . . . . . . . . . . . . . . . . . 8

2.2. Cliente Wave In A Box . . . . . . . . . . . . . . . . . . . . . . 11

2.3. Capturas de Google Docs . . . . . . . . . . . . . . . . . . . . . 11

2.4. Captura de TitanPad: Ejemplo de uso de EtherPad . . . . . . 12

2.5. Captura de Colorillo . . . . . . . . . . . . . . . . . . . . . . . 13

2.6. Captura de ShareLaTeX . . . . . . . . . . . . . . . . . . . . . 13

2.7. Capturas de Samepage . . . . . . . . . . . . . . . . . . . . . . 14

2.8. Capturas de Quip . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.9. Capturas de UPyD Parla . . . . . . . . . . . . . . . . . . . . . 16

2.10. Capturas de ]IURecuperaCórdoba . . . . . . . . . . . . . . . . 17

2.11. Capturas de PSOE Andalucia . . . . . . . . . . . . . . . . . . 18

2.12. Capturas de PP Canarias . . . . . . . . . . . . . . . . . . . . 19

2.13. Plaza Podemos utilizando la plataforma Reddit . . . . . . . . 21

2.14. Change.org · La mayor plataforma de peticiones del mundo . . 22

2.15. Creación colaborativa del programa de Ahora Madrid. . . . . . 24

2.16. Creación colaborativa del programa de Zaragoza en Común. . 24

2.17. Capturas de Appgree . . . . . . . . . . . . . . . . . . . . . . . 25

4.1. Nube de Tecnoloǵıas utilizadas en el Proyecto . . . . . . . . . 33

4.2. Arquitectura federada en SwellRT . . . . . . . . . . . . . . . . 36

4.3. Distribución Actual de Versiones Android (Fuente: Google) . . 43

4.4. Frameworks PHP más populares. Fuente: SitePoint . . . . . . 46

5.1. Ejemplo de Traza de Error en Logcat . . . . . . . . . . . . . . 52

5.2. Pantalla de Login de WaveAndroid . . . . . . . . . . . . . . . 56

5.3. Proceso de conexión WebSocket con Servicio . . . . . . . . . . 59

VII



5.4. Proceso de conexión Http con Servicio . . . . . . . . . . . . . 60

5.5. Esquema de Clases de SwellRT-Android con Servicio . . . . . 61

6.1. Capturas del brainstorming . . . . . . . . . . . . . . . . . . . 64

6.2. Estudiante universitario . . . . . . . . . . . . . . . . . . . . . 74

6.3. Activista poĺıtico . . . . . . . . . . . . . . . . . . . . . . . . . 74

6.4. Modelo de desarrollo de los prototipos. . . . . . . . . . . . . . 80

6.5. Primeros protitipos sobre programas electorales. . . . . . . . . 81

6.6. Prototipos para el desarrollo de propuestas. . . . . . . . . . . 82

6.7. Pantalla principal de la aplicación. . . . . . . . . . . . . . . . 85

6.8. Vista de categoŕıas. . . . . . . . . . . . . . . . . . . . . . . . . 86

6.9. Principios de diseño en la aplicación. . . . . . . . . . . . . . . 87

7.1. Arquitectura de Wave . . . . . . . . . . . . . . . . . . . . . . 92

7.2. Modelo Conversacional de Wave . . . . . . . . . . . . . . . . . 93

7.3. Modelo de Contenidos de SwellRT . . . . . . . . . . . . . . . . 94

7.4. Arquitectura general de la aplicación. . . . . . . . . . . . . . . 95

7.5. Modelo entidad-relación de la base de datos. . . . . . . . . . . 96

7.6. Arquitectura de Laravel . . . . . . . . . . . . . . . . . . . . . 101

7.7. Camino desde la ruta al método del controlador. . . . . . . . . 104

7.8. Esquema de Implementación de TopItem (Con vista de Section
y Proposal) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

7.9. Esquema de Implementación de Menú Izquierdo (Con vista
del Menú) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

7.10. Ejemplos de Codificación de Secciones y Subsecciones . . . . . 111

7.11. Esquema de estructura en árbol de Programa Poĺıtico . . . . . 112

7.12. Esquema de Clases de Conexión HTTP mediante AsyncTask . 114

7.13. Esquema de Uso de Wave/SwellRT . . . . . . . . . . . . . . . 117

7.14. Esquema de Registro en SwellRT . . . . . . . . . . . . . . . . 117

7.15. Esquema de Creación de Pad Colaborativo en SwellRT . . . . 118

7.16. Esquema de Apertura y Edición de Pad Colaborativo en SwellRT119

VIII



Índice de tablas

3.1. Software libre utilizado durante el desarrollo. . . . . . . . . . . 27

3.2. Patrones de diseño empleados en el proyecto. . . . . . . . . . . 32

4.1. Tecnoloǵıas usadas en el Proyecto . . . . . . . . . . . . . . . . 34

5.1. Dependencias de SwellRT-Android . . . . . . . . . . . . . . . 62

7.1. Funciones CRUD . . . . . . . . . . . . . . . . . . . . . . . . . 99

7.2. Códigos de estado de la respuesta del servidor . . . . . . . . . 100

7.3. Adapters, Views y Clases utilizadas en el proyecto . . . . . . . 110

8.1. Dificultad y tiempos de las tareas para el usuario del tipo
ciudadano. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

8.2. Dificultad y tiempos de las tareas para el usuario del tipo
activista social. . . . . . . . . . . . . . . . . . . . . . . . . . . 128

9.1. Reparto colaborativo de tareas. . . . . . . . . . . . . . . . . . 134



Abstract

Nowadays we live in a society of democratic change in which people begin
to take a decisive role in the political area. There are increasingly social
movements that proliferate due to the interest generated by taking part in
politics. This participation has been channeled by the emergence of new
technologies that allows to establish new ways for people to organize and
express their opinion. The vast majority of these new tools are developed in
a scope near to Web-based interfaces and interconnected network platforms.
Being as we are in a time subject to several electoral events that favours the
increased interest of people involved in politics, the development of such type
of tools is becoming increasingly necessary.

Keeping in mind this context, we contemplate the development of an appli-
cation that provides access to new ways of participation from mobile devices.
This application will have two clear objectives: to bring to the forefront poli-
tical programmes, which usually few people read, encouraging its reading and
discussion; and open a common space in which citizens express their alter-
native proposals to those put forward by the political parties that represent
us.

We will base on the use of already existing Open-Source technologies for co-
llaborative editing in real-time, adjusting them to mobile devices. Specifically
we will explore the use of Web-based platform Apache Wave, carrying out a
migration process that allows to take advantage of its potential in Android-
based devices. This migration supposes an additional work that involves an
effort to research into the development of an innovative platform, because
there is no equivalent free software currently on Android. By using this tech-
nology, users will have the opportunity to compose real-time collaborative
texts.

As a result for this work we will develop a first version of the application
which, as a proof of concept, will make use of the features described above.
Thus, the ultimate aim we set out for this project is to put into practice its
usefulness during future electoral events.

Keywords: Collaborative Writing, Politics, Democracy, Citizen Participa-
tion, Real-Time, Android, Apache Wave, Elections, Election Programme,
Citizen Proposals.

IX





Resumen

Actualmente vivimos en una sociedad de cambio democrático en la que las
personas comienzan a adquirir un papel determinante en el terreno poĺıtico.
Son cada vez más los movimientos sociales que proliferan a ráız del interés
generado por participar en politica. Esta participación se ha visto canalizada
por la aparición de nuevas tecnoloǵıas que permiten establecer nuevas formas
para que las personas se organicen y expresen su opinión. La gran mayoŕıa de
estas nuevas herramientas se desarrollan en un ámbito cercano a plataformas
interconectadas en red y basadas en una interfaz Web. Encontrándonos en
un momento sujeto a varias citas electorales que propicia el aumento del
interés de las personas por involucrarse en poĺıtica, el desarrollo de este tipo
de herramientas se hace cada vez más necesario.

Teniendo en cuenta este contexto, se plantea el desarrollo de una aplicación
que proporcione acceso a nuevas formas de participación desde dispositivos
móviles. Dicha aplicación tendrá dos objetivos claros: poner en un primer
plano los programas electorales (que normalmente pocas personas leen) in-
centivando su lectura y debate; y abrir un espacio común en el que la ciuda-
dańıa exprese sus propuestas alternativas a las soluciones expuestas por los
partidos poĺıticos que les representan.

Nos basaremos en el uso de tecnoloǵıas de Software libre ya existentes de edi-
ción colaborativa en tiempo real, adaptándolas a dispositivos móviles. Con-
cretamente se explorará el uso de la plataforma Web Apache Wave, llevando
a cabo un proceso de migración que permita explotar su potencial en dis-
positivos basados en Android. Esta migración supone un trabajo adicional
que conlleva un esfuerzo de investigación y desarrollo de una plataforma in-
novadora, ya que no existe una tecnoloǵıa de software libre equivalente en
Android actualmente. Haciendo uso de esta tecnoloǵıa los usuarios tendrán
la oportunidad de redactar textos colaborativos en tiempo real.

Como resultado de este trabajo se desarrollará una primera versión de la
aplicación que, a modo de prueba de concepto, haga uso de las funcionalida-
des antes descritas. De esta manera el objetivo final que nos planteamos es
poner en práctica su uso durante futuras citas electorales.

Palabras Clave: Escritura Colaborativa, Poĺıtica, Democracia, Participa-
ción Ciudadana, Real-Time, Android, Apache Wave, Elecciones, Programas
Electorales, Propuestas Ciudadanas.

XI





Caṕıtulo 1

Introducción

A continuación se exponen algunas observaciones previas acerca del por
qué de DemoCritics y la idea detras de la aplicación. Posteriormente se de-
tallan los objetivos generales del proyecto y la estructura de este documento.

1.1. Antecedentes

En los siguientes párrafos se discutirá acerca de una serie de consideraciones
sobre el estado actual de la poĺıtica y la democracia. Se centrará la discusión
sobre todo en su relación con las nuevas tecnoloǵıas como herramientas ca-
paces de cambiar la manera en la que se conciben ambas disciplinas. Después
se discutirá la intención detrás del desarrollo de DemoCritics.

1.1.1. Marco teórico: Poĺıtica en el mundo de la In-
formática

A primera vista se puede pensar que la poĺıtica no parece entusiasmar a las
personas dedicadas al mundo de la informática. Se puede ubicar la poĺıtica
como una parte de las ciencias sociales o la actividad poĺıtica, situando la
informática en ciencias exactas o formales. Pero pensando en factores como la
gestión de los privilegios de una aplicación entre los que se define de alguna
forma una jerarqúıa, indirectamente se estará haciendo poĺıtica. También
se pueden encontrar caracteŕısticas poĺıticas en el diseño relacional de una
base de datos. Definiendo los campos de una base de datos se pueden ver
algunos valores como el sexo, la nacionalidad, la edad o incluso las relaciones
o restricciones que existen entre las tablas. Se estarán definiendo unas reglas
básicas de funcionamiento de la base de datos establecidas por unos principios
poĺıticos.

Adentrándose en el mundo de las Licencias (copia, modificación, distribución,
etcétera) en el desarrollo de Software se encuentra más contenido poĺıtico.
Licencias que determinan el uso de un tipo de Software, ya sea para compartir,

1



CAPÍTULO 1. INTRODUCCIÓN

vender o distribuir copias. Multitud de ”reglas poĺıticas” definidas en un
documento de licencia de uso. Aśı como las restricciones que se establecen en
la metodoloǵıa del desarrollo orientado a objetos, estableciendo las relaciones
de herencia, restricción de métodos, variables, etcétera.

Regresando a la actualidad y basándose en no muy lejanos acontecimientos
pasados, se ha óıdo cómo algunos gobiernos recopilan datos de la actividad
de los usuarios en las redes sociales [1], analizando todo el contenido que
generan. Incluso cómo algunas aplicaciones móviles piden aprobar permisos
con los que operar libremente en los dispositivos.

Se observa por tanto que la poĺıtica está más integrada en la informática de
lo que parece, sobre todo si se deja a un lado la informática más cient́ıfica
y formal y se pasa a la informática más social, la de los gobiernos, la de los
negocios o la de las relaciones sociales.

1.1.2. Idea detrás de DemoCritics

La idea a desarrollar está generada en una época en la que la poĺıtica parece
haber despertado el interés de una parte considerable de la ciudadańıa. Podŕıa
ser por tanto una herramienta útil para participar en temas poĺıticos de forma
sencilla y atractiva. Dejando aśı atrás los tópicos a menudo escuchados de 2o
no entiendo de poĺıtica”, ”la poĺıtica es aburrida”, ”no sé a quién votar” o
”no he léıdo nunca un programa electoral” entre otros.

La herramienta ofrece una nueva forma de participar en la poĺıtica y de
llevar a los ciudadanos los programas electorales expuestos por las diferentes
formaciones poĺıticas (Ver Sección 2.2.1). De forma que, para potenciar el
uso social de la aplicación, los ciudadanos podŕıan leer aquellos puntos de
los programas más vistos, debatidos, comentados, etc. Aśı, cualquier usua-
rio tendŕıa a su disposición todos los programas electorales en su
bolsillo, por lo que no tendŕıa que ir a la página web de cada formación
poĺıtica y descargarse un documento de 200 páginas. Pensamos que es-
ta forma tradicional de presentar un programa poĺıtico en un solo
documento en un mundo donde las posibilidades de comunicarnos
se han desarrollado exponencialmente mediante las nuevas tecno-
loǵıas no es la mejor manera de generar interés por su lectura y la
implicación en poĺıtica de las personas.

Por otra parte, y teniendo en cuenta la tendencia actual de los nuevos movi-
mientos ciudadanos de elaborar programas poĺıticos en base a propuestas de
los ciudadanos, la aplicación también debe ofrecer alguna manera de

2



CAPÍTULO 1. INTRODUCCIÓN

realizar Propuestas y debatirlas entre todos. De esta forma tanto la
ciudadańıa como las formaciones poĺıticas pueden saber en cualquier momen-
to cuáles son las principales preocupaciones de los ciudadanos y qué medidas
o soluciones proponen para resolverlas. Además se pueden aprovechar
las caracteŕısticas de Wave para realizar estas Propuestas de forma
colaborativa y en tiempo real, aportando un valor diferenciador respecto
a las actuales soluciones desarrolladas para Web (Ver sección 2.2.2). Para ello
será necesario estudiar primero la migración de Wave/SwellRT a Android con
el objetivo de poder utilizar esta tecnoloǵıa en DemoCritics.

Por tanto, desde un primer punto de vista subjetivo, la aplicación esta di-
vidida en dos partes. Por un lado se tiene la presentación estructurada de
los programas poĺıticos que presentan las formaciones poĺıticas. Y por otro
todas las propuestas que elaboran de forma colaborativa los ciudadanos, ya
sea individualmente o en colectivos sociales.

1.2. Objetivos del Proyecto

El objetivo principal de este proyecto es desarrollar una aplicación Android
de utilidad social y que haga uso de una tecnoloǵıa poco utilizada en estas
plataformas móviles como es la colaboración en tiempo real, que desde hace
unos años śı que viene estando más presente en plataformas Web. Para ello
primero se evaluará la tecnoloǵıa existente en el proyecto SwellRT (basado
en Apache Wave) y se adaptará dicha tecnoloǵıa para poder hacer uso de
ella de forma nativa desde Android. Después se discutirán posibles ideas de
aplicación que puedan hacer uso de esta tecnoloǵıa y se diseñará y desa-
rrollará una primera versión estable de esa idea de aplicación Android que
pueda ser evaluable por usuarios. También se estudiará la viabilidad de se-
guir desarrollando a futuro la aplicación con vistas a conseguir un producto
que podamos poner a disposición del público en el marketplace de Android.

1a parte: Migración de Wave (SwellRT) a Android

• Proporcionar un entorno de colaboración en tiempo real federado
para Android basado en SwellRT.

2a parte: Creación de la aplicación Android.

• Desarrollar una aplicación que recopile y permita interactuar con
los programas electorales de los partidos poĺıticos.

3



CAPÍTULO 1. INTRODUCCIÓN

• Desarrollar una aplicación que permita la participación colecti-
va de ciudadanos mediante propuestas colaborativas editables en
tiempo real.

1.3. Estructura del Documento

En esta memoria se han querido reflejar los aspectos más destacados del
proceso de desarrollo de este Trabajo de Fin de Grado. Aunque a lo largo
del documento se detallen aspectos técnicos queremos dejar patente que no
se trata de un tutorial de cómo funciona Wave o Android. Aunque a veces
se entre en mayor detalle por cuestiones de claridad a la hora de entender el
funcionamiento de la tecnoloǵıa, se anima al lector si quiere profundizar más
en el tema a que haga uso de las múltiples referencias bibliográficas que se
incluyen en este documento.

A lo largo de este documento el lector se encontrará con una estructura ba-
sada en caṕıtulos en los que se irán detallando distintas facetas del desarrollo
del proyecto:

Caṕıtulo 2 - Estado del Arte: se hace un pequeño análisis de las
caracteŕısticas de actuales soluciones software que hacen uso de tecno-
loǵıas de colaboración en tiempo real y de aplicaciones dedicadas a la
participación poĺıtica.

Caṕıtulo 3 - Metodoloǵıas del Proyecto: se exponen brevemente
las metodoloǵıas empleadas durante todo el desarrollo del proyecto.

Caṕıtulo 4 - Tecnoloǵıas del Proyecto: se repasan las tecnoloǵıas
y herramientas utilizadas durante todo el desarrollo del proyecto.

Caṕıtulo 5 - Migración de SwellRT a Android: se exponen aspec-
tos destacados acerca de esta primera parte del proyecto, que pretende
conseguir utilizar la tecnoloǵıa de Wave/SwellRT en Android.

Caṕıtulo 6 - Diseño de la Aplicación: se detallan algunos aspectos
acerca de la investigación previa y el diseño mediante Diseño Guiado
por Objetivos (DGO) de DemoCritics.

Caṕıtulo 7 - Arquitectura del Proyecto: se indaga en aspectos
técnicos destacados de la organización de SwellRT y DemoCritics.

4



CAPÍTULO 1. INTRODUCCIÓN

Caṕıtulo 8 - Evaluación con usuarios: se explican los procesos de
evaluación con los usuarios de la versión desarrollada de DemoCritics,
aśı como sus resultados.

Caṕıtulo 9 - Resultados y Trabajo Futuro: se discuten los resul-
tados obtenidos tras la realización del proyecto. Se discute también el
reparto de trabajo y los siguientes pasos a realizar con el objetivo de
mejorar o cambiar DemoCritics.

Conclusiones: se extraen una serie de conclusiones acerca de lo con-
seguido tras completar este Trabajo de Fin de Grado.

5





Caṕıtulo 2

Estado del Arte

En este caṕıtulo se procederá a explorar las diferentes soluciones Software
que se encuentran actualmente mercado. Se analizará cada una de ellas de
forma resumida, obteniendo una visión general de las caracteŕısticas que lo
componen y la funcionalidad que ofrece.

Las plataformas quedarán dividas en dos secciones principales. Por un lado
se analizarán las soluciones Software que proporcionan edición de contenidos
en tiempo real (ver sección 2.1), desde un editor de texto colaborativo hasta
una pizarra de dibujo. La segunda parte (ver Sección 2.2) explorará herra-
mientas de contenido poĺıtico relacionado por una parte con las candidaturas
o programas electorales de unas elecciones, y por otra parte con herramientas
de participación ciudadana y activismo social.

2.1. Edición Colaborativa en Tiempo Real

En esta sección se verán algunas de las soluciones disponibles actualmente
que, al igual que Wave, permiten editar contenido de forma colaborativa y en
tiempo real. Este contenido puede ser muy variado, aunque lo más usual suele
ser proporcionar edición de texto en tiempo real mediante el uso de Trans-
formaciones Operacionales (OT) [2]. Sin embargo, todas estas plataformas
utilizan una arquitectura de servidor centralizado para ofrecer estas funcio-
nalidades. Las soluciones no centralizadas actuales incluyen las arquitecturas
P2P y federadas [3]. En las P2P (”Peer to Peer”) todos los participantes
de la red son iguales (”peers”) a efectos de controlar los datos que circulan
por la red y el Software/Hardware utilizado, pudiendo interactur directamen-
te entre ellos. La arquitectura federada es una solución no centralizada que
permite que múltiples nodos (servidores) centrales interactúen entre si, pu-
diendo los usuarios (clientes) pertenecer a cualquier nodo sin que ello impida
que se comuniquen con otros nodos distintos al que pertenecen. Wave utiliza
una arquitectura federada en la que no existe un único servidor central que
controle los datos de los usuarios (Ver Sección 4.1.3.1).

7



CAPÍTULO 2. ESTADO DEL ARTE

Figura 2.1: Tipos de Arquitecturas de Red

Para desarrollar este proyecto se ha escogido Wave porque es la
única plataforma de Software libre que permite utilizar la tecno-
loǵıa de colaboración en tiempo real mediante una arquitectura no
centralizada de tipo federado.

De esta manera, primero se verán las principales herramientas de desarrollo
(APIs) más utilizadas actualmente, para después pasar a ver algunas de las
plataformas que hacen uso de esta tecnoloǵıa. En su mayoŕıa son para Web,
aunque existen unas pocas para Android.

2.1.1. APIs Centralizadas

La mayor parte del desarrollo de tecnoloǵıas de Colaboración en Tiempo
Real (RTC) se realizan mediante APIs que son propiedad de determinadas
compañias y que no utilizan una arquitectura federada, sino que toda la
información pasa por un servidor central que controla el RTC. A continuación
veremos algunas de las más utilizadas hoy en d́ıa.

2.1.1.1. Google Realtime API

Google Drive Realtime API [4] permite construir aplicaciones de colabo-
ración en tiempo real utilizando la tecnoloǵıa de Transformaciones Opera-
cionales (OT) [2] presente en Google Docs. Utiliza JavaScript para poder
construir construir en nuestro cliente web un modelo de datos (Realtime Da-
ta Model) que se guarda en sus servidores y gestiona automaticamente los
cambios realizados por cualquiera de los usuarios que colaboran en tiempo
real. Estos cambios en el modelo son notificados al servidor y al resto de
usuarios mediante eventos que se lanzan al modificar los datos sobre los que
se está colaborando. Para utilizarlo es necesario tener cuenta en la Conso-
la de Desarrolladores de Google y activar el uso de esta API con nuestras
credenciales de usuario. Existe asimismo una versión (privativa) de esta API
compatible con Android.

8



CAPÍTULO 2. ESTADO DEL ARTE

2.1.1.2. Microsoft RTC Client API

Microsoft RTC Client API [5] permite construir aplicaciones que permitan
realizar llamadas de audio/video o sesiones de mensajeŕıa instantánea (IM)
de texto por Internet y en tiempo real. Las aplicaciones se deben escribir en
C++ o Visual Basic y pueden ser utilizadas tanto en PC como en dispositivos
móviles siempre que ejecuten un sistema operativo Windows.

2.1.1.3. WebRTC

WebRTC [6] (Web Real-Time Communication) es un API de Software Li-
bre (bajo licencia BSD) actualmente en desarrollo por Google y la World
Wide Web Consortium (W3C) y que pretende dotar a los navegadores web
de capacidades de comnicación en tiempo real entre śı sin necesidad de plu-
gins externos. En la actualidad se encuentra en su versión 1.0 y soporta los
navegadores Firefox y Chrome.

2.1.1.4. Mozilla TogetherJS

Mozilla TogetherJS [7] es una libreŕıa gratuita y de código libre (bajo licen-
cia pública Mozilla v2) que permite añadir capacidades de colaboración en
tiempo real a una página web. Utiliza WebRTC y webSockets para estable-
cer comunicaciones peer-to-peer (P2P) entre dos o más navegadores Web.
No proporciona alamcenamiento persistente de los datos y es necesario te-
ner un Servidor que establezca la conexión. Con esta herramienta se puede
editar texto en tiempo real (usando Transformaciones Operacionales), esta-
blecer chats de audio/video y sincronizar el contenido de los navegadores.
Está disponible en GitHub [8] para contribuir a su desarrollo.

2.1.1.5. ShareJS

ShareJS [9] es una plataforma de Software Libre (bajo licencia MIT) que
dispone de un pequeño servidor basado en Node.js y una libreŕıa de clien-
te JavaScript que permiten la edición colaborativa de contenido mediante
Transformaciones Operacionales. Permite actuar sobre objetos JSON o so-
bre texto plano. Está disponible en GitHub para scontribuir a su desarrollo.

9



CAPÍTULO 2. ESTADO DEL ARTE

2.1.1.6. Goodow

Goodow [10] es un framework de código libre de reciente desarrollo que pro-
porciona un API muy similar a Google Real-Time API (Ver Sección 2.1.1.1)
para colaboración en tiempo real mediante el uso de Transformaciones Ope-
racionales. Dispone asimismo de dos clientes básicos para Android e iOS,
utilizando una implementación del Servidor propia.

2.1.2. Plataformas Web y Android

En las siguientes secciones veremos algunas de las plataformas Web y Android
que hacen uso de tecnoloǵıas de Colaboración en Tiempo Real.

2.1.2.1. Wave: Wave In A Box (WIAB)

Wave In a Box (WIAB) [11] es el código fuente liberado por Google y com-
pletado por la comunidad de Apache tras pasar el proyecto a sus manos en
el año 2012. Al igual que el resto del código de la tecnoloǵıa que heredó de
Google, está implementado en Java usando OpenJDK [12]. La instalación
trae consigo un cliente web desarrollado en Java usando el framework Goo-
gle Web Toolkit (GWT) [13], lo que genera código JavaScript ejecutable en el
navegador. Este cliente Web sirve como prueba de concepto de las funcionali-
dades básicas del Modelo Conversacional de Wave, pudiendo gesionar waves,
usuarios y extensiones. Actualmente cualquiera puede descargar y desplegar
WIAB en su ordenador siguiendo los pasos que nos proporcionan en su wiki
[14]. La aplicación se distribuye en forma de código fuente, accesible entre
otras formas desde su repositorio de GitHub [15]. Existen asimismo servido-
res de prueba ya desplegados en Internet sobre los que se puede observar el
funcionamiento de WIAB [16].

2.1.2.2. Google Docs

Google Docs [17] es la plataforma de Google para edición de documentos de
forma colaborativa y en Tiempo Real usando su API Realtime (Ver Sección
2.1.1.1). Permite que varios usuarios con cuenta de Google creen y editen
colaborativamente un documento a la vez. Puedes ver los cursores de cada
usuario e interactuar con ellos mediante un chat. También permite escribir
sugerencias a modo de notas en el margen sobre lo ya escrito. Dispone de
versión web y móvil, pudiendo interactuar entre ellas sin problemas.

10



CAPÍTULO 2. ESTADO DEL ARTE

Figura 2.2: Cliente Wave In A Box

(a) Interfaz Web (b) Interfaz Android

Figura 2.3: Capturas de Google Docs

11



CAPÍTULO 2. ESTADO DEL ARTE

Figura 2.4: Captura de TitanPad: Ejemplo de uso de EtherPad

2.1.2.3. Etherpad

Etherpad [18] es un editor colaborativo en tiempo real de Software Libre
(bajo licencia Apache 2.0). Permite a varios autores editar a la vez un mis-
mo documento de texto, resaltando en distintos colores lo editado por cada
persona y con la opción de un chat para comunicarse entre śı. Existen múlti-
ples servicios que hacen uso de este editor, siendo uno de las más conocidas
TitanPad [19].

2.1.2.4. Colorillo

Colorillo [20] es una aplicación web básica de dibujo colaborativo en tiempo
real. Cualquier usuario puede empezar a dibujar sobre un nuevo lienzo en
blanco con diversos colores y compartir este lienzo con otros usuarios para
dibujar entre todos. De cada usuario podemos ver su procedencia aproximada
sobre un mapa y el color que actualmente está utilizando. Existe también
opción para chatear con otros usuarios. Los dibujos se pueden descargar y
tienen todos licencia Creative Commons BY 3.0.

2.1.2.5. ShareLaTeX

ShareLaTeX [21] es un editor web colaborativo de documentos escritos en
LaTeX en tiempo real. Permite elaborar documentos LaTeX entre varias per-

12



CAPÍTULO 2. ESTADO DEL ARTE

Figura 2.5: Captura de Colorillo

Figura 2.6: Captura de ShareLaTeX

sonas, ofreciendo una interfaz que incluye una previsualización del resultado
en PDF. Desde 2014 es Software libre (bajo licencia AGPL v3) y cualquie-
ra puede descargarselo de GitHub e instalar su propio servidor (escrito en
Node.js) de ShareLaTeX. En su web ofrecen también opciones de pago con
extras como un control de versiones o sincronización con Dropbox.

13



CAPÍTULO 2. ESTADO DEL ARTE

(a) Interfaz Web (b) Interfaz Android

Figura 2.7: Capturas de Samepage

2.1.2.6. Samepage

Samepage [22] es una aplicación, tanto para web como para plataformas móvi-
les (Android e iOS), que permite crear documentos que pueden ser editados
de forma colaborativa y en tiempo real por múltiples usuarios. Para ello es
necesario solo es tener una cuenta de samepage. Tanto el cliente web como
el móvil permiten interactuar entre ellos para crear nuevas páginas, editar
texto y hacer comentarios, aunque la versión web permite también añadir
tablas, imágenes y archivos.

2.1.2.7. Quip

Quip [23] es una aplicación para dispositivos móviles (Android e iOS) desa-
rrollada con el objetivo de aumentar la productividad en los trabajos en
grupo. Permite elaborar documentos, hojas de cálculo y listas de tareas com-
partidas y editables de forma colaborativa en tiempo real, pudiendo realizar
también comentarios sobre ellas. Dispone también de una versión web, pero
es necesario tener cuenta para usarla.

14



CAPÍTULO 2. ESTADO DEL ARTE

(a) Escritorio (b) Edición de texto (c) Comentarios

Figura 2.8: Capturas de Quip

2.2. Aplicaciones de Participación Poĺıtica y

Ciudadana

En esta sección exploraremos algunas de las principales aplicaciones informáti-
cas que existen en la actualidad destinadas a la participación ciudadana en
propuestas, lectura de programas electorales o divulgación de candidaturas.

2.2.1. Programas Poĺıticos

En la actualidad no existe ningún tipo de aplicación móvil orientada a debatir
los programas electorales de los partidos poĺıticos en su conjunto. Concreta-
mente no existe ningún tipo de plataforma que agrupe en un solo sitio los
programas electorales de las diferentes candidaturas. Lo más parecido que
hemos podido encontrar han sido aplicaciones elaboradas por un partido
poĺıtico, orientadas a dar a conocer su candidatura. En ellas podemos ver
normalmente, entre otros, la presentación de la candidatura, v́ıdeos propa-
gand́ısticos y el programa electoral.

Pasamos ahora a analizar algunas de las aplicaciones móviles encontradas,
identificando en cada caso aspectos e ideas que nos han resultado positivos
y negativos.

15



CAPÍTULO 2. ESTADO DEL ARTE

2.2.1.1. UPyD Parla

La aplicación presenta [24] al candidato de UPyD Carlos Alt Bustelo para
la alcald́ıa de Parla. Se trata de una alicación divulgativa donde podemos
conocer todo lo esencial de la candidatura de UpyD para las elecciones del
municipio de Parla en Mayo de 2015: los candidatos, el programa, v́ıdeos,
etc.

(a) Indice Programa (b) Sección Programa (c) Candidatos

Figura 2.9: Capturas de UPyD Parla

- Aspectos positivos:

Presentación de Programa Electoral estructurado con Indice inicial.

El Programa se lee dentro de la app, no nos lleva a leer el programa en
PDF de la web.

Presentación de una Sección del Programa Electoral de forma resumida,
teniendo la opción de leer la sección entera al pulsar un botón.

- Aspectos negativos:

Posee una sección llamada ”Memes” cuyo nombre no se entiende ya
que se limita a mostrar carteles propagand́ısticos de la candidatura.

16



CAPÍTULO 2. ESTADO DEL ARTE

2.2.1.2. ]RecuperaCórdoba

Esta aplicación [25] presenta la candidatura de Pedro Garćıa de Izquierda
Unida a la provincia de Córdoba, informando de su propuesta de gobierno
de forma resumida. En la aplicación podremos encontrar la lista de los can-
didatos propuestos a la comunidad cordobesa, el programa electoral de la
formación, las propuestas del partido, noticias de última hora y v́ıdeos.

(a) Indice Programa (b) Sección Programa (c) Candidatos

Figura 2.10: Capturas de ]IURecuperaCórdoba

- Aspectos positivos:

Interfaz limpia y sencilla de diseño plano.

Consistencia en la aplicación: la información se presenta siempre en
formato de lista ofreciendo los minimos datos necesarios sin sobrecargar
de información al usuario.

Menú lateral disponible en cualquier pantalla con las principales accio-
nes de la aplicación: Candidatos, Programa, Videos y Noticias.

El programa electoral está estructurado en un indice primer nivel y a
veces con segundo nivel.

Aporta la opción de ver el programa completo.

17



CAPÍTULO 2. ESTADO DEL ARTE

- Aspectos negativos:

Utiliza a veces iconos cuyo proposito no se entiende: ¿Un avión de papel
para noticias? ¿Un ”a>z” para la lista de candidatos?

Las distintas secciones se abren dentro de la aplicación, pero da acceso
a una navegación lateral por las páginas del PDF del programa en
cuestión.

Si haces zoom en una sección no permite pasar de página.

2.2.1.3. PSOE Andalućıa

Esta aplicación [26] presenta la candidatura del PSOE a la junta de Andalućıa
para las elecciones del 22 de Marzo, promocionando básicamente su programa
electoral y a la candidata Susana Dı́az. Permite también estar al d́ıa de
noticias y eventos relacionados con dicha candidatura.

La navegación por el programa, aunque estructurada en un primer nivel, se
realiza directamente visualizando páginas que parecen extraidas del programa
en PDF.

(a) Pantalla Principal (b) Indice Programa (c) Sección Programa

Figura 2.11: Capturas de PSOE Andalucia

- Aspectos positivos:

18



CAPÍTULO 2. ESTADO DEL ARTE

Posee un indice de primer nivel para estructurar el programa.

- Aspectos negativos:

La interfaz y los botones no se adaptan al tamaño de pantalla y per-
manecen de un tamaño pequeño que dificulta la interacción.

El programa electoral se visiona en forma de una página que parece
descargada directamente de la version PDF y que permanece en un
tamaño pequeño e ilegible, no permitendo tampoco hacer zoom. En
general, la interfaz parece hecha para una web más que para un móvil.

2.2.1.4. PP Canarias

La delegación del Partido Popular en Canarias presenta su aplicación móvil
[27] para promocionar a sus candidatos para las elecciones autonómicas y
municipales de Mayo de 2015. La aplicación nos avisará de los eventos elec-
torales, podremos consultar los candidatos, novedades, galeŕıa de imágenes
y por supuesto ver el programa electoral.

(a) Pantalla Principal (b) Programas (c) Candidatos

Figura 2.12: Capturas de PP Canarias

- Aspectos positivos:

19



CAPÍTULO 2. ESTADO DEL ARTE

Interfaz limpia y atractiva con una organización clara en secciones que
aparecen en una barra inferior al estilo de iOS.

- Aspectos negativos:

Aunque dispone de una sección para programas electorales, no dispone
de ellos en local, si no que te obliga a abrir un navegador para ver la
versión entera en PDF.

El problema de la barra inferior de menús es que quita espacio al con-
tenido principal. Se podŕıa haber puesto el menú en alun sitio menos
intrusivo.

2.2.2. Participación Ciudadana

Centrándonos en la participación ciudadana ya sea mediante la generación de
Propuestas, el desarrollo colaborativo de programas o la recogida de firmas,
existen numerosos portales en Internet y aplicaciones móviles destinadas a
ello. Realizaremos un breve repaso a las aplicaciones más destacadas.

2.2.2.1. Reddit

Reddit [28] es una plataforma web de código libre donde los usuarios pueden
crear temas, propuestas o compartir enlaces web a otros sitios. A primera
vista puede parecer un foro, aunque la principal diferencia respecto a éste
último radica en que otros usuarios pueden votar a favor o en contra de
los enlaces, haciendo que el sistema los haga aparecer como más o menos
destacados. A esto lo denominan ”filtrado colaborativo” pues de esta forma
los temas de conversación, enlaces, o propuestas aparecerán en el orden que
haya escogido la comunidad según la puntuación positiva o negativa que le
hayan dado. En principio el uso de reddit está destinado a todo tipo de temas,
entre los que podemos encontrar algunos ejemplos fuertemente relacionados
con la participación ciudadana. Es el caso de Plaza Podemos [29]: un espacio
utilizado para que la ciudadańıa pueda expresar sus propuestas, compartir
noticias relacionadas con la actualidad poĺıtica o debatir aquellos temas que
más les preocupan. Aśı, aunque no seamos participantes de reddit, de un
simple vistazo podemos saber qué es lo más debatido por la ciudadańıa, las
propuestas que quieren llevar a cabo en en el gobierno o cuáles son los temas
que más les preocupan.

20



CAPÍTULO 2. ESTADO DEL ARTE

Figura 2.13: Plaza Podemos utilizando la plataforma Reddit

- Aspectos positivos:

Opción de filtrado por tipos de contenido (propuestas, noticias...) y
ordenación de distintas formas (nuevos, populares, activos...)

Sistema de votación sencillo desde la propia previsualización del con-
tenido mediante flechas (arriba y abajo), pudiendo ver entre ellas el
número actual de votos.

- Aspectos negativos:

Para un usuario que lo usa por primera vez puede resultar confuso que
haya contenido redactado con usuarios mezclado con enlaces a noticias
externas.

2.2.2.2. Change.org

Change.org [30] es un portal web que permite lanzar múltiples peticiones
de cambio en Internet. Podŕıamos definirlo como la evolución de la recogida

21



CAPÍTULO 2. ESTADO DEL ARTE

Figura 2.14: Change.org · La mayor plataforma de peticiones del mundo

de firmas en la calle: cualquiera puede realizar una petición para solicitar
el apoyo de otros. Las personas que decidan apoyar la petición, dejarán sus
datos personales y constarán entre el número de personas que han firmado
a favor de la petición. Una vez que han alcanzado un número objetivo de
apoyos se procede a entregar las firmas digitales al organismo, persona o
entidad a la que va destinada la petición.

Por ejemplo: en mayo de 2011, en relación con las movilizaciones del Movi-
miento 15-M y Democracia Real Ya, y ante el desalojo por los Mossos de
Esquadra se llevó a cabo la petición “Exige la dimisión fulminante del Con-
seller de Interior Felip Puig por la violencia utilizada en Pza. Catalunya”.

Desde su creación en 2007, Change.org ha logrado muchas de sus peticiones
demandadas entre los que se incluyen la atención de pacientes con enfer-
medades complejas, protección sobre animales y medio ambiente, derechos
públicos, leyes, etc.

- Aspectos positivos:

Página principal con peticiones cuyo objetivo de firmas se ha consegui-
do (”victoria”) y las más destacadas aun por conseguir.

De cada petición se muestra un ”preview” con los aspectos más desta-

22



CAPÍTULO 2. ESTADO DEL ARTE

cados: foto, titulo, autor, número de firmas y fecha de creación.

- Aspectos negativos:

Aunque existen filtros para peticiones (Destacadas, Populares y Re-
cientes) ¿de qué depende esta clasificación? No queda claro cómo se
elige la opción en dicha lista de peticiones,

2.2.2.3. Programas Colaborativos de Ahora Madrid y Zaragoza
en Común

Para las pasadas elecciones municipales del 24 de Mayo, la candidatura de
unidad popular Ahora Madrid, desarrolló una plataforma en la web para
elaborar su programa electoral de forma colaborativa. En esta plataforma,
cualquier usuario teńıa la oportunidad de explorar las propuestas por cate-
goŕıa o por distrito. De tal forma que podŕıa debatirlas, puntuarlas o crear
sus propias propuestas. Aśı las propuestas más valoradas por la comunidad,
seŕıan llevadas al programa final para las elecciones municipales del 24 de
Mayo.

El resultado final fue determinar las cinco propuestas más votadas que fueron
incluidas en el programa final como medidas urgentes para realizar en los 100
primeros d́ıas de gobierno.

También utilizaron una plataforma similar en la candidatura zaragozana de
unidad popular Zaragoza en Común [31].

- Aspectos positivos:

Las propuestas están organizadas por distintos temas: ”Ejes temáticos”
en el caso de Zaragoza en Común y ”Areas y Objetivos” en el caso de
Ahora Madrid.

En ambos casos se puede filtrar la lista de propuestas de distintas for-
mas (”Más valoradas”, ”Más consenso” y ”Más debatidas”)

En el ”preview” de la propuesta se muestra el número de comentarios
y el porcentaje de votos positivos en relación al número total de votos
recibidos.

- Aspectos negativos:

En cada propuesta se muestra un número a la izquierda que no explica
lo que significa (entendemos que es el número de votos a favor).

23



CAPÍTULO 2. ESTADO DEL ARTE

Figura 2.15: Creación colaborativa del programa de Ahora Madrid.

Figura 2.16: Creación colaborativa del programa de Zaragoza en Común.

24



CAPÍTULO 2. ESTADO DEL ARTE

2.2.2.4. Appgree

Appgree[32] es una plataforma desarrollada con el objetivo de poner a gran-
des grupos de personas de acuerdo en poco tiempo. Está disponible tanto
para web como para móviles y permite que sus usuarios lancen propuestas
y debatan sobre cualquier tema pudiendo votar y alcanzar un consenso, ob-
teniendo los resultados de dicha votación casi en tiempo real gracias a un
algoritmo estad́ıstico desarrollado por ellos llamado DemoRank[33].

En la aplicación podemos acceder a una lista de canales: que aglutinan en-
cuestas, propuestas y preguntas (ya sea de respuesta abierta o de votación
entre dos o mas opciones), pudiendo votar y ver los resultados actuales de
votación y respuestas. Para fomentar la participación potencian mucho el
uso de listas de preguntas más candentes y recientes. Además se pueden
compartir preguntas por redes sociales para aumentar su difusión.

(a) Canal (b) Pregunta Múltiple (c) Pregunta Abierta

Figura 2.17: Capturas de Appgree

- Aspectos positivos:

Interfaz limpia de colores planos (blanco y azul) con pantalla principal
de ultimas preguntas destacadas.

Organización por canales temáticos de las preguntas.

25



CAPÍTULO 2. ESTADO DEL ARTE

Opción de marcar canales como favoritos para poder seguirlos y ser
notificados de las últimas preguntas añadidas.

- Aspectos negativos:

Las preguntas se organizan por antigüedad (activas y no activas) pero
se navega de abajo hacia arriba, cuando uno esperaria hacerlo al revés.

Los tipos de preguntas (abiertas, de respuesta múltiple, de śı o no,
encuestas...) aparecen todas mezcladas.

26



Caṕıtulo 3

Metodoloǵıas del Proyecto

A continuación se exponen las diferentes metodoloǵıas que hemos utilizado
durante el desarrollo de este Trabajo de Fin de Grado.

3.1. Uso de Software Libre

Para el desarrollo de todo el software que compone el proyecto siempre se
ha utilizado una aproximación de software libre. Esto permite contribuir
al común y que cualquier persona pueda hacer uso de nuestro código si lo
necesita. Se ha usado software libre tanto con las herramientas necesarias
para el desarrollo de código y documentación como para el resultado final
de la aplicación. Con esto se da la posibilidad a que otros usuarios puedan
visualizar el código desarrollado o utilizarlo libremente. Para ello se realizaron
aportaciones a toda la comunidad subiendo el código del proyecto a GitHub
bajo una licencia GNU GPLv3 [34].

En la tabla 3.1 se expone un breve resumen del software libre utilizado y las
licencias que poseen.

Software Licencia
Eclipse Eclipse Public License

Android Studio Apache License 2.0
Laravel MIT License

Apache Wave Apache License
phpMyAdmin GNU GPLv2

MySQL GNU GPL
PHP PHP License

Android Apache License 2.0 y GNU GPLv2
Java GNU GPL

OpenShift Apache License 2.0

Tabla 3.1: Software libre utilizado durante el desarrollo.

27



CAPÍTULO 3. METODOLOGÍAS DEL PROYECTO

3.2. Migración de Wave/SwellRT a Android

Para llevar la tecnoloǵıa de Software libre de colaboración en tiempo real
ya existente en Web de SwellRT a Android, se utilizó una metodoloǵıa que
implicaba los siguientes pasos:

Estudiar el funcionamiento de la implementación Web actual de SwellRT
en Java y GWT.

Identificar los problemas de la implementación actual al desplegarla en
Android.

Implementar los cambios necesarios para hacer la tecnoloǵıa compatible
con las caracteŕısticas nativas de Android.

Probar con una aplicación sencilla que el resultado funciona.

El desarrollo de esta parte del proyecto se puede ver en el caṕıtulo5.1 de este
documento, dedicado en su totalidad a describir los aspectos más destacados
dicha migración a Android.

3.3. Diseño de la Aplicación

Tras conseguir migrar SwellRT a Android hab́ıa que llevar a cabo el diseño
de la aplicación Android que utilizara las caracteŕısticas de colaboración en
tiempo real de SwellRT. Para ello se utilizó una metodoloǵıa de brainstorming
con el fin de dar con una idea interesante de aplicación y una metodoloǵıa
formal de Diseño Guiado por Objetivos (DGO) para diseñarla.

3.3.1. Brainstorming

El brainstorming [35] (o lluvia de ideas en español) es una técnica de trabajo
en grupo que persigue que todos sus integrantes se junten para generar ideas
originales en un ambiente distendido. El objetivo es primar la cantidad por
encima de la calidad de éstas para después de la sesión realizar un proceso
de selección de las más interesantes. De esta manera pueden salir ideas que a
priori podrian resultar absurdas pero que otros integrantes del grupo pueden
aprovechar para que surjan otras nuevas.

28



CAPÍTULO 3. METODOLOGÍAS DEL PROYECTO

Con esta técnica se ha decidido la aplicación que se le dará a la tecnoloǵıa
de SwellRT en Android. (Ver Sección 6.2).

3.3.2. Diseño Guiado por Objetivos (DGO)

Se basará el diseño de la aplicación en la metodoloǵıa del Diseño Guiado por
Objetivos (DGO o Goal-Directed Design), que implementa el proceso de la
Ingenieŕıa de la Usabilidad propuesto por Alan Cooper [36]. Este proceso
constará de las siguientes fases:

3.3.3. Brainstorming

El brainstorming [35] (o lluvia de ideas en español) es una técnica de trabajo
en grupo que persigue que todos sus integrantes se junten para generar ideas
originales en un ambiente distendido. El objetivo es primar la cantidad por
encima de la calidad de éstas para después de la sesión realizar un proceso
de selección de las más interesantes. De esta manera pueden salir ideas que a
priori podrian resultar absurdas pero que otros integrantes del grupo pueden
aprovechar para que surjan otras nuevas.

3.3.4. Diseño Guiado por Objetivos (DGO)

Para elaborar el diseño de la aplicación, nos hemos basado en la metodo-
loǵıa del Diseño Guiado por Objetivos (DGO o Goal-Directed Design), que
implementa el proceso de la Ingenieŕıa de la Usabilidad propuesto por Alan
Cooper [36]. Este proceso constará de las siguientes fases:

1. Investigación

Esta fase consistirá en la realización de estudios para obtener datos
cualitativos sobre los usuarios y/o reales de la aplicación y cuáles son
sus necesidades. Se realizarán tareas para comprender a los usuarios,
saber sus inquietudes y lograr empat́ıa. A lo largo de esta fase se irán
identificando patronos de comportamiento que sugerirán los objetivos
y motivaciones del usuario. Por último se realizarán estudios de mer-
cado, revisiones y auditoŕıas que ayudarán al diseñador a comprender
el dominio, el modelo y las restricciones técnicas que el sistema debe
cumplir.

29



CAPÍTULO 3. METODOLOGÍAS DEL PROYECTO

2. Modelado

A lo largo de esta fase se utilizarán los datos provenientes de la fase
previa para crar los modelos del dominio y los usuarios. En esta parte se
crearán las personas, aquetipos de usuarios que contienen información
sobre obejtivlos, motivaciones y comportamientos de los usuarios con
el sistema. El resultado final de esta fase serán los tipos de persona
que representarán a los usuarios del sistema, y que más adelante serán
utilizados fases para proporcionar algún tipo de feedback.

3. Definición de Requisitos

Durante esta fase se utilizarán las personas y los datos de la fase an-
terior, para crear los escenarios de contexto e identificar los requisitos
o necesidades del usuario. Estos requisitos serán definidos en tres com-
ponentes: objeto, acciones y contexto. También se definirán requisitos
relacionados con el negiocio, la apclicación, requisitos técnicos, etcétera.

4. Definición del framework de Diseño

En esta fase se creará el concepto general del sistema, definiendo los
comportamientos y diseño visual. Identificaremos el framework de
interacción, como un concepto de diseño estable que define la estruc-
tura del sistema a partir de patrones y principios de diseño. Por último,
se definirá el framework visual, como el aspecto visual de la aplicacion
(diseño, tipograf́ıa, colores, iconos, etcétera).

Queremos insistir eso śı en que únicamente se ha basado este proyecto en
esta metodoloǵıa para seguir el proceso del diseño de la aplicación. No se
seguirán todas las fases de esta metodoloǵıa al pie de la letra ya que el
alcance en tiempo de este proyecto escapa a una metodoloǵıa tan formal y
laboriosa (que implica gran cantidad de pruebas y procesos) como esta.

Queremos insistir eso śı en que únicamente nos hemos basado en esta me-
todoloǵıa para seguir el proceso del diseño de la aplicación. No seguiremos
todas las fases de esta metodoloǵıa al pie de la letra ya que el alcance en
tiempo de este proyecto escapa a una metodoloǵıa tan formal y laboriosa
(que implica gran cantidad de pruebas y procesos) como esta.

3.4. Implementación de la Aplicación

En esta fase se llevó a cabo la implementación de un prototipo final de la
aplicación basado en el estudio de los resultados de la fase de diseño previa.

30



CAPÍTULO 3. METODOLOGÍAS DEL PROYECTO

Además se diseñó e implementó también el servidor que alojaŕıa la base de
datos y se comunicaŕıa con la aplicación. Durante el desarrollo del código del
sistema se han utilizado las metodoloǵıas que se describen a continuación.

3.4.1. Control de versiones

Para mantener una copia de las versiones locales, se ha utilizado GIT co-
mo herramienta de control de versiones. Realizando commits y subiendo los
cambios de cada versión en un repositorio público alojado en GitHub.

3.4.2. GitHub

Para compartir el código del sistema y visualizar los cambios de cada com-
mit, se ha utilizado una organización pública donde se almacenan todos los
repositorios de sus distintas partes. La organización está disponible en el
siguiente enlace: https://github.com/Zorbel.

3.4.3. Reparto de tareas

Durante la implementación del proyecto se dividieron las tareas en dos grupos
principales. Por un lado se teńıa la parte de back-end, formada por la API
Rest desarollada en Laravel y la base de datos. Mientras que por otro lado se
encontraba la parte de front-end formada por la aplicación en Android. De
cada una de estas partes y debido a la experiencia previa con las tecnoloǵıas
involucradas se encargó uno de los componentes del grupo. De esta manera
Jaime trabajó más en el desarrollo del back-end y Javier en el del front-end.
No obstante ambos revisaban el código del otro para verificar su correcto
funcionamiento. El desarrollo inicial en Wave/SwellRT y su implementación
final en la aplicación se produjo en paralelo por ambos componentes del
grupo.

3.4.4. Revisiones de código

Cada vez que se completaba una funcionalidad se sub́ıa a GitHub y se realiza-
ba una pequeña revisión de código para verificar cómo se hab́ıa implementa-
do el objetivo a desarrollar. De esta forma se evitaba malinterpretar algunos
aspectos que durante la implementación pueden diferir de su planteamien-
to inicial. También se recibieron revisiones de código externas por parte de

31

https://github.com/Zorbel


CAPÍTULO 3. METODOLOGÍAS DEL PROYECTO

los directores del Trabajo de Fin de Grado, que aportaron una visión más
eficiente y organizada del código desarrollado.

3.4.5. Evaluaciones de usabilidad

Se recibió una evaluación de usabilidad externa por parte del director del
TFG Pablo, que valoraba aspectos a mejorar de la Intefaz de Usuario (UI).
Esta evaluación sivió para modificar algunos aspectos de representación gráfi-
ca que mejoraraŕıan la interpretación de los elementos por parte del usuario.

3.5. Patrones de Diseño

La figura 3.2 representa los patrones utilizados en el desarrollo de todo el
proyecto.

Tabla 3.2: Patrones de diseño empleados en el proyecto.

Patrón Decripción Utilización Sección

MVC

Modelo-Vista-Controlador.
Separa la lógica del modelo
y la vista, que se comunican
a través del controlador.

Servicio Web REST Laravel. 7.2.2.1

Singleton

Mantiene una única instan-
cia de un objeto, pudiento
instanciarse desde cualquier
clase.

Aplicación Android. 7.2.3.2

Factoŕıa

Permite crear, mediante
una interfaz abstracta, con-
juntos o familias de objetos
relacionados, sin especificar
cual es la implementación
concreta del objeto.

Servicio SellRT. 5.1.1.3

32



Caṕıtulo 4

Tecnoloǵıas del Proyecto

En las siguientes secciones se explicarán brevemente las tecnoloǵıas y herra-
mientas que se han utilizado para llevar a cabo este proyecto. Concretamente
se hablará de las tecnoloǵıas utilizadas durante la Migración del cliente web
de SwellRT (Wave) a Android (Ver Sección 5.1) y durante el desarrollo de la
aplicación Android que hará uso del resultado de dicha Migración.

En el caso de Wave, al tratarse de una tecnoloǵıa bastante reciente, se expli-
cará más detalladamente en qué consite esta tecnoloǵıa, pero para el resto
de casos se hará una pequeña reseña sobre en qué consiste la tecnoloǵıa y sus
usos. En todos los casos se intentará tamb́ıen explicar de qué manera y para
qué se ha utilizado dentro de este proyecto.

Para hacerse una idea general de las tecnoloǵıas utilizadas se recomienda ver
el resumen que se muestra en la Tabla 4.1.

Figura 4.1: Nube de Tecnoloǵıas utilizadas en el Proyecto

33



CAPÍTULO 4. TECNOLOGÍAS DEL PROYECTO

Tipo Nombre Uso Sección

Framework

SwellRT
Framework que permite desarrollar aplicaciones con la tec-
noloǵıa y la infraestructura federada de Wave a través de
un API JavaScript y Android.

4.1.4

Android Plataforma para la Migración y el Desarrollo de la app. 4.2.2

GWT
Framework JavaScript utilizado por el antiguo Cliente web
de Wave presente en SwellRT.

4.1.7

Laravel 5
Framework de desarrollo del Service REST de la App en
PHP.

4.2.9

Servidor
Wave In A Box

(WIAB)
Servidor que aloja las Waves. Migración y Desarrollo de la
App.

2.1.2.1

OpenShift
Servidor que aloja el Service REST y la Base de Datos de
la App.

4.2.10

Lenguaje

Java
Lenguaje base para trabajar con Android, tanto en la Mi-
gración como en la App.

4.1.6

JavaScript
Lenguaje del antiguo cliente web de Wave presente en
SwellRT.

4.1.8

PHP Lenguaje para definición del Service REST de la App. 4.2.8

SQL
Lenguaje para definir e interactuar con la Base de Datos de
la App.

4.2.5

Formato
de Datos

JSON
Formato para intercambio de información con Servidor Wa-
ve y REST.

4.2.4

XML
Formato para definición de datos estructurados (y de inter-
faces en Android).

4.2.3

Protocolo
Wave

Protocolo de intercambio de Waves basado en XMPP y
usado para la migración y la App.

4.1.1

HTTP
Protocolo de transferencia de datos por Internet usado por
la Migración y por la app.

4.1.9

WebSocket
Protocolo de transferencia de datos bidireccionales por In-
ternet, usado por la Migración y por la App.

4.1.10

Base de
Datos

MySQL Sistema Gestor de la Base de Datos de la App 4.2.6

PhpMyAdmin
Herramienta de Administración de la Base de Datos de la
App.

4.2.7

Control de
Versiones

Git
Software de control de versiones usado para la Migración y
la App.

4.1.11

GitHub
Plataforma web de control de versiones que aloja los desa-
rrollos de la Migración y de la App.

4.1.12

Prototipado POP
Aplicación para elaborar los Prototipos Interactivos basa-
dos en los Prototipos en Papel de la App.

4.2.12

IDE
Eclipse Luna Entorno de Desarrollo utilizado para la Migración de Wave. 4.1.5

Android Studio Entorno de Desarrollo utilizado para el desarrollo de la App. 4.2.1

Sublime Text
Editor de texto y de código fuente,utilizado para desarrollar
el Service REST.

4.2.11

Tabla 4.1: Tecnoloǵıas usadas en el Proyecto

34



CAPÍTULO 4. TECNOLOGÍAS DEL PROYECTO

4.1. Tecnoloǵıas de Wave

4.1.1. Google Wave

Ideado y presentado en 2009 por ingenieros de Google [37], Wave es a la
vez un protocolo de comunicaciones basado en XMPP [38]y una plataforma
web de código libre, que permiten a sus usuarios comunicarse y colaborar
entre śı en tiempo real (Ver sección 4.1.3.2) y de forma federada (Ver sección
4.1.3.1) a través de Internet. Inicialmente fue desarrollado con el objetivo de
integrar en una sola plataforma servicios ampliamente utilizados como son el
correo electrónico, las redes sociales y la mensajeŕıa instantánea. Pese al gran
entusiasmo generado entre la comunidad de desarrolladores tras su anuncio,
en el año 2010 Google anuncia el abandono del proyecto [39] debido a su
poca acogida entre los desarrolladores y a que decide reorientar el uso de la
tecnoloǵıa hacia sus plataformas de edición de documentos Google Docs [17]
y a su red social Google + [40]. Es en este momento cuando el desarrollo
libre del proyecto pasa a manos de la Apache Software Foundation bajo el
nombre de Apache Wave.

4.1.2. Apache Wave

Al cambiar de manos su desarrollo en 2010, la tecnoloǵıa pasa a formar parte
de la incubadora de la fundación Apache [41] como software de código libre
bajo licencia Apache [42]. Aśı, se produce el desarrollo de Wave In a Box
(WIAB) (Ver sección 2.1.2.1), plataforma que integra un cliente web sencillo
y una implementación de un servidor Wave que cualquiera puede descargar
y desplegar en su ordenador.

4.1.3. Caracteŕısticas de Wave

Como plataforma de código libre desarrollada para ser utilizada en red, Wa-
ve hace uso de distintas tecnoloǵıas y protocolos bien conocidos. Entre sus
caracteŕısticas más destacadas están las siguientes:

4.1.3.1. Federación

El Protocolo Wave [38] fue desarrollado para utilizar un modelo federado [43]
[44] de comunicación basado en la tecnoloǵıa XMPP [45] [38]. Se trata por

35



CAPÍTULO 4. TECNOLOGÍAS DEL PROYECTO

tanto de un modelo descentralizado en el que cualquiera de los participantes
en la edición del documento (o ”conversación”) es libre de actuar tanto como
servidor como cliente sin que ello afecte a su participación en el documento.
Por otra parte los clientes pueden interactuar entre śı independientemente
de a qué servidor estén conectados.

Figura 4.2: Arquitectura federada en SwellRT

Además, a diferencia de otras tecnoloǵıas (como el correo electronico) en las
que cada participante almacena su propia copia de la conversación y cada
vez que hay cambios se debe transmitir la conversación entera a todos los
participantes, Wave tiene la ventaja de que actúa de forma que es el servidor
de la conversación el único que almacena la copia entera y se encarga de
calcular los cambios que se han producido para transmitir solamente dichos
cambios por la red a los participantes, con las consiguientes ventajas en
términos de latencia que ello conlleva.

4.1.3.2. Consistencia en tiempo real

El Protocolo Wave [38] utiliza la tecnoloǵıa de Transformaciones Operacio-
nales (OT) [2] para garantizar la consistencia en la comunicación en tiempo
real entre los participantes. Es decir, cualquier cambio producido por cual-
quiera de los participantes en la conversación se transmite automáticamente
y en tiempo real al resto de los participantes. Esto se hace sin pérdida de
información y garantizando que, independientemente del orden en el que se

36



CAPÍTULO 4. TECNOLOGÍAS DEL PROYECTO

produjeron los cambios, el estado estado final del documento será el mismo
para todos y por ende verán lo mismo. [46].

4.1.3.3. Escalabilidad

Wave fue desarrollado como un protocolo de alta escalabilidad que permite
gestionar la existencia de una gran cantidad de conversaciones y participantes
sin que por ello se resienta la productividad del sistema.

4.1.4. Servidores Wave: SwellRT

Como parte del proyecto europeo de investigación P2Pvalue [47] se ha desa-
rrollado SwellRT (Swell Real Time), un fork de Wave In a Box (Ver sección
2.1.2.1) que ampĺıa las caracteŕısticas de éste último añadiendo un nuevo
modelo de datos (Modelo de Datos Colaborativo) más allá del Modelo de
Datos Conversacional de Wave original. Proporciona también un API escrito
en Java que permite trabajar sobre los datos de ese nuevo modelo en forma
de tres tipos básicos: mapas, listas y strings. Es por tanto un framework de
colaboración en tiempo real que basa su funcionamiento en Apache Wave y
cuyo principal popósito es permitir la integracion de la tecnoloǵıa Wave en
otras aplicaciones, que podrán compartir objetos (de los tipos antes mencio-
nados) de forma federada y en tiempo real. Su código fuente está disponible
en GitHub [48], aśı como sus instrucciones de instalación (Ver el Readme en
GitHub).

Para este proyecto se ha usado el framework SwellRT como base para la
migración de la tecnoloǵıa de Apache Wave a la plataforma Android [49]. Se
pretende con esto que SwellRT haga uso de las funcionalidades nativas de
Android.

4.1.5. Eclipse

Eclipse [50] es un Entorno de Desarrollo Integrado (IDE) de código libre
(bajo licencia Eclipse Public License) desarrollado por la Eclipse Foundation.
Lanzado en 2003 alcanza actualmente su versión 4.4, también denominada
Eclipse ”Luna”. Se trata de uno de los IDEs más utilizados que proporciona
herramintas que permiten el desarrollo de código para múltiples lenguajes y
tecnoloǵıas. Posee además la capacidad de extender sus capacidades gracias

37



CAPÍTULO 4. TECNOLOGÍAS DEL PROYECTO

al uso de plug-ins que se pueden descargar desde su marketplace. Es el caso
por ejemplo del plugin ADT (Android Developer Tools), que permite utilizar
el SDK de Android para desarrollar para esta plataforma utilizando Eclipse
como IDE. Hasta finales del año 2014 Eclipse + ADT era el IDE recomendado
por Google para el desarrollo en su plataforma móvil, aunque recientemente
ha pasado a utilizar su propio IDE llamado Android Studio (Ver Sección
4.2.1)

En este proyecto usaremos Eclipse con el plugin ADT como IDE para estudiar
el código del cliente web de SwellRT y llevar a cabo una migración a Android
que permita hacer uso de las caracteŕısticas nativas de esta plataforma.

4.1.6. Java

Java [51] es un lenguaje de programación de próposito general y orientado
objetos. Fue desarrollado en 1995 por Sun Microsystems, actualmente parte
de Oracle, y se distribuye en forma de JDK (Java Development Kit), cuya
versión oficial privativa alcanza hoy en d́ıa la 8. Existe no obstante una ver-
sión de código libre (bajo licencia GPLv2) llamada Open JDK [12] disponible
actualmente en su versión 7. Java tiene como ventaja su independencia del
hardware, ya que cualquier código compilado en java se traduce a un for-
mato bytecode que se ejecuta en una Máquina Virtual Java (JVM) que es
independiente del hardware que haya por debajo.

En este proyecto se usará Java para la Migración del cliente SwellRT a An-
droid, pues dicho cliente (y el que desarrollo Google inicialmente) está escrito
en su mayor parte en este lenguaje de programación. Se utilizará también pa-
ra el desarrollo de la aplicación Android, ya que el SDK de esta plataforma
se basa en Java para desarrollar código compatible.

4.1.7. GWT

GWT [13] (Google Web Toolkit) es un framework de código libre (bajo li-
cencia Apache 2.0) que facilita el desarrollo de aplicaciones web basadas
en AJAX y JavaScript. Concretamente el API de GWT permite desarollar
cñódigo en Java que posteriormente será traducido a JavaScript. Fue creado
por Google en 2006 y actualmente es un proyecto independiente de Software
libre que alcanza ya su versión 2.7

En este proyecto se utilizará GWT durante la Migración de Wave a Android.
Puesto que una parte significativa del cliente web de SwellRT está desarro-

38



CAPÍTULO 4. TECNOLOGÍAS DEL PROYECTO

llada con esta tecnoloǵıa y es necesario estudiar el código para sustituirla
por código nativo de Android, ya que la plataforma móvil de Google no es
compatible con GWT.

4.1.8. JavaScript

JavaScript [52] (JS) es un lenguaje de programación dinámico y débilmente
tipado utilizado a menudo para la programación de aplicaciones web del lado
del cliente (navegador web), aunque también existen implementaciones para
el lado del servidor (como Node.js). Originalmente desarrollado en 1995 por
la extinta Netscape Communications, su versión actual es la 1.8.5.

En este proyecto se utilizará JavaScript para estudiar la implementación
del cliente web de SwellRT hecha con GWT y JavaScript que deberemos
migrar a código nativo de Android, pues la plataforma móvil de Google no
es compatible de forma nativa con JavaScript.

4.1.9. HTTP

HTTP [53] (HyperText Transfer Protocol) es el protocolo de capa de apli-
cación más utilizado para establecer comunicaciones en la World Wide Web.
Fue desarrollado en 1996 conjuntamente por la World Wide Web Consortium
(W3C) y el Internet Engineering Taskforce (IETF), aunque la definición de
su versión más actual (1.1) se encuentra especificada en la serie de RFCs
(Request For Comments) 7230 [53]. Se trata de un protocolo orientado a
transacciones que siguen un esquema de petición-respuesta entre cliente y
servidor.

En este proyecto se utilizará el protocolo HTTP para establecer las cone-
xiones con ambos servidores: el servidor SwellRT que aloja las Waves y el
servidor Openshift que aloja el Service REST y la Base de Datos de la apli-
cación. Concretamente con este protocolo se realizará el proceso de login en
Wave y las peticiones al Service REST en la aplicación Android.

4.1.10. WebSocket

WebSocket [54] es un protocolo que permite establecer comunicaciones bidi-
reccionales (de cliente a servidor y viceversa) y full-dúplex (de forma simúltánea
en ambos sentidos) en la red. Permite utilizar la tecnoloǵıa de los sockets TCP

39



CAPÍTULO 4. TECNOLOGÍAS DEL PROYECTO

en la capa de aplicación. Se trata de un protocolo estandarizado por la IETF
en 2011 en el RFC 6455 [54].

En este proyecto se utilizará esta tecnoloǵıa para establecer un canal de
comunicación basado en sockets con el servidor Wave de SwellRT, pues la
caracteŕıstica de bidireccionalidad full-dúplex es necesaria para aprovechar
la potencialidad de consistencia en tiempo real de Wave. Concretamente en
la Migración se deberá sustituir la implementación actual de WebSocket en
GWT por otra que sea compatible de forma nativa con Android.

4.1.11. Git

Git [55] es un Sistema de Control de Versiones (VCS) distribuido y open-
source (bajo licencia pública GNU) diseñado para gestionar las distintas ver-
siones de una aplicación independientemente del tamaño de la aplicación y
del número de personas que trabajan en ella. Fue creado por Linus Torvalds
en 2005 para trabajar en el desarrollo del kernel de Linux, aunque su versión
actual (2.4.2) es una de las herramientas de control de versiones mas utilizada
para gestionar proyectos software. Su interfaz es por consola de comandos.

En este proyecto se usará Git por consola de comandos como Sistema de
Control de Versiones de todo el software generado, tanto de la Migración de
Wave/SwellRT a Android como del desarrollo de la app y el Service REST del
que hace uso. Incluso las distintas versiones del código látex de esta Memoria
estarán gestionadas con Git.

4.1.12. GitHub

GitHub [8] es una plataforma web lanzada en 2008 que permite alojar de
forma gratuita y en sitios llamados repositorios, proyectos software que uti-
licen Git como Sistema de Control de Versiones. Los repositorios gratutos
son públicos y accesibles por todo el mundo, de manera que cualquiera pue-
de participar en la elaboración de código, aunque existe la opción de pagar
por tener acceso a repositorios privados. GitHub proporciona una interfaz
web que además de gestionar los repositorios permite alojar wikis, páginas
web, gestión de tareas pendientes (issues) y control de acceso entre otras
funcionalidades.

Para este proyecto se utilizará GitHub como plataforma para alojar todo
el código de Software libre desarrollado durante el proyecto: la Migración
de SwellRT a Android (cuyo cliente web antiguo también está disponible

40



CAPÍTULO 4. TECNOLOGÍAS DEL PROYECTO

en GitHub [48]), el desarrollo de la aplicación Android, el Service REST
y la Memoria. Todo esto está disponible en forma de repositorios bajo la
organización llamada ”Zorbel” en la siguiente URL:

HTTPs://github.com/Zorbel

4.2. Tecnoloǵıas de la Aplicación Android

4.2.1. Android Studio

Android Studio [56] es el Entorno de Desarrollo Integrado (IDE), basado en
IntelliJ IDEA [57], oficial que Google proporciona para desarrollar aplicacio-
nes para Android. Fue anunciado en 2013 y en diciembre de 2014 dejó su fase
de beta y pasó a ser el IDE de referencia para el desarrollo en Android, de-
jando atrás el antiguo IDE de Eclipse junto al plug-in ADT. Android Studio
integra en un solo lugar todas las herramientas necesarias para desarrollar en
esta plataforma como un gestor de versiones de Android (SDK Manager), un
gestor de emuladores virtuales (AVD Manager) o una herramienta de Debug
(DDMS) entre otras. Permite asimismo trabajar tanto con código de aplica-
ción como con la interfaz gráfica (XML), la cual podremos previsualizar en
el propio IDE.

En este proyecto, y ya que desde principio de año es el IDE de referencia,
se utilizará Android Studio para el desarrollo de la aplicación Android que
hará uso de las funcionalidades de Wave.

4.2.2. Android

Android [49] es el Sistema Operativo de código libre (bajo licencia Apa-
che 2.0) para dispositivos móviles de Google basado en el kernel de Linux.
Lanzado en 2007, actualmente su API alcanza ya la versión 21 [58], también
denominada Android 5.0 ”Lollipop”. Para desarrollar en esta plataforma bas-
ta con descargarse su SDK [59], accesible entonces desde desde consola de
comandos, aunque siempre resulta más cómodo utilizar un Entorno de Desa-
rrollo como Eclipse o Android Studio (Ver Secciones 4.1.5 y 4.2.1).

Android SDK [59]: paquete que integra el conjunto de herramientas ne-
cesarias para desarrollar en Android. Entre estas herramientas destacan las
siguientes:

41

HTTPs://github.com/Zorbel


CAPÍTULO 4. TECNOLOGÍAS DEL PROYECTO

Libreŕıas con el API de Android y Documentación asociada [60]

Android Virtual Device Manager (AVDM) [61] herramienta para
gestionar la creación, modificación, ejecución y eliminación de emulado-
res en Android. Un emulador [62] es una máquina virtual que ejecuta
una determinada versión de Android. Permite desplegar un dispositivo
movil en el ordenador que imita las caracteŕısticas software y hardwa-
re de uno real para poder hacer pruebas de desarrollo sin necesidad
de poseer un dispositivo con Android. Se pueden elegir multitud de
parámetros [63] para el dispositivo que emula (resolución y tamaño de
pantalla, de memoria Ram, elementos hardware emulados, etcétera.)
siendo lo más importante elegir un API (versión de Android) que se
corresponda con el API que se haya elegido para la aplicación.

Android SDK Manager [64] herramienta para gestionar las versio-
nes de SDK y herramientas asociadas instaladas. Android se encuentra
actualmente en la versión 5.1 (API 22), pero un desarrollador puede
elegir desarrollar para una versión anterior si lo estima necesario, por
lo que puede descargarse por separado dicha versión y mantener varias
API si lo necesita.

Dalvik Debug Monitor Server (DDMS) [65] herramienta que pro-
vee las caracteŕısticas de entorno de depuración para las aplicaciones
en desarrollo. Utiliza la herramienta ADB (Android Debug Bridge)
[66],que permite la comunicación entre el proceso de la consola de co-
mandos del IDE y el emulador/dispositivo móvil.

Teniendo en cuenta la distribucion actual de versiones instaladas en dispo-
sitivos Android [67] (Ver figura 4.3) se ha decidido realizar la migración de
SwellRT con el API 19 de Android (Version 4.4 ”KitKat”) para no tener
problemas de compatibilidad. El emulador desplegado para las pruebas de
desarrollo en la Migración utilizará por tanto Android 4.4 .

Por otro lado en este proyecto se utilizará Android como plataforma móvil
sobre la que llevar a cabo el desarrollo de una aplicación que haga uso de las
funcionalidades y caracteŕısticas de Wave. En esta aplicación se utilizará el
API 21 (Android 5.0 Lollipop) para tener acceso a la interfaz gráfica de diseño
plano ”Material Design” que incluye. Esto no supone un problema, ya que
dicha interfaz gráfica śı que es compatible con versiones previas de Android.

42



CAPÍTULO 4. TECNOLOGÍAS DEL PROYECTO

Figura 4.3: Distribución Actual de Versiones Android (Fuente: Google)

4.2.3. XML

XML [68] (eXtensible Markup Language) es un formato de definición, al-
macenamiento e intercambio de datos de forma estructurada. Fue definido
en 1996 por el W3C y actualmente existe una versión 1.1 (2008). Se trata
de un lenguaje de marcado que define dicho formato estructurado mediante
marcas o ”etiquetas” que aportan información acerca del texto que rodean.
En el caso particular de Android, esta plataforma define la interfaz gráfica
de sus pantallas mediante documentos XML llamados Layouts [69].

En este proyecto se utilizará XML para definir la interfaz gráfica de las pan-
tallas que conforman la aplicación Android.

4.2.4. JSON

JSON [70] (JavaScript Object Notation) es un estándar para intercambio
de datos de forma simple y ligera mediante pares clave-valor. Originalmen-
te derivaba de un subconjunto de datos de JavaScript pero actualmente se
encuentra definido en el RFC 7159 y el ECMA-404 y es independiente de
lenguaje que se utilice para interpretar (”parsear”) los datos que contiene.
En JSON se puede estructurar estos datos de dos formas: en objetos (que
contienen pares clave-valor) y en arrays (que contienen objetos).

En este proyecto utilizaremos JSON para intercambiar datos con el servidor

43



CAPÍTULO 4. TECNOLOGÍAS DEL PROYECTO

de Wave/SwellRT y con el Service REST de la aplicación. En el caso de
SwellRT no trabajaremos directamente a nivel de JSON ya que su API abs-
trae el formato de intercambio de datos. Sin embargo, en la aplicaión śı que
trabajaremos directamente con esta tecnoloǵıa ya que el Service REST res-
ponde a las peticiones de la aplicación en forma de mensajes JSON que la
propia aplicación debe tambien ”parsear” para tratarlos.

4.2.5. SQL

SQL [71] (Structured Query Language) es un lenguaje diseñado espećıfica-
mente para interactuar con Bases de Datos Relacionales pudiendo definir la
estructura de los datos y manipularlos. Desarrollado en 1986, actualmente
está estandarizado por la International Standards Organization (ISO) en el
estándar ISO/IEC 9075 SQL [71]. Este lenguaje permite mediante la cons-
trucción de ”consultas” crear tablas, acceder a sus datos y modificarlos entre
otras cosas.

En este proyecto se utilizará SQL en el Service REST para construir las
consultas a Base de Datos necesarias para devolver al cliente de la aplicación
Android los datos que solicite o pida cambiar.

4.2.6. MySQL

MySQL [72] es un Sistema Gestor de Base de Datos (SGBD) Relacionales que
permite el almacenamiento, creación y modificación de dicho tipo de Bases de
Datos. Desarrollado por Oracle, su versión actual (5.7.4) se distribuye tanto
en forma de Software libre (bajo licencia GPL) o de uso comercial.

En este proyecto se usará MySQL como SGBD para almacenar la Base de
Datos de nuestra aplicaión Android.

4.2.7. PhpMyAdmin

PhpMyAdmin [73] es una herramienta de código libre (bajo licencia públi-
ca GNU) escrita en PHP y que proporciona un sistema de administración
de SGBD MysQL a través de una interfaz web. Fue desarrollado en 1998 y
actualmente la versión 4.4.8 es desarrollada y mantenida por The PhpMyAd-
min Project. Posee una interfaz sencilla que permite administrar la Base de
Datos mediante las operaciones básicas de creación, modificación, elimina-
ción de tablas, creación de consultas SQL y gestión de permisos y usuarios

44



CAPÍTULO 4. TECNOLOGÍAS DEL PROYECTO

entre otros.

En este proyecto se usará PhpMyAdmin como sistema de administración de
la Base de Datos MySQL que contiene los datos de la aplicación Android.

4.2.8. PHP

PHP [74] es un lenguaje de propósito general del lado del servidor diseñado
originalmente para crear aplicaciones web que generaran contenido dinámico.
Diseñado en 1996 por Rasmus Lerdorf, su versión actual 5.6.7 es de código
libre y se distribuye bajo licencia PHP. Tiene la ventaja de poder ser fácil-
mente incorporado dentro de los documentos HTML.

Para este proyecto se utilizará el lenguaje PHP para programar el compor-
tamiento del Service REST que hace de intermediario entre las peticiones de
la aplicación Android y la Base de Datos MySQL.

4.2.9. Laravel 5

Laravel [75] es un framework que permite desarrollar aplicaciones y servicios
web con PHP 5. Fue desarrollado por Taylor Otwell en 2011 y su versión
actual 5.0 se distribuye en forma de código abierto (bajo licencia MIT) en
su propio repositorio público en GitHub [76]. Su funcionalidad es extensible
mediante módulos.

En este proyecto se utilizará Laravel 5 para construir en PHP el Service REST
que hará de intermediario entre las peticiones HTTP del cliente Android y
la Base de Datos de la aplicación.

La elección de Laravel como framework PHP se debió a su flexibilidad, la
facilidad para programar la aplicación y el gran soporte que tiene de la co-
munidad. Además, es uno de los frameworks más populares actualmente en
uso.

4.2.10. OpenShift

OpenShift [77] es una plataforma de computación en la nube que ofrece alojar
servicios de forma gratuita en sus servidores mediante un modelo de arqui-
tectura Software as a Service (SaaS). Disponible desde 2011, se distribuye
bajo licencia Apache 2.0. Dispone también de planes de pago que aumentan
las prestaciones del servidor.

45



CAPÍTULO 4. TECNOLOGÍAS DEL PROYECTO

Figura 4.4: Frameworks PHP más populares. Fuente: SitePoint

En este proyecto se usará OpenShift como servidor web para alojar los servi-
cios de los que hace uso nuestra aplicación Android: el Servicio Web REST y
la Base de Datos. Concretamente el servidor esta accesible desde la siguiente
URL:

HTTPs://apptfg-servicerest.rhcloud.com/

4.2.11. Sublime Text

Sublime Text [78] es un editor de texto gratuito multiplataforma muy versátil
que proporciona caracteŕısticas de atajos de teclado y resaltado de código
para diferentes lenguajes de programación muy útiles cuando se desarrolla
sin un IDE. Fue desarrollado en 2008 por Jon Skinner y actualmente se
encuentra en su versión 2.0.2.

En este proyecto se utilizará Sublime como editor de texto sobre todo para
configurar y programar el Service REST en PHP, pues no se ve necesario
utilizar un IDE espećıfico para ello.

46

HTTPs://apptfg-servicerest.rhcloud.com/


CAPÍTULO 4. TECNOLOGÍAS DEL PROYECTO

4.2.12. POP: Prototyping On Paper

POP [79] (Prototyping On Paper) es una aplicación con versiones web y
para dispositivos móviles que permite elaborar en pocos pasos prototipos
(mockups) interactivos basados en fotos de prototipos realizados en papel.
De esta forma se puede elaborar un prototipo de interfaz gráfica de bajo coste
con la que el usuario pueda interactuar.

Ene este proyecto se utilizará POP durante la fase de diseño de la aplicación
Android para elaborar mockups sencillos e interactivos que podamos enseñar
a la gente y que nos ayuden a refinar el diseño de la interfaz gráfica de la
aplicación. Tiene además la ventaja de que se puede enseñar en la aplicación
móvil de POP para simular el aspecto final que tendŕıa la aplicación y que
el usuario se haga una mejor idea de lo que se pretende diseñar.

47





Caṕıtulo 5

Migración de SwellRT a Android

En esta parte de la memoria se hablará de los aspectos más destacados del
proceso de migración de la tecnoloǵıa de colaboración en tiempo real presente
en SwellRT, basada en el protocolo Wave (ver Sección 4.1.1), a Android.
Para ello se identificará el objetivo de esta parte del proyecto y se detallarán
los problemas encontrados y cómo se solucionaron. Al final se discutirá el
resultado obtenido.

5.1. Objetivo

El framework de SwellRT utiliza un servidor WIAB y el protocolo Wave,
ambos desarrollados en Java/GWT. El SDK de Android [59] es compatible
con Java, aśı que a priori la implantación del servidor no supone problemas
en los dispositivos móviles. Sin embargo, existe un problema con el API de
SwellRT, ya que el lado del cliente fue desarrollado en Javascript usando
el framework GWT. Android no soporta de forma nativa estas tecnoloǵıas,
aśı que es necesario estudiar el código de SwellRT para sustituir todo el código
que haga uso de Javascript/GWT por código compatible con Android.

El objetivo de esta parte del proyecto es conseguir que un cliente
desplegado en Android sea capaz de conectarse e interactuar con
un servidor Wave/SwellRT sin problemas para hacer uso de sus
caracteŕısticas.

5.1.1. Migración: Identificación y Solución de Proble-
mas

Resumen:

Construcción y Depuración de la Migración 5.1.1.1

Migrando la Conexión HTTP a Android 5.1.1.2.

49



CAPÍTULO 5. MIGRACIÓN DE SWELLRT A ANDROID

Migrando la Conexión WebSocket a Android 5.1.1.3.

Migrando el Logging a Android 5.1.1.4.

Creando el Servicio Android 5.1.1.5.

5.1.1.1. Construcción y Depuración

El objetivo de esta parte del proyecto es conseguir que el cliente de SwellRT
se pueda desplegar en Android para aśı conseguir que se conecte al servi-
dor Wave In a Box (Ver sección 2.1.2.1) que también incluye. Para ello lo
primero que se hará será desplegar el servidor en el ordenador clonando el
repositorio de GitHub [48] de SwellRT y siguiendo los pasos descritos en el
Readme del proyecto. Para comprobar que el servidor se ha instalado correc-
tamente, se puede ejecutar por consola (ver Readme) y abrir un navegador
Web con la dirección http://localhost:9898. Se crea entonces un usuario y
contraseña de prueba. Este paso es importante ya que la aplicación Android
intentará conectarse contra este servidor mientras estemos haciendo pruebas
de desarrollo. A continuación se crea un proyecto Android en Eclipse y se
incluyen en él todas las clases de SwellRT.

Existe un problema con la construcción y depuración del código de SwellRT
en Eclipse. Android limita el número de métodos máximos de una
aplicacion a 65K [80] por cuestiones de eficiencia. Para evitar esta limi-
tación, durante el proceso de construcción el SDK de Android utiliza, entre
otras, una herramienta llamada ProGuard [81]. Esta herramienta se encar-
ga de optimizar el código de la aplicacion buscando remover clases que no
se utilizan y ofuscando el código para prevenir la ingenieŕıa inversa. En el
caso de SwellRT, el código posee un gran número de clases java necesarias
para desplegar el servidor y el cliente de la herramienta, por lo que es ne-
cesaria dicha optimización de código realizada por ProGuard. El sistema de
compilación de aplicaciones de Android tiene dos formas: compilación de la
aplicación en modo debug (para hacer pruebas cuando todav́ıa se encuentra
en fase de desarrollo) y en modo release (la aplicación se encuentra en su
versión final y se empaqueta y se firma digitalmente para lanzarla al públi-
co). En el caso de Eclipse, ProGuard solo se ejecuta cuando se construye
en modo release, por lo que cuando se intenta compilar una aplicación con
tantas clases como SwellRT mientras se desarrolla (modo debug) el sistema
da error y no se puede compilar el código para probarlo en el emulador.

La solución que se encontró fue desarrollar en Eclipse (por las facilidades
que el entorno proporciona para escribir código) pero realizar el proceso de

50



CAPÍTULO 5. MIGRACIÓN DE SWELLRT A ANDROID

construcción del código por consola de comandos, ya que en este caso śı que
se puede compilar la aplicación en modo debug utilizando ProGuard.

Una vez aclarado el problema de la construcción y depuración se pasa a
desarrollar el proyecto de la migración. Uno de los componentes principales de
Android a la hora de desarrollar en esta plataforma son las Actividades [82],
que representan las pantallas que se le muestran al usuario y que responden
a su interacción programáticamente. Por tanto, se crea una nueva actividad
principal (waveAndroid.java) que se ejecutará al lanzar la aplicación y que
por el momento intentará conectarse al servidor especificando por código el
usuario y contraseña que hemos creado antes en el servidor. SwellRT realiza
este login contra el servidor usando dos tecnologias: HTTP [83] y WebSockets
[54].

5.1.1.2. Conexión HTTP

Wave fue desarrollado para utilizar el protocolo WebSocket para la conexión
al servidor, pero esta tecnoloǵıa necesita realizar una autenticación HTTP
previa llamada ”handshake”. Lo primero que se hará será otorgar permisos
de conexión a internet a la aplicación. Android utiliza un sistema de
permisos [84] para controlar los privilegios de cada aplicación. Estos permi-
sos se declaran en el Manifiesto de la aplicación [85], archivo que declara
sus caracteŕısticas. Para ello basta con añadir lo siguiente al manifest.xml de
la aplicación:

<uses -permission android:name="android.permission.INTERNET"/>

También hay que tener en cuenta que cuando estamos en el emulador no
estamos en la misma red que el ordenador en el que trabajamos, por lo que la
conexión a la URL http://localhost:9898 no es válida. No obstante, esto tiene
facil solución pues el emulador de Android define unas direcciones IP
de red especiales [86] para este tipo de casos. Basta con sustituir localhost
por la direccion 10.0.2.2 para conseguir acceder al servidor WIAB desplegado
en el ordenador. La dirección URL sera por tanto: http://10.0.2.2:9898.

Lo siguiente que se hará será ejecutar el código de Login del cliente SwellRT
para intentar localizar dónde se lleva a cabo la conexion HTTP. Para ello se
llama desde la actividad principal (WaveAndroid.java) al método startSes-
sion() de la clase WaveClient.java pasándole el usuario y la contraseña antes
creados.

Esto provoca un error de ejecución y la aplicación se cierra. Lo siguiente
que hacemos es depurar la aplicación estudiando el LogCat [87] (Ver Figura

51



CAPÍTULO 5. MIGRACIÓN DE SWELLRT A ANDROID

5.1) para ver dónde se produce el error. Se descubre que el problema esta
localizado en el método login() de la misma clase, que intentaba realizar una
petición POST HTTP al servidor utilizando un RequestBuilder de la
libreŕıa com.google.gwt.http.client. He aqúı el primer problema: la actual
conexión utiliza métodos de GWT/Javascript para hacer la petición Post y
Android no es compatible con esta tecnoloǵıa.

Figura 5.1: Ejemplo de Traza de Error en Logcat

Hay por tanto que encontrar una libreŕıa similar compatible con Android
que construya una petición HTTP POST y la env́ıe al servidor. La primera
opción que sse valoró fue utilizar la libreŕıa HTTP Apache [88], incluida
en el SDK de Android desde sus primeras versiones. Sin embargo, Google
recomienda [89] a partir del API 10 (Android 2.3 ”Gingerbread”) utilizar la
libreŕıa HttpURLConnection[90], también incluida en el API. Por tanto
esta última es la que se elige para la migración.

Se puede ver un esquema simplificado de la nueva estructura del login HTTP
en la Sección A.1.1 del Apénd́ıce.

Sin embargo, aqúı no acaba el problema. Por cuestiones de usabilidad y
de respuesta a la interacción del usuario, Android establece dos reglas para
trabajar con el proceso de la actividad que se le esta mostrando al usuario
(llamado UI Thread) [91]:

52



CAPÍTULO 5. MIGRACIÓN DE SWELLRT A ANDROID

1. No bloquear el UI Thread

2. No acceder al UI Thread directamente desde otro Thread

La conexión a un servidor es un proceso susceptible de durar un tiempo
variable según las condiciones de la red, lo cual deja la aplicación en espera
hasta que se realiza dicha conexión, bloqueando el UI Thread. Por tanto, se
decidió usar un hilo (Thread) por separado en forma de AsyncTask [92]
para llevar a cabo la tarea de Login, tal y como recomienda Google hacer
para trabajar con conexiones a la red [93]. La ventaja por tanto de usar otro
hilo para esto es que la actividad principal no se bloquea.

Es importante también destacar que la arquitectura de SwellRT y de Wave
está planteada de manera que utiliza llamadas aśıncronas (callbacks) para
notificar al resto de la aplicacion del resultado de los procesos de conexión
al servidor, por lo que el AsyncTask tendrá que usar el callback apropiado
para notificar del éxito o fracaso de la conexión Http.

Se puede ver un esquema del AsyncTask encargado del Login en la Sección
A.1.2 del Apénd́ıce.

Este proceso de conexión Http deberá devolver una Cookie que se tratará con
el objetivo de generar un SessionId que será necesario para seguir con la
conexión al servidor. Llegados a este punto, se tiene un proceso de
login Http que hace uso de la libreŕıa HttpUrlConnection y de
un AsyncTask para realizar esa primera conexión al servidor. Se
depura la aplicación y se comprueba que efectivamente el login Http se realiza
correctamente (la respuesta del servidor tiene código 200). Sin embargo la
aplicación aún no funciona correctamente, pues se cierra al intentar
ejecutar el código que se encarga del siguiente paso de la conexión:
conectarse por WebSocket.

5.1.1.3. Conexión WebSocket

Para realizar una conexión con el servidor Wave es necesaria una conexión
mediante WebSockets[54], tecnoloǵıa que permite conexiones bidireccionales
y aśıncronas entre el servidor y el cliente (recordemos que la conexión en
el modelo cliente-servidor tradicional está definida como unidireccional de
cliente a servidor), de manera que cualquiera de los dos puede iniciar una
conexión con el otro en cualquier momento e intercambiar información con
éste. En el caso del protocolo Wave este comportamiento es el deseable, ya que
al tratarse de un protocolo de comunicaciones federado en el que cualquiera

53



CAPÍTULO 5. MIGRACIÓN DE SWELLRT A ANDROID

en la red puede ser cliente o servidor, es importante que la conexión sea
bidireccional. Además la asincrońıa es necesaria ya que, para mantener la
consistencia en tiempo real 4.1.3.2, hace falta que el servidor que contiene las
waves pueda iniciar una conexión con los clientes para notificar los cambios
que se produzcan en dichas waves. Por tanto, el cliente Android debe ahora
establecer una conexión WebSocket con el servidor WIAB.

La metodoloǵıa a utilizar será la misma que para la conexión HTTP, se
ejecutará el código de SwellRT para identificar dónde falla y por tanto cómo
está estructurada la creación y gestión de WebSockets en la versión GWT.

El cliente SwellRT original realiza esta conexión utilizando una libreŕıa lla-
mada Atmosphere [94], que proporciona un framework para Java que permite
gestionar conexiones WebSocket junto a la conexión HTTP que subyace por
debajo. Sin embargo, esta libreŕıa se encarga solo de gestionar la conexión,
no de crear el WebSocket propiamente dicho. En el caso de SwellRT este
WebSocket se crea utilizando la implementación que proporciona GWT lla-
mada también WebSocket (WebSocket.java). Esta clase define las funciones
básicas que debeŕıa tener el nuevo WebSocket: onOpen() para establecer
la conexión, onMessage() para recibir mensajes por el WebSocket, send()
para enviar mensajes y onClose() para cerrar la conexión. Aśımismo el Web-
socket deberá también implementar una serie de callbacks (definidos en la
interfaz WebSocketCallback.java) para notificar a la aplicación de la llegada
de estos eventos del servidor. Los callbacks son: onConnect(), onDiscon-
nect() y onMessage(message) respectivamente.

Este WebSocket se crea utilizando un patrón de diseño Factory, que
abstrae la creación de un objeto de su implementación, de manera que el
desarrollador tenga acceso al objeto sin tener que preocuparse de cómo es-
te implementado el WebSocket por debajo (ver WaveSocketFactory.java en
SwellRT). En este caso, como ya se ha dicho, con Atmosphere y WebSoc-
ket GWT. No obstante, la aplicación no funciona tal y como está hecho en
SwellRT ya que Android no soporta GWT de forma nativa. Hay que sus-
tituir este código buscando una libreŕıa de Software libre que implemente
un WebSocket en Android sobre Atmosphere y que porporcione las mismas
funciones básicas descritas en el párrafo anterior.

La solución encontrada fue utilizar wAsync[95], libreŕıa proporcionada por
Atmosphere para trabajar con Websockets en Node.js, Java y Android. wAsync
trabaja creando un socket que responde a eventos diversos, estando entre
ellos eventos similares a los utilizados por la versión GWT de SwellRT:
on(EVENT.name()), siendo EVENT el nombre del evento al que debe
responder.

54



CAPÍTULO 5. MIGRACIÓN DE SWELLRT A ANDROID

Se puede ver un ejemplo sencillo de utilización de wAsync en la Sección A.1.3
del Apénd́ıce.

Como la arquitectura Wave utilizaba el patrón factoŕıa, fue necesario sustituir
la clase de WebSocket GWT por una de nueva creación llamada WaveSoc-
ketWAsync.java[96] que implementa los métodos de creación y configura-
ción de un Websocket y de callback antes descritos. Asimismo se modificó la
clase WaveSocketFactory.java para hacer uso ahora de esta nueva implemen-
tación del WebSocket compatible con Android.

Sin embargo, se ejecutó esta nueva versión de código y se encontró que la
libreŕıa WAsync incluye dependencias a código que no está presente en la
propia libreŕıa y que es necesario para crear el cliente AsyncHTTPClient que
gestiona la conexión HTTP que subyace por debajo del WebSocket. Concre-
tamente hace falta utilizar un HTTPProvider compatible con Atmosphere,
tal y como recomienda hacer wAsync en su wiki [97]. Para ello basta con
añadir al proyecto las librerias oportunas (Ver Tabla de Dependencias 5.1) y
configurar el cliente segun lo descrito en dicha wiki:

AsyncHttpClientConfig ahcConfig = new AsyncHttpClientConfig.

Builder ().build();

AsyncHttpClient ahc = new AsyncHttpClient(new

GrizzlyAsyncHttpProvider(ahcConfig));

Ahora, al ejecutar la aplicación se comprueba que la conexión al servidor
se produce correctamente. Para completar esta parte del proyecto solo falta
pedir al usuario su user y password, ya que hasta ahora se hab́ıan especificado
a mano en el propio código para realizar pruebas.

5.1.1.4. Conexión final y Logging

Para probar que la aplicación migrada es funcional y es capaz de utilizar las
caracteŕısticas nativas de Android se creará una pequeña y sencilla pantalla
de Login que pedirá al usuario la dirección del servidor Wave, un usuario y
una contraseña.

En el diseño de aplicaciones Android el componente principal de una app es la
Actividad, que se corresponde con la pantalla con la que interactúa el usuario.
La interfaz gráfica se usuario (UI) de las pantallas se encuentra separada del
código de la aplicación en ficheros XML de Layout[69]. A una Actividad se le
especifica cuál es su archivo de layout en su método onCreate(), responsable
de la creación de la actividad y sus recursos.

Se crea una Actividad llamada WaveAndroid.java que haga uso del layout

55



CAPÍTULO 5. MIGRACIÓN DE SWELLRT A ANDROID

Main.xml, en el cual se incluyen tres cajas de texto (llamadas EditText en
Android) para que el usuario introduzca los datos. Además se guarda una
referencia a estas cajas de texto en la Actividad para poder acceder al texto
introducido y pasárselo al método login de Wave que hemos migrado ante-
riormente.

Figura 5.2: Pantalla de Login de WaveAndroid

Además fue necesario mejorar el sistema de mensajes de Log de la aplicación
sustituyendo el framework de la libreŕıa SLF4J para Java usada por SwellRT
por una versión más reciente desarrollada para Android[98]. Esto se debió a
que las libreŕıas de las que hace uso wAsync utilizaban una versión más
reciente de este logger.

Por último se instaló la aplicación en el emulador o el dispositivo móvil y
se probó que se mostraba la pantalla de login anterior. Se introdujeron los
datos del servidor WIAB, de usuario y contraseña y comprobamos que se
ha conseguido el objetivo de esta parte del proyecto: el cliente Android
realiza el login contra el servidor WIAB correctamente.

56



CAPÍTULO 5. MIGRACIÓN DE SWELLRT A ANDROID

5.1.1.5. Organización del código: Servicio Android

Una vez conseguida la conexión al servidor desde Android, se decidió revisar
el código para intentar optimizarlo y organizarlo de manera que aprovechara
mejor las caracteŕısticas de Android y la arquitectura de Wave. Además, el
API que permite gestionar el modelo de datos de SwellRT (Ver Sección 4.1.4)
está escrito en java, por lo que es plenamente funcional y compatible con el
código de la migración a Android. A continuación se hablará de los motivos
de dicha reorganización.

Como ya se ha comentado anteriormente, el proceso de login se debe hacer en
un hilo de ejecución separado del hilo principal o UI Thread, ya que Android
no recomienda[91] que tareas que tarden mucho tiempo en ejecutarse (cómo
por ejemplo descarga de datos de la red) se ejecuten en el mismo hilo que la
interfaz de usuario, pudiendo bloquear dicho hilo y obstaculizando por tanto
la interacción del usuario con el dispositivo.

Hasta ahora se hab́ıa utilizado para ello una Actividad que coteńıa el Asyn-
cTask [92] encargado de ejecutar el código de conexión al servidor en un hilo
separado del UI Thread. Sin embargo, tal y como está definida la arquitectu-
ra de Wave y de SwellRT, la utilización de callbacks (ver secciones 5.1.1.2 y
5.1.1.3) es necesaria para notificar al resto de la aplicación de los eventos re-
lacionados con el intercambio de datos con el servidor. Un AsyncTask ejecuta
de una sola vez y de forma aśıncrona el código que se le asigne a su método
doInBackground(), de manera que una vez que termina su ejecución puede
notificar el resultado de la conexión. Pero no queda a la espera de otros po-
sibles eventos en el socket (como la recepción de mensajes o la desconexión).
Es decir: aunque se definan callbacks para esperar los eventos del
servidor, el socket no podrá notificarlo porque no existe un hilo
que quede a la espera de estos eventos.

Por otro lado, cada vez que se quisiera realizar algún tipo de interacción con el
servidor habŕıa que utilizar un AsyncTask espećıfico para ello, lo cual no hace
sino añadir más código a la aplicación. Otra desventaja de los AsyncTask en
la implementación inicial es que si la Actividad que lo esta ejecutando pasa
a segundo plano (por ejemplo si el usuario cambia de aplicación) se detiene
el proceso de conexión.

Considerando todo esto se decidió utilizar otro componente de Android pen-
sado para ejecutar tareas en background y con la opción de hacerlo de forma
independiente de la aplicación: el Servicio[99].

Un Servicio Android se diferencia de una Actividad en que es un com-
ponente que se ejecuta en segundo plano y no proporciona una interfaz de

57



CAPÍTULO 5. MIGRACIÓN DE SWELLRT A ANDROID

usuario con la que éste pueda interactuar. Un Servicio ejecuta tareas de larga
duración (cómo la descarga de datos de la red) a petición de otros compo-
nentes de la aplicación que estén suscritos (el término utilizado por Android
es bind) a dicho Servicio, a modo de cliente-servidor. De esta manera la Ac-
tividad (cliente) que se suscriba al Servicio (servidor) puede interactuar con
éste último haciendo peticiones y recibiendo notificaciones cuando el Servi-
cio obtenga resultados. Por tanto, se podrá acceder a la conexión al
servidor desde cualquier punto de la aplicación, solo es necesario
que la Actividad en ejecución se suscriba al Servicio para hacerlo.

Pero un Servicio se ejecuta dentro del mismo proceso que el UI Thread,
por lo que aun aśı habrá que utilizar métodos para ejecutar el código que
nos interese en otros hilos de ejecución dentro del propio Servicio. De esta
manera se dividió la reorganización en dos: la conexión Http y la
conexión WebSocket.

Para la conexión HTTP, se decidió utilizar un AsyncTask llamado LoginTask
muy similar al ya explicado anteriormente (ver Sección 5.1.1.2) pero esta
vez definido dentro del propio Servicio y con un callback que notificaba a
la aplicación si la conexión se realizaba correctamente. Además, se puso el
código de la conexión en una clase aparte llamada WaveHttpLogin.java para
tenerlo más organizado.

Como se ve, cuando se realiza esta conexión Http, la Actividad inicial (Wa-
veAndroid.java) es informada de ello mediante su callback onLogin() para
poder notificar al usuario e iniciar la conexión por WebSocket.

Para dicha conexión se deb́ıa buscar una solución que permitiera al Web-
Socket responder a eventos del servidor (véase el funcionamiento de WAsync
descrito en la Sección 5.1.1.3) para, mediante callbacks, informar a la apli-
cación de dichos eventos. La solución final encontrada fue combinar el
uso de un Thread y un Handler. El Thread se encarga de crear el socket
y configurar su respuesta a eventos en forma de mensajes, que enviará en-
tonces al Handler, encargado de quedar a la espera de recibir estos mensajes
de forma aśıncrona y llamar al callback adecuado. Esta implementación se
puede ver concretamente dentro de la clase WaveSocketWAsync.java, donde
se define el Thread llamado WebSocketRunnable y el Handler UIHandler. El
siguiente es un esquema en forma de Diagrama de Secuencia de la conexión
inicial con WebSocket al servidor Wave:

58



CAPÍTULO 5. MIGRACIÓN DE SWELLRT A ANDROID

Figura 5.3: Proceso de conexión WebSocket con Servicio

Cuando se realiza esta conexión al Servidor Wave, la Actividad es notificada
de ello mediante la propagación de callbacks onConnect() que informan del
éxito de la conexión. A partir de este momento el socket informará de la
misma forma (mediante el env́ıo de mensajes al UIHandler) de otros eventos
que se produzcan, ya sea la recepción de datos o la desconexión por ejemplo.
De la misma forma la aplicación podrá enviar datos al servidor, ya que el
socket se mantiene en el Servicio.

5.1.2. Dependencias

El cliente Android de SwellRT migrado y desarrollado en esta parte del pro-
yecto hace uso de las siguientes dependencias con libreŕıas externas a An-
droid:

59



CAPÍTULO 5. MIGRACIÓN DE SWELLRT A ANDROID

Figura 5.4: Proceso de conexión Http con Servicio

5.1.3. Resultado de la Migración

Después de todos estos pasos se dspońıa de una versión funcional de SwellRT
capaz de conectarse al servidor WIAB de forma nativa desde Android. El
resultado de esto se puede ver en el GitHub de esta parte del
proyecto[96].

Solo restaba poner el API de SwellRT en una capa superior para poder acce-
der y trabajar a nivel de wave con el modelo de datos de SwellRT. De esto se
encargó el director de proyecto Pablo, desarrollador del proyecto inicial Web
de SwellRT. Con este API trabajaremos en la siguiente parte del proyecto
para crear una aplicación Android que haga uso de las funcionalidades de
SwellRT. El API se encuentra en el GitHub de SwellRT.

El trabajo realizado para hacer compatible la tecnoloǵıa de colaboración en
tiempo real de Wave presente en SwellRT con dispositivos Android, aporta
por primera vez la posibilidad de utilizar estas caracteŕısticas de forma nativa
en Android en un API de software libre. Hasta este momento las soluciones
disponibles pasaban por utilizar libreŕıas privativas como la de Google (Real
Time API). Esta nueva aportación se encuentra ahora disponible para los
desarrolladores de Android en el GitHub del proyecto de SwellRT: https:
//github.com/P2Pvalue/swellrt/tree/master/android

60

https://github.com/P2Pvalue/swellrt/tree/master/android
https://github.com/P2Pvalue/swellrt/tree/master/android


CAPÍTULO 5. MIGRACIÓN DE SWELLRT A ANDROID

Figura 5.5: Esquema de Clases de SwellRT-Android con Servicio

61



CAPÍTULO 5. MIGRACIÓN DE SWELLRT A ANDROID

Nombre Versión Descripción

WAsync [95] 1.4.3
Libreŕıa que contiene el cliente WebSockets/HTTP
para comunicación aśıncrona.

AsyncHttpClient [100] 1.8.14
Libreŕıa que permite a aplicaciones Java ejecutar de
forma sencilla peticiones HTTP y procesar de forma
aśıncrona la respuesta HTTP recibida.

Grizzly-Framework [101]
2.3.18

Framework del núcleo para aplicaciones Grizzly que
proporciona conexiones TCP/UDP, gestión de me-
moria, servicios/buffers, eventos NIO de bucle/cade-
nas de filtro/filtros

Grizzly-Http [101]
Framework HTTP que contiene la lógica para el tra-
tamiento de mensajes HTTP en el servidor y en el
cliente.

Grizzly-WebSockets [101]
Websocket API que permite crear aplicaciones con
WebSockets en el servidor y en el cliente.

slf4j-Android [98] 1.6.1
”Simple Logging Facade for Java”: Framework de
logging compatible con Android.

Tabla 5.1: Dependencias de SwellRT-Android

Es además plenamente compatible con el cliente web, por lo que las posi-
bilidades de desarrollo de aplicaciones multi-plataforma son claras. Además,
en este proyecto se ha optado por realizar una pequeña prueba de concepto
con edición de texto en tiempo real, pero el desarrollo de plataformas cola-
borativas en tiempo real va más allá e incluye aplicaciones tan diversas como
herramientas de dibujo, visualizado de contenidos (como v́ıdeo y música) de
forma sincronizada, mapas con información en tiempo real, generación de
estad́ısticas en tiempo real, ...

En definitiva, se ha puesto la colaboración en tiempo real a disposi-
ción de la comunidad de desarrolladores de Software libre Android
para que hagan uso de estas funcionalidades en sus futuras aplica-
ciones.

62



Caṕıtulo 6

Diseño de la Aplicación

En este caṕıtulo se expondrá el proceso de diseño de la aplicación que hará uso
de las caracteŕısticas de colaboración en tiempo real presentes en SwellRT
para Android.

6.1. Introducción

Tras haber adaptado (Ver Sección 5.1) la tecnoloǵıa de Wave/SwellRT a An-
droid que soportaŕıa el núcleo de la aplicación, era hora de decidir qué utilidad
se le iba a dar de cara a desarrollar una aplicación Android que hiciera uso
de ello. Se decidió tener sobre todo en cuenta estas caracteŕısticas que nos
ofrećıa Wave:

Edición colaborativa.

Consistencia en Tiempo Real.

6.2. Brainstorming de ideas

Después de considerar posibles ideas de implementaciones que podŕıan hacer
uso de estas caracteŕısticas, decidimos realizar una sesión de brainstorming
junto a nuestros directores de proyecto para identificar ideas potenciales. En
esta sesión aparecieron temas tan variados como wikis colaborativas, aplica-
ciones de inteligencia artificial, aportaciones colaborativas en poĺıtica, edición
de v́ıdeos y música, cursos de formación colaborativos, visualizacion de ma-
pas, etc.

Con un gran repertorio de ideas expuestas en la sesión, se decidió centrar-
se primero en descartar aquellas que no motivaba llevar a cabo. De esta
manera se quedaron cuatro ideas fundamentales a desarrollar en la aplica-
ción: Poĺıtica, Música, Inteligencia Artificial y Mapas. Centrándose ahora
solo en estos temas, surgieron varias ideas colaborativas como: desarrollar

63



CAPÍTULO 6. DISEÑO DE LA APLICACIÓN

(a) Idea de Aplicación

(b) Posibles Nombres

Figura 6.1: Capturas del brainstorming

64



CAPÍTULO 6. DISEÑO DE LA APLICACIÓN

documentos poĺıticos, programas electorales, comunicación entre colectivos
en tiempo real, aprendizaje de música, edición de partituras y obras, aplica-
ciones colaborativas con inteligencia artificial, edición de mapas en tiempo
real, lexicalización, etc.

Finalmente, ya que ambos componentes del trabajo teńıan interés por la
poĺıtica, se decidió realizar una aplicación colaborativa relacionada con dicho
mundo. En esta aplicación se podŕıa recurrir a la edición de contenidos en
tiempo real, ya fueran propuestas poĺıticas, programas electorales u otro tipo
de documentos. Más adelante también se podŕıa hacer uso incluso de algu-
na herramienta de Inteligencia Artificial para automatizar algunas tareas o
realizar recomendaciones sociales.

Lo que śı que se tuvo claro desde el principio es la idoneidad del momento
actual para desarrollar una aplicación de temática poĺıtica, dado que el actual
es un año electoral. Se propuso el objetivo de desarrollar algo que pudiera
tener cierta repercusión y utilidad en las próximas citas electorales de este
año 2015. Se intentaŕıa pensar en la aplicación no solo como un Trabajo de
Fin de Grado sino como algo que se pudiera llevar más allá y que resultara
útil a la sociedad.

Por otro lado, se pretend́ıa elegir un nombre para la aplicación que fuera a
la vez atractivo y significativo de la participación ciudadana que representa.
Para esto se hizo tambien una sesión de brainstorming con varias personas,
de la cual se sacaron varias posibilidades para el nombre. Tras someter a
votación estos nombres se eligió con el que más gustó a todos: DemoCritics.

6.3. Diseño Guiado Por Objetivos (DGO)

Como ya se ha planteado en la metodoloǵıa del proyecto (ver Sección 3.3.4 el
diseño de la aplicación se inspirará en una metodoloǵıa de Diseño Guiado por
Objetivos (DGO) cuyo objetivo final es producir una versión de la aplicación
usable y funcional- Para ello se llevarán a cabo las siguientes actividades:

- Investigación 6.3.1 - Modelado y Definición de Personas 6.3.3 - Definición
de Escenarios y Requisitos 6.3.4 - Framework de Diseño 6.3.5 - Verificación:
Principios de Diseño 6.3.6

65



CAPÍTULO 6. DISEÑO DE LA APLICACIÓN

6.3.1. Investigación

Durante las siguientes secciones se detallará el proceso de investigación previo
realizado para concretar la funcionalidad que ofreceŕıa la aplicación, aśı como
su diseño gŕafico y caracteŕısticas técnicas.

En este caṕıtulo se desarrollan las fases de la metodoloǵıa del Diseño Guiado
por Objetivos (ver sección 3.3.4). Cada una de ellas especificará los pasos a
seguir durante su progreso y el resultado final de cada una.

6.3.2. Investigación

6.3.2.1. Intención Inicial: Prototipo básico

Programas electorales

Vivimos en una sociedad digital, donde cada vez son más las personas que
utilizan sus smartphones para realizar todo tipo de tareas en su vida cotidia-
na.

En los últimos años las diferentes formaciones poĺıticas han subido sus progra-
mas electorales a un documento en formato PDF que suele estar disponible
para su descarga en su página web. Este documento tiene generalmente una
gran extensión (los hay de 200 páginas), lo cual no hace sino dificultar que
las personas se animen a leerlo. Por ello pensamos que una aplicación que
pudiera visualizar las principales secciones de los programas poĺıticos podŕıa
ser especialmente útil para acercar los programas a los electores.

Además también intentaŕıamos darle una estructura a estos programas, de
manera que el usuario pudiera navegar por ellos a nivel de Sección, a di-
ferencia del método actual de leer un ”macro-documento” en PDF. Aśı, la
gente podŕıa opinar sobre los programas poĺıticos a nivel de sección me-
diante acciones familiares para ellos: ”Me gusta”, ”No me gusta” y realizar
”Comentarios”. Añadimos también una acción de ”No lo entiendo” que pen-
samos que seria util para indicar cuándo la redacción de la sección era de
significado difuso.

En definitiva, queŕıamos crear un espacio donde poder informarse sobre las
distintas ofertas electorales y poder debatir sobre las propuestas que propone
cada formación poĺıtica, todo ello en forma una aplicación que podremos
consultar en cualquier momento.

66



CAPÍTULO 6. DISEÑO DE LA APLICACIÓN

Propuestas y Wave

Por otro lado,y en ĺınea con los últimos movimientos poĺıticos ciudadanos,
pretend́ıamos crear también un portal de propuestas ciudadanas en el móvil.
Los usuarios podŕıan visualizar las propuestas de otros usuarios y tener la
posibilidad de crear nuevas propuestas. Además, como queŕıamos aprovechar
las caracteŕısticas de la migración de Wave previamente desarrollada, pensa-
mos en la posibilidad de elaborar estas propuestas de forma colaborativa y
en tiempo real entre muchos usuarios.

También pensamos en la posibilidad de categorizar el contenido de la apli-
cación (Programas y Propuestas) por temas, para proporcionar filtros a la
hora de navegar por dicho contenido. Sin embargo no teńıamos muy clara
la elección de temas, asi como si debiamos darle al usuario la posibilidad de
crear nuevos temas o dar nosotros unos temas preestablecidos.

Una vez pensada la intención y los principales objetivos de la aplicación,
procedimos a realizar unos primeros prototipos en papel de nuestra idea y a
implementar un prototipo básico en el móvil (Ver Sección 6.3.5) que mostraba
programas poĺıticos estructurados y permit́ıa navegar a nivel de Sección por
ellos para leer y emitir opiniones (likes, dislikes, comentarios, etcétera.).

6.3.2.2. Hipótesis de personas

Para identificar a los usuarios objetivo, tenemos que encontrar a miembros
representativos de esos usuarios y animarlos a que participen en nuestra
investigación. Para ello reuniremos una serie de caracteŕısticas básicas que el
usuario deberá cumplir para poder aportarnos los objetivos funcionales de la
aplicación. Estas son algunas de las caracaeŕısticas deseadas:

Edad: Entre 16 y 65 años.

Sexo: Indiferente.

Profesión: Indiferente.

Aptidudes deseables: Activismo social, cociencia poĺıtica, trabajo
colaborativo, ... .

Habilidades técnicas: Usuario con experiencia media en uso de apli-
caciones móviles.

67



CAPÍTULO 6. DISEÑO DE LA APLICACIÓN

Simplificando el tipo de persona que queremos encontrar, lo dividiremos en
dos tipos de persona. Por un lado buscaremos al activista social, activo en
movimientos sociales, participación en portales con carácter social, etcétera.
Mientras que por otro lado buscaremos una persona que muestre cierto interés
en el mundo de la poĺıtica, pero que no participe en moviimentos sociales.
Finalmente pudimos contactar con dos miembros de Labodemo [102], una
organización que se dedica al desarollo de nuevas formas de participación
ciudadana. Este perfil cubiŕıa en caso del activista social, mientras que para
el tipo de persona entendido de la poĺıtica pero no tan involucrado, escogimos
a Javier de la Cueva [103].

El siguiente paso seŕıa estudiar la viabilidad de esta aplicación entrevistando
a las personas seleccionadas para realizar una investigación sobre sus nece-
sidades prácticas. Por otra parte también seŕıa útil enseñarles los prototipos
básicos que manejábamos para verificarlos. Entendimos que el tipo de per-
sona con el que nos entrevistáramos deb́ıa de estar relacionado de alguna
manera con el mundo de la poĺıtica, pues nada mejor que hablar con gente
ya interesada en dichos temas para orientarnos por el buen camino.

A continuación detallamos las entrevistas que realizamos en la investigación:

6.3.2.3. Entrevistas

En este aparatdo se recopilarán todas las entrevistas realizadas en la fase de
investigación del diseño de la aplicación.

Entrevista con Labodemo

Tuvimos la oportunidad de mantener una conversación con dos miembros de
Labodemo [102], en la que aprovechamos para mostrarles un prototipo de
la aplicación que estábamos desarrollando. Ambos teńıan experiencia en el
desarrollo de plataformas de participación ciudadana en Internet: fueron los
responsables del desarrollo de los portales de participación del partido poĺıtico
Podemos y la candidatura ciudadana de unidad popular Ahora Madrid.

En ese momento nuestro prototipo móvil se limitaba únicamente a mostrar
las diferentes secciones de cada programa, lo cual les pareció útil, aunque no lo
suficiente como para atraer a una cantidad considerable de usuarios. Confor-
me a su linea de trabajo habitual, eran más partidarios de dar a los usuarios
la posibilidad de realizar Propuestas además de ver Programas poĺıticos. Les
comentamos entonces que antes de hablar con ellos ya hab́ıamos planteado

68



CAPÍTULO 6. DISEÑO DE LA APLICACIÓN

desarrollar Propuestas colaborativas en tiempo real aprovechando la tecno-
loǵıa de Wave. Pero ellos no eran partidarios de esta opción, ya que según
ellos acabaŕıa siendo caótico tener tanta gente editando la misma propuesta
de cara a generar contenido útil.

Dándole una vuelta a la categorización del contenido, nos sugirieron que para
atraer a usuarios, deb́ıamos considerar la posibilidad de integrar en la apli-
cación a colectivos sociales que generaran y categorizaran dicho contenido.
No eran partidarios de que dieramos nosotros ciertas temáticas preestableci-
das, pues debido a la variedad de redaccion en los distintos programas seŕıa
dificil identificar temáticas que incluyeran a todos los programas y proba-
blemente acabariamos excluyendo temas. Aśı, seŕıan los colectivos los que se
encargaran de ”tematizar.el contenido de la aplicación. Por ejemplo: un gru-
po de animalistas podŕıa tener un espacio en la aplicación donde poder crear
sus propias propuestas, e incluso hacer comparativas de lo que proponen los
diferentes programas sobre los animales.

De esta manera, y en relación a la aproximación a los foros tradicionales, se
planteó la idea de crear ”Hilos”: elementos ”temáticos”que agruparan en un
solo sitio Secciones y Propuestas que hablaran sobre un determinado tema.
Estos hilos seŕıan también generados por dichos colectivos.

Esto seŕıa útil también para usuarios que buscaran información sobre un
determinado tema. Por ejemplo: un usuario poco activo, que resulta ser pro-
fesor, podŕıa buscar un colectivo de profesores y ver las Propuestas que se
llevan a cabo o visualizar una comparativa respecto las medidas de educación
de los diferentes programas poĺıticos.

Nos insistieron mucho en el tema de las comparativas. Seŕıa de gran utilidad
que la aplicación tuviera una parte de comparativas en la que los usuarios
pudieran comparar los programas poĺıticos en vez de leerlos sección por sec-
ción. Resultaŕıa de gran interés a un autónomo visualizar las medidas que
proponen los diferentes partidos poĺıticos para los autónomos. Pero estas
comparativas no podŕıa realizarlas cualquiera, por lo que debeŕıan realizar-
las periodistas o expertos que hubieran realizado algún tipo de comparativa
similar anteriormente. Nos sugirieron contactar con periodistas o colectivos
que hubieran publicado algún tipo de comparativa en cuanto a programas o
medidas, para obtener algún tipo de ayuda o consejo a seguir.

Conclusión

Puntos positivos:

69



CAPÍTULO 6. DISEÑO DE LA APLICACIÓN

Nueva forma de participación ciudadana de cara a las elecciones.

Métodos alternativos para discutir propuestas, partidos, programas,
etcétera.

Ligar propuestas a programas concretos.

Puntos negativos:

Visualizar un programa electoral en el móvil puede no resultar dema-
siado interés para los usuarios.

Desarrollar propuestas colaborativas en tiempo real no maniene una
estabilidad en la aplicación.

La aplcación debeŕıa desarrollarse en otras plataformas móviles y de
escritorio.

Puntos a tener en cuenta:

Dejar libertad a usuarios y colectivos creando sus propias categoŕıas
o hilos como ”Espacios” que puedan elaborar segun sus intereses y
generar contenido para la aplicación.

Desarrollar comparativas por secciones, temas o partidos. De tal forma
que un usuario pueda visualizar las diferencias de aquellos temas que
le preocupan.

Contactar con colectivos, asociaciones y/o periodistas que anteriormen-
te hayan elaborado comparativas entre programas poĺıticos en puntos
concretos

Entrevista con Javier de la Cueva

La entrevista con Javier de la Cueva resultó bastante productiva. Ya le co-
noćıamos de algunas conferencias que impartió en la facultad. Javier es abo-
gado y doctorado en Filosof́ıa, estando especializado en temas relacionados
con tecnoloǵıa, Internet y propiedad intelectual. Además, en sus últimas con-
ferencias Javier habla sobre acciones micropoĺıticas [104]. Estas acciones de-
finen la capacidad que tienen los ciudadanos para realizar aportaciones a la
sociedad, el estado o el gobierno que favorezcan la participación ciudadana
en una democracia participativa.

70



CAPÍTULO 6. DISEÑO DE LA APLICACIÓN

Representar los programas electorales en una aplicación móvil le pareció algo
interesante y necesario para la sociedad actual. Si bien casi nadie hace el
esfuerzo de visualizar un programa electoral en PDF, utilizar una herramienta
que facilita el acceso al programa por secciones podŕıa ser una nueva forma
de incentivar su lectura y ayudar a fomentar la participación ciudadana en
poĺıtica.

Además nos sugirió la posibilidad de desarrollar una Hemeroteca de progra-
mas electorales. De esta forma cualquiera podŕıa consultar los programas
de los anteriores gobiernos y comprobar si se cumplieron los objetivos del
programa, aśı como comparar programas de distintos años entre śı,

Pero si en algo nos insistió Javier, fue en la importancia de categorizar el con-
tenido de la aplicación. Un usuario que no tenga conocimientos sobre diversos
temas, se encontraŕıa más cómodo si pudiera visualizar las diferentes partes
de un programa o las propuestas ciudadanas por categoŕıas o temas genera-
les. Ya que dejar libertad a los usuarios para crear categoŕıas personalizadas
podŕıa ser algo negativo para usuarios inexpertos o con pocos conocimientos
sobre temas espećıficos.

Por último, centrándonos en las Propuestas ciudadanas, surgió la idea de
elaborar propuestas que tuvieran una especificación concreta. Es decir, a
parte de tener una idea de propuesta y redactarla, esta propuesta debeŕıa
ir acompañada de los recursos que seŕıan necesarios y sobre todo cómo se
llevaŕıa a cabo de una forma aproximada. También resultaŕıa interesante
definir un pequeño presupuesto de lo que conllevaŕıa realizar la propuesta
o cómo se podŕıa financiar. Aśı evitaŕıamos una elaboración de propuestas
más real, evitando un listado de propuestas infinito sin planterase cómo se
llevaŕıan a cabo o cómo se financiaŕıan.

Conclusión

Puntos positivos:

Llevar los programas poĺıticos de una forma más atractiva a la ciuda-
dańıa es algo esencial en la actualidad.

Categorizar las secciones de los programas poĺıticos para que se puedan
explorar por temas.

Incluir los recursos necesarios que hacen falta para llevar una propuesta
a cabo.

71



CAPÍTULO 6. DISEÑO DE LA APLICACIÓN

Puntos negativos:

Tratar de convertir la aplicación en un foro inconscientemente.

Dejar libertad a la hora de crear categoŕıas espećıficas o hilos puede
generar confusión entre los usuarios.

Puntos a tener en cuenta:

Desarrollar categoŕıas semanales en función de las novedades o actua-
lidad poĺıtica.

Añadir la posibilidad de solicitar la ayuda de expertos sobre un tema
para elaborar una propuesta.

Crear una emeroteca de programas poĺıticos para realizar análisis sobre
el cumplimiento de los programas en legislaturas pasadas.

Informar sobre la legilación actual cuando visualicemos una propuesta
o sección de un porgrama que quiera mejorar o cambiar la legislación
actual.

6.3.3. Modelado y Definición de Personas

Las personas son una herramienta de diseño y ayuda al diseño de la aplica-
ción. El objetivo es centrar el diseño en este tipo de persona, para lograr los
objetivos a la hora de utilziar un sistema. La persona será nuestro modelo,
una descripción detallada de un individuo imaginario que representa a un
grupo de usuarios a los que va destinada la aplicación. Es una representa-
ción ficticia pero desarrollada con gran detalle, que será fruto de los datos
recogidos en la investigación previa de la fase anterior.

En esta fase se definirá el tipo de persona que interactuará con nuestra apli-
cación. Para ello se han identificado dos tipos de personas primarias; un
activista social y un ciudadano de a pie que forme parte del electorado.

- Activista social, 16 años en adelante

Actividad:

Estudia, trabaja o realiza otras actividades de voluntariado.

72



CAPÍTULO 6. DISEÑO DE LA APLICACIÓN

Frecuenta asambleas, participa en diferentes movimientos sociales y
está al d́ıa de la actualidad poĺıtica.

Utiliza redes sociales para comunicarse con otros colectivos, acudir
a asambleas, promover ideas u otras actividades relacionadas con la
poĺıtica y el activismo social.

Otros:

Desconoce las ideas que proponen algunos partidos

Le gusta aportar nuevas soluciones a la sociedad.

- Ciudadano de a pie, 18 años en adelante

Actividad:

Estudia, trabaja o realiza otras actividades de voluntariado.

Es distante al mundo de la poĺıtica, concibe ciertos temas pero no los
conoce en profundidad.

Visita diferentes medios de comunicación para enterase de la actuali-
dad.

Utiliza redes sociales para compartir contenidos con sus amigos o esta-
blecer nuevas amistades.

Otros:

Desconoce por completo los programas electorales.

Tiene cierta indecisión a la hora de acudir a las urnas, no sabe que
propone cada partido.

En las figuras 6.2 y 6.3 se exponen una serie de personas ficticias que podŕıan
representar en la vida real los tipos de persona a la que va dirigida la apli-
cación.

73



CAPÍTULO 6. DISEÑO DE LA APLICACIÓN

Figura 6.2: Estudiante universitario

Figura 6.3: Activista poĺıtico

74



CAPÍTULO 6. DISEÑO DE LA APLICACIÓN

6.3.4. Definición de Escenarios y Requisitos

En esta sección se definirán los posibles escenarios que puedan surgir en la
aplicación. La idea es situarnos en un escenario real que pudera ocurrir en
cualquier momento a lo largo del d́ıa, para detallar la solución al problema. En
cada uno se especificarán los requisitos necesarios para solventar el problema
o los pasos a seguir para lograr el objetivo. Diferenciaremos los términos de
acción, como la actividad inmediata que requiere la solución. El objeto,
como el sujeto principal del escenario. Y por último definimos contexto
reflejando el objetivo final del requisito.

Escenario I

Se acercan las elecciones municipales y Juan aún no ha decidido a qué partido
va dar su voto. No conoce las propuestas que ofertan los partidos a la ciuda-
dańıa y tampoco se f́ıa mucho de lo que dicen los medios de comunicación.

Juan coge su móvil y visualiza los diferentes programas electorales por cate-
goŕıa, seleccionando la categoŕıa de educación que es la que más le afecta a
él personalmente. La aplicación le muestra un listado de las secciones donde
lso diferentes partidos hablan de las medidas que van a tomar en torno a la
educación.

Requisitos:

1. Visualizar (acción) las diferentes categoŕıas (objeto), para ver las sec-
ciones de los programas de una determinada categoŕıa (contexto).

2. Mostrar(acción) un listado de todas las secciones de los programas de
los partidos poĺıticos (objeto) en función de la categoŕıa seleccionada
por el usuario (contexto).

Escenario II

Pablo es un empleado sanitario de Hospital Cĺınico de Madrid preocupado
por la gestión de los hospitales públicos. Parece que la situación no está muy
controlada, por lo que quisiera saber que propuestas o alternativas propone
la ciudadańıa para mejorar la situación actual.

A través de su móvil puede explorar las diferentes propuestas por categoŕıas.
Eligiendo la categoŕıa de sanidad, le aparece un listado de las últimas pro-
puestas desarrolladas por la ciudadańıa.

Requisitos:

75



CAPÍTULO 6. DISEÑO DE LA APLICACIÓN

1. Visualizar (acción) el listado de propuestas (objeto), clasificados por la
categoŕıa seleccionada por el usuario (contexto).

2. Mostrar (acción) la propuesta (objeto), seleccionada por el usuario para
que pueda puntuarla y/o comentarla (contexto).

Escenario III

Lara es una profesora de un colegio de la Comunidad de Madrid. Se acercan
las vacaciones de verano y muchos niños se quedarán sin acceso a comedor.
Lara está planteándose cómo elaborar una propuesta ciudana para abrir los
colegios en horario no lectivo y que todos los niños tengan derecho a comedor
en los meses de verano. Lara no es una experta en gestión pública ni sabe
cómo llevar a cabo la propuesta.

Para ello, Laura comienza a desarrollar una propuesta ciudadana en la apli-
cación, explicando la base de la propuesta. Al no saber cómo financiarlo, deja
la propuesta abierta para que la comunidad la pueda ayudar a desarrollarla.

Requisitos:

1. Agregar (acción) una nueva propuesta (objeto) rellenando los princi-
pales campos del formulario (contexto).

2. Publicar (acción) la propuesta (objeto) como una propuesta colabora-
tiva para editar (contexto)

3. Mostrar (acción) la propuesta (contexto) en la lista de propuestas co-
laborativas para que puedan colaborar otros usuarios (contexto).

Escenario IV

Fran es un periodista de un periódico digital. Se acercan las elecciones y
está redactando un pequeño art́ıculo acerca de los programas de algunos par-
tidos poĺıticos. Necesita acceder a los programas compeletos de los partidos
y visualizar las secciones que le resulten de interés para comentarlas en su
art́ıculo.

Accediendo a la aplicación, Fran puede seleccionar los programas de todos
los partidos que se presentan a las elecciones. Listando el ı́ndice del programa
y accediendo a sus secciones.

Requisitos:

1. Visualizar (acción) todos los partidos (objeto) que se presentan a las
elecciones (contexto).

76



CAPÍTULO 6. DISEÑO DE LA APLICACIÓN

2. Seleccionar (acción) un partido poĺıtco (objeto) para visualizar el pro-
grama electoral (contexto).

3. Listar (acción) el ı́ndice (objeto) de secciones del programa seleccionado
(contexto).

4. Visualizar (acción) la sección (objeto) del programa seleccionado por
el usuario (contexto).

6.3.5. Framework de diseño

En esta sección detallaremos todos los aspectos relacionados con el desa-
rrollo del aspecto visual y la interacción con la aplicación. Se utilizarán los
escenarios y requisitos definidos en la fase anterior para crear los bocetos y
prototipos interactivos. Detallaremos los prototipos desarrollados en papel,
algunos prototipos intermedios y el prototipo final de la aplicación presenta-
do.

6.3.5.1. Framework de interacción

Para definir el Framework de interacción realizaremos un proceso de seis
etapas:

Factor de forma, postura y métodos de entrada:

La aplicación será visualizada en un smartphone bajo el sistema operativo
Android (con API 15 como mı́nimo), con tamaños de pantalla entre 3,5 y 6
pulgadas. Que pueda visualizarse en interiores y exteriores.

La postura será temporal. El usuario puede utilizarlo en periodos de tiempo
muy breves como puede ser la consulta de alguna sección, propuesta o dar su
valoración. Elaborando una propuesta o participando en el desarrollo de una,
el usuario necesitará algo más de tiempo, pero seguirá utilizando funciones
básicas. Propias de una postura temporal.

Elementos y datos funcionales:

Elementos de datos

Programa poĺıtico

77



CAPÍTULO 6. DISEÑO DE LA APLICACIÓN

• Atributos: partido, programa, secciones, ı́ndice, temas.

• Relaciones: partido-programa, ı́ndice-sección.

Temas

• Atributos: categoŕıa, programa, sección, partido, propuesta.

• Relaciones: categoŕıa-programa, categoŕıa-propuesta, partido-sección.

Propuestas Ciudadanas

• Atributos: propuesta, categoŕıa, usuario.

• Relaciones: propuesta-usuario, propuesta-categoŕıa.

Propuestas Colaborativas

• Atributos: propuesta, categoŕıa, usuario, edición colaborativa.

• Relaciones: usuario-propuesta, propuesta-categoŕıa.

Elementos funcionales

Visualizar los partidos poĺıticos que se presentan a las elecciones.

Mostrar el ı́ndice de cada programa poĺıtico.

Mostrar, valorar y debatir las secciones de los programas poĺıticos.

Visualizar categoŕıas por temas, distinguiendo entre propuestas y sec-
ciones de programas.

Mostrar, valorar y debatir las propuestas de los usuarios.

Crear una nueva propuesta en una categoŕıa.

Mostrar las propuestas colaborativas y participar en su desarrollo.

Crear una nueva propuesta incompleta para desarrollarla de forma co-
laborativa.

78



CAPÍTULO 6. DISEÑO DE LA APLICACIÓN

Grupos funcionales y jerarqúıas:

Pantalla principal de la aplicación. Grupos de elementos funcionales que con-
tiene:

Lectura y valoración de Programas poĺıticos.

• Visualizar programas poĺıticos.

• Ver secciones de programas.

• Visualización, valoración y debate de secciones de programas poĺıti-
cos.

Clasificación de secciones de programas y propuestas ciudadanas por
categoŕıas.

• Ver secciones de programas poĺıticos por tema.

• Ver propuestas ciudadanas por tema.

Lectura, valoración y creación de Propuestas Ciudadanas.

• Ver propuestas ciudadanas.

• Valorar y debatir propuestas ciudadanas.

• Creación de propuesta ciudadana.

Lectura, colaboración y creación de Propuestas Colaborativas.

• Visualizar las propuestas ciudadanas en desarrollo.

• Crear una propuesta colaborativa.

• Colaborar en el desarrollo de una propuesta.

Boceto del framework de interacción:

El proceso de desarrollo de bocetos se ha realizado en espiral, de tal forma que
una vez que identificábamos una determinada funcionalidad, la representába-
mos en un mockup a papel para debatirlo y discutirlo en las entrevistas. A
continuación trasladábamos el mockup a un prototipo de alto nivel desarro-
llado en Android. Para las siguientes implementaciones que añad́ıan nueva
funcionalidad el proceso era el mismo:

79



CAPÍTULO 6. DISEÑO DE LA APLICACIÓN

1. Desarrollo de un boceto a papel identificando los elementos funcionales.

2. Definir la interacción a través de la herramienta POP [79].

3. Implementar un prototipo de mayor fidelidad en Android.

Figura 6.4: Modelo de desarrollo de los prototipos.

De esta forma tuvimos que dar un total de tres vueltas a nuestro modelo en
espiral para completar el desarrollo.

1) Programas Poĺıticos

En la figura 6.5 se pueden observar los primeros bocetos que defińıan
la interacción de la visualización de los programas poĺıticos:

Elementos del protitipo en papel

a) Partidos poĺıticos

b) Programas poĺıticos

c) Índice de programas poĺıticos

d) Secciones de proramas poĺıticos

80



CAPÍTULO 6. DISEÑO DE LA APLICACIÓN

(a) Protipo en papel.
(b) Protipo interactivo
en POP.

(c) Implementación en
Android.

Figura 6.5: Primeros protitipos sobre programas electorales.

Funcionalidades del protitipo interactivo

a) Visualizar la lista de partidos poĺıticos.

b) Seleccionar un programa poĺıtico.

c) Navegar por el ı́ndice de un programa poĺıtco.

d) Visualizar secciones de un programa, valorarla y comentarla.

Implementación en Android

a) Descargar la lista de partidos poĺıticos del servidor.

b) Descargar el programa seleccionado.

c) Navegar por el ı́ndice del programa.

d) Descargar el contenido de las secciones.

e) Añadir comentarios al servidor.

f ) Modificar parámetros sociales en el servidor (like, dislike, views,
etc).

2) Bocetos de Propuestas Ciudadanas

81



CAPÍTULO 6. DISEÑO DE LA APLICACIÓN

(a) Protipo en papel.
(b) Protipo interactivo
en POP.

(c) Implementación en
Android.

Figura 6.6: Prototipos para el desarrollo de propuestas.

A partir de lo desarrollado hasta el momento, se procedió a diseñar las
propuestas en la aplicación. Manteniendo la coherencia con el diseño
anterior, contuamos desarollando los protitipos que añad́ıan la funcio-
nalidad de las propuestas ciudadanas.

Elementos del protipo en papel

a) Propuestas ciudadanas.

b) Listado de propuestas por tops.

c) Listado de secciones de programas por tops.

d) Desarrollar una propuesta.

e) Pantalla principal rediseñada.

Funcionalidades del prototipo interactivo con POP

a) Visualizar propuesta.

b) Listado de propuestas por tops.

c) Listado de secciones de programas por tops.

82



CAPÍTULO 6. DISEÑO DE LA APLICACIÓN

d) Desarrollar una propuesta.

e) Pantalla principal rediseñada.

Implementación en Android

a) Visualizar propuesta almacenada en el servidor.

b) Listado de propuestas por tops sincronizada con el servidor.

c) Agregar una nueva propuesta al sistema.

d) Pantalla principal rediseñada.

3) Bocetos de Propuestas Colaborativas

Escenarios key path :

En esta sección describiremos los escenarios key path, que descrien cómo in-
teractúa una persona con la interfaz diseñada en el framework de interacción.
Son la evolución de los escenarios de contexto, pero describiendo cómo inter-
actúa la persona con los elemenos de datos funcionales en la interfaz.

I Escenario de cómo visualizar un programa poĺıtico de un par-
tido que se presenta a las elecciones.

Faltan quince d́ıas para las elecciones generales y Carlos aún no ha
decidido su voto. Un amigo le recomienda que instale DemoCritics para
poder leer algún programa poĺıtico y ver las propuestas de las diferentes
opciones poĺıticas. Dentro de la aplicación, Carlos visualiza la lista de
todos los partidos que se presentan a las próximas elecciones generales,
y dentro de cada uno, puede visualiar el programa. Obteniendo un top
de las secciones más populares, Carlos visualiza las partes del programa
que más llaman su atención.

II Escenario de cómo agregar una nueva propuesta en el sistema.

Laura trabaja en la administración de la EMT y lleva varios d́ıas dis-
cutiendo con sus compañeros de trabajo una forma de reestructurar
las ĺıneas de autobuses. De forma que no confluyan todas en el centro,
si no que alguna ĺınea recorra los barrios exteriores del centro. Lau-
ra decide instalar DemoCritics para poner en conocimiento de toda la
ciudadańıa la propuesta que lleva semanas trabajando. Para ello Larua
se sitúa en la parte de propuestas de la aplicación y agrega una nueva.

83



CAPÍTULO 6. DISEÑO DE LA APLICACIÓN

Introduciendo la descripción de la propuesta, cómo piensa llevarla a
cabo y el coste que supondŕıa, Laura consigue publicar su propuesta
en la aplicación para que los usuarios puedan valorarla y debatirla.

III Escenario sobre cómo solicitar ayuda para elaborar una pro-
puesta.

Manuel es un gran aficionado a la música, y en la localidad donde vi-
ve no hay escuelas de música municipales. Él quiere llevar a cabo una
propuesta que se base en el desarrollo de nuevas escuelas de música
municipales en puntos estratégicos y aśı fomentar la educación musi-
cal. Manuel toma su móvil en la pantalal principal de DemoCritics y
solicita la colaboración de una propuesta que facilite la creación de
escuelas musicales. Ya que a pesar de ser un gran aficionado musical,
Manuel no sabe cómo llevar a cabo esa propuesta o qué presupuesto
necesitataŕıa. Aśı pidiendo ayuda a los usuarios, Manuel tendrá desa-
rrollada su propuesta por aquellos interesados y expertos del tema en
la comunidad.

IV Escenario para colaborar en el desarrollo de una propuesta.

Sof́ıa lleva varios años trabajando en la adminsitración pública del es-
tado, y siempre ha querido ayudar utilizando la experiencia que le ha
dado su trabajo estos años. Pero nunca ha sabido ni dónde ni cómo co-
laborar. Un conocido le recomienda instalar DemoCritics en su móvil
personal, aśı podŕıa ayudar a personas que necesitaran ayuda de sus
conocimientos. Con la aplicación instalada, Sof́ıa se dirige a las pro-
puestas colaborativas para explorar aquellas propuestas que están en
desarrollo y pueden necesitar su ayuda. Seleccionada la propuesta, ac-
cede a su contenido y procede a editar el documento que explica cómo
se llevaŕıa a cabo la propuesta.

Escenarios de validación:

En esta fase se pondrán a prueba los escenarios, validando a ciertas situa-
ciones que nos ayudarán a encontrar fallos o posibles mejoras en el diseño.
Utilizaremos preguntas para definir la respuesta del sistema para problemas
o dudas que puedan surgir.

A Qué pasaŕıa si un usuario accede a la aplicación por primera
vez y quisera consultar el programa poĺıtico de un partido en
concreto?

84



CAPÍTULO 6. DISEÑO DE LA APLICACIÓN

Figura 6.7: Pantalla principal de la aplicación.

El usuario accedeŕıa a la pantalla principal de la aplicación (ver figu-
ra 6.7), donde podŕıa diferenciar cuatro grupos principales: Programas
Poĺıticos, Categoŕıas, Propuestas Ciudadanas y Propuestas Colabora-
tivas. Accediendo sobre el icono de programas poĺıticos, la aplición
mostraŕıa al usuario el listado de partidos poĺıticos para explorar los
programas. Al usuario le bastaŕıa con seleccionar el partido poĺıtco del
que quisiera consultar su programa electoral. Finalmente, la aplicación
mostraŕıa al usuario el ı́ndice del programa electoral del partido selec-
cionado.

B ¿Cómo podŕıa acceder un usuario a las secciones de todos los
programas donde tratan un tema en concreto

Desde el menú principal, el usuario accedeŕıa al menú de categoŕıas
para filtrar las secciones o propuestas por temas. Una vez alĺı, el usuario
seleccionaŕıa la categoŕıa (ver figura 6.8) que deseara para obtener todas
las secciones de los programas de los partidos poĺıticos que estuvieran
relacionadas con esa categoŕıa en concreto.

C ¿Qué tendŕıa que hacer un usuario que queire publicar una
nueva propuesta relacionada con la educación?

85



CAPÍTULO 6. DISEÑO DE LA APLICACIÓN

Figura 6.8: Vista de categoŕıas.

Debeŕıa ir al menú de propuestas de la aplicación y seleccionar el botón
de agregar situado abajo a la derecha para acceder al formulario para
publicar una nueva propuesta. Dentro del formulario, el usuario de-
berá de seleccionar la categioŕıa de sanidad

D ¿Cómo podŕıa colaborar un experto en cultura en la aplica-
ción?

Para ver si alguna propuesta requiere la ayuda de alguien en el mundo
de la cultura, deberá acceder al menú Propuestas Colaborativas y se-
leccionar la categoŕıa Cultura entre las listadas de la aplicación. Alĺı se-
leccionará aquellas propuestas que le resulten de interés para ayudar a
su elaboración. Dentro de la propuesta podrá ayudar a redactar en un
pad colaborativo cómo llevar a cabo la propuesta o cómo financiarla.

6.3.6. Verificación: Principios de Diseño

Con el objetivo de verificar los principios de diseño que cumple la aplicación,
utilizaremos los 10 principios de diseño propuestos por Jakob Nielsen [105]
para evaluar la calidad del sistema.

86



CAPÍTULO 6. DISEÑO DE LA APLICACIÓN

(a) Visibilidad del esta-
do del sistema.

(b) Control y libertad
del usuario.

(c) Flexibilidad y eficien-
cia.

Figura 6.9: Principios de diseño en la aplicación.

1. Visibilidad del estado del sistema: Siempre que el sistema ejecuta
tareas o no puede continuar por algún motivo, se mantiene informado
al usuario sobre lo que está pasando. Esto podemos encontrarlo cuando
el usuario accede a los programas poĺıticos y el sistema procede a des-
cargar la información. Mientras se descarga la información, se muestra
un pequeño diálogo indicando la descarga de los datos para mantener
al usuario informado.

2. Relación entre el sistema y el mundo real (Metáforas y lengua-
je familiares): El sistema mantiene un lenguaje próximo al usuario,
evitando terminos más formales del sistema. Cuando visualizamos una
sección de un programa o una propuesta, el sistema emplea el lenguaje
común de términos como like (mano con pulgar hacia arriba), dislike
(mano con pulgar hacia abajo), etcétera, para valorar las secciones de
un programa o una propuesta.

3. Control y libertad del usuario: La aplicación permite deshacer ac-
ciones fácilmente, como puede ser cambiar la opinión de un like o dislike,
o cancelar la acción de publicar una nueva propuesta o comentario.

4. Consistencia y estándares: La aplicación sigue las pautas de diseño
propuestas por las pautas de diseño Material Design [106]. Este estilo
de diseño plano fue propuesto por Google en 2014, y en la actualidad

87



CAPÍTULO 6. DISEÑO DE LA APLICACIÓN

la mayor parte de aplicaciones móviles Android lo utilizan a la hora de
diseñar sus pantallas. Por esto, los usuarios no debeŕıan tener proble-
mas navegando y utilizando los controles de la aplicación, ya que son
familiare al encontrarse en un amplio catálogo de aplicaciones. Agregar
una propuesta desde un botón de lapiz inferior situado a la derecha,
representar un listado de objetos mediante tabs deslizables, son algunas
de las caracteŕısticas destacables de Material Design.

5. Prevención de errores: La aplicación muestra mensajes de error
cuando algo le impide funcionar con normalidad. De esta forma se avi-
sa al usuario de que algo no está funcionando como debeŕıa. Cuando
ejecutamos la aplicación y el sistema detecta que no hay conexión, la
aplicación notifica al usuario en un sencillo diálogo la necesidad de tener
conexión a internet para operar con la aplicacion.

6. Reconocimiento mejor que recuerdo: Para agregar una nueva pro-
puesta o comentario, tan sólo se necesita una transición entre dos pan-
tallas. De esta forma facilitamos al usuario la generación de nuevos
contenidos sin saturarle la memoria u obligarle a recordar mucha in-
formación para llegar a su objetivo. Este principio se encuentra en la
mayor parte de las aplicaciones móviles, pues el usuario suele interac-
tuar con el dispositivo en pequeños intervalos de tiempo y además no
suele tener una postura cómoda que le facilite la concentración. Por lo
que se requieren pocas transiciones entre pantallas, tareas sencillas y
elementos sencillos y distinguibles. Por ejemplo, también identificamos
las distintas partes de la aplicaión (Secciones, Categoŕıas, Propuestas)
con colores distintos para que el usuario sepa en todo momento dónde
se encuentra.

7. Flexibilidad y eficiencia: Se utilizan atajos a funcionalidades dis-
ponible desde la mayor parte de las pantallas del sistema. Haciendo
uso del botón ”hamburguesa” en material design nos da la posibilidad
de abrir un menú con accesos directos a las principales partes de la
aplicación. De tal forma que no necesitemos volver hacia atrás para
seleccionar otra opción. No obstante, ambos caminos pueden ser utili-
zados en función de la habilidad o conocimiento del usuario respecto a
la aplicación.

8. Estética y diseño minimalista: Tanto los diálogos que muestra el
sistema como la información visible en la mayoŕıa de las pantallas del
sistema es clara y concisa. Aśı evitamos dar información innecesaria al
usuario o distraer su atención para evitar su confusión.

88



CAPÍTULO 6. DISEÑO DE LA APLICACIÓN

9. Ayudar a los usuarios a reconocer, diagnosticar y recuperar-
se de los errores: Cuando el usuario da con un error inesperado, el
sistema informa de lo ocurrido mendiante un sencillo diálogo de error.
Simplificando el mensaje mostrado al usuario para que pueda resolverlo
sin grandes problemas.

10. Ayuda y documentación: Cuando el usuario genera contenido, el
sistema va indicando al usuario los pasos que tiene que seguir para
completar su tarea de forma satisfactoria. Esto sucede por ejemplo en
el caso en el que un usuario construye una nueva propuesta, donde el
sistema le indica los campos que tiene que rellenar y la información que
debe ir en cada campo.

89





Caṕıtulo 7

Arquitectura del Proyecto

En este caṕıtulo se estudiarán aspectos técnicos destacados relacionados con
la arquitectura y organización del Software desarrollado durante todo el pro-
yecto.

7.1. Arquitectura de Wave

La arquitectura que soporta Wave tal y como la diseñó originalmente Goo-
gle está estructurada en forma de capas que interactuan entre śı. De forma
general y de abajo hacia arriba disponemos de las siguientes capas:

Capa de Conexión Cliente/Servidor: Se encarga de gestionar la cone-
xión entre servidor y servidor mediante el protocolo XMPP y la cone-
xión entre cliente y servidor mediante el protocolo Wave y WebSockets.

Capa de Control de OT: Se encarga de gestionar la consistencia en
tiempo real de los datos mediante la utilización de Transformaciones
Operacionales (OT).

Capa de Modelo de Datos Wave: Se encarga de gestionar los datos a
nivel de las Waves que forman parte de una Conversación.

Capa de Modelo Conversacional: Se encarga de gestionar los datos a
nivel de las Conversaciones, junto a los documentos que las componen
y los usuarios participantes (Ver Sección 7.1.1). En el caso de SwellRT
se extendió este modelo a otro más generalizado llamado Modelo de
Contenidos (Ver Sección 7.1.2).

Capa de Interfaz de Cliente: API con operaciones para que el cliente
interactue con el Modelo Conversacional subyacente mediante eventos.
En el caso de SwellRT se extendió este API para utilizar el Modelo de
Contenidos de esta tecnoloǵıa.

91



CAPÍTULO 7. ARQUITECTURA DEL PROYECTO

Figura 7.1: Arquitectura de Wave

7.1.1. Modelo Conversacional Wave

Además de definir el protocolo del que hace uso Wave, Google definió un
Modelo de Datos Conversacional [107] que refleja la arquitectura de los datos
que componen las conversaciones en Wave. Aśı, a grandes rasgos, se pueden
ver dichas conversaciones como documentos XML sobre los que los usuarios
participantes (cualquiera es libre de unirse a una conversación en cualquier
momento) actúan creando nuevos elementos o modificando los ya existentes.
Este modelo de datos define una nomenclatura propia para los elementos que
componen esta tecnoloǵıa [108] [44]:

Wave: Conjunto de wavelets (conversaciones).

Wavelet: conjunto de documentos de una conversación y sus partici-
pantes.

Blip: documento con el contenido de un mensaje en la conversación.
Un blip puede tener otros blips dentro de él y los blips pueden ser
publicados o no en función de si su visibilidad se extiende o no al resto
de participantes de la conversación respectivamente.

Manifiesto conversacional: documento con metadatos que definen
la estructura de una conversación.

Hilo conversacional: conjunto de Blips consecutivos que forman parte
de una conversación.

92



CAPÍTULO 7. ARQUITECTURA DEL PROYECTO

Extensiones [109]: pequeñas aplicaciones que se ejecutan dentro de
una Wave y aportan nuevas funcionalidades que no forman parte del
modelo conversacional básico. Pueden ser de dos tipos:

• Gadget: aplicación que se ejecuta en el contexto de una Wave y
en la que todos sus usuarios participan.

• Robot: aplicación que participa en una Wave a modo de usuario
automatizado e interactúa con el contenido pudiendo modificarlo
y responder a eventos por acciones de otros usuarios reales.

Figura 7.2: Modelo Conversacional de Wave

7.1.2. Modelo de Contenidos SwellRT

SwellRT [48] (Swell Real Time) es un framework de desarrollo para Wave que
forma parte del proyecto europeo P2Pvalue [47]. Está basado en el servidor
Wave In A Box [11] (WIAB) y extiende sus funcionalidades cambiando el Mo-
delo Conversacional original creado por Google por uno nuevo de propósito
más general llamado Modelo de Contenidos. En este modelo nuevo se pue-
den intercambiar estructuras de datos de forma colaborativa, federada y en
tiempo real que combinen los siguientes 4 tipos: Mapas, Listas, Strings y
Documentos de Texto.

De esta manera la estructura de datos intercambiada constará siempre de
un Mapa inicial (llamado ”root”) del cual colgarán a modo de árbol el resto

93



CAPÍTULO 7. ARQUITECTURA DEL PROYECTO

de estructuras (de cualquiera de los cuatro tipos que maneja SwellRT) cuyos
datos se gestionarán en tiempo real. Para ello existe también una API nueva
que se encarga de la gestión de dicho arbol mediante la utilización de eventos
que notifican de cambios en las estructuras de datos. Este modelo será el que
se utilizará para la aplicación Android. El siguiente es un esquema de los
cambios en el modelo original introducidos por SwellRT:

Figura 7.3: Modelo de Contenidos de SwellRT

7.2. Arquitectura de la aplicación

La arquitectura de DemoCritics está compuesta por cuatro módulos principa-
les de los que se hablará en profundidad en las siguientes subsecciones. Como
Cliente móvil se tendrá la aplicación desarrollada en Android, que reali-
zará peticiones HTTP al Servicio Web RESTful (PHP+Laravel+MySQL).
Dicho Servicio Web RESTful será quien gestione las peticiones de la apli-
cación móvil mediante el protocolo HTTP. La Base de Datos MySQL
almacenará toda la información relacionada con la aplicación. El API del
Servicio Web RESTful será quien actúe de intermediario entre las peticiones
de la aplicación y las operaciones en Base de Datos. En este caso alojaremos
la Base de Datos y el Servicio Web RESTful en caso en OpenShift [77], una
plataforma que permite alojar servicios web de forma gratuita.

94



CAPÍTULO 7. ARQUITECTURA DEL PROYECTO

Figura 7.4: Arquitectura general de la aplicación.

Por otro lado, la aplicación hará uso del Servicio Android desarrollado en
SwellRT-Android [110] para conectarse con el servidor de colaboración en
tiempo real SwellRT (Java/Jetty+MongoDB) e intercambiar los datos que
sea necesario mantener en tiempo real, es decir, la edición de una Propuesta
de forma colaborativa entre varias personas.

7.2.1. Base de datos

En la implementación de la Base de Datos se ha utilizado un Modelo Rela-
cional para la definición de las tablas. Utilizando MySQL [72] como sistema
de gestión de base de datos (SGBD) y phpMyAdmin [73] como herramienta
de gestión gráfica de la base de datos.

La base de datos está formada por un total de nueve tablas donde se almacena
toda la información relacionada con los programas de los partidos poĺıticos,
las propuestas ciudadanas, etc. y otros datos más técnicos como la gestión
de los usuarios, la relación de los comentarios o la relación entre las secciones
y comparativas entre otros.

95



CAPÍTULO 7. ARQUITECTURA DEL PROYECTO

Figura 7.5: Modelo entidad-relación de la base de datos.

Las tablas section y political party se utilizan para guardar información
estática en la aplicación. Es decir, en la tabla political party se almacenan los
partidos poĺıticos que se presentan a unas elecciones, y en la tabla section,
las diferentes secciones de un programa electoral. Tan sólo modificaremos las
columnas de likes, dislikes, not understood y views para obtener estad́ısticas
de uso de cada sección. El resto de las columnas permanecerán intactas (salvo
que la redacción del programa cambie).

Definimos como datos estáticos aquellos datos que permanecen intactos en
la aplicación desde el inicio. Son datos que no requieren ser modificados y
siempre permanecen tal y como están, a no ser que surgiera algún fallo o im-
previsto en la aplicación. Estos datos principalmente estarán formados por la
información de los partidos poĺıticos y sus programas. Se entiende que de cara
a unas elecciones los partidos poĺıticos no suelen cambiar su nombre, logo o lo
que es el programa electoral. Por lo tanto esos datos permanecerán intactos
durante el uso de la aplicación. Sin embargo, la aplicación contará con datos
dinámicos como aquellos datos que se irán generando y que con el tiempo
pueden cambiar o eliminarse. Este tipo de dato estará relacionado con la ma-
yor parte de la actividad del usuario con la aplicación. Por ejemplo, cuando
un usuario agrega una nueva propuesta, esta propuesta será añadida como

96



CAPÍTULO 7. ARQUITECTURA DEL PROYECTO

una fila más de la tabla proposals. Además esta nueva fila estará sujeta a
cambios que definirán su valoración, el número de comentarios, el número de
visualizaciones, etcétera.

A continuación se procederá a explicar las tablas más relevantes de la base
de datos:

7.2.1.1. political party

Esta tabla contiene la información relacionada con los partidos poĺıticos que
se presentarán a las elecciones. Por tanto nos interesará guardar el nombre
del partido, un logo que los identifique en formato blob y un identificador
único para relacionarlos con sus programas poĺıticos.

7.2.1.2. section

Esta es una de las tablas más complejas de la aplicación, pues contiene toda
la información de los programas poĺıticos. Se encontrará una clave primaria
compuesta definida como id political party y section, que harán referencia
a una sección concreta de un partido poĺıtico. De esta forma nunca se en-
contrará una fila que contenga la misma sección de un programa del mismo
partido poĺıtico dos veces, ya que a cada sección le correspondeŕıa un solo
partido poĺıtico (para más información sobre la estructura del campo sec-
tion consultar el caṕıtulo 7.2.3.2). Por otro lado está el contenido tanto de
la propia sección como del programa poĺıtico, es decir, el t́ıtulo de la sección,
el contenido en texto, etc. como datos estáticos de la tabla. Y por último,
los indicadores sociales de likes, not understood, dislikes y views como datos
dinámicos que se irán actualizando con la actividad de los usuarios.

7.2.1.3. proposal

La tabla encargada de almacenar las propuestas que se van agregando a
la aplicación. Estará definida por campos como un identificador único para
la propuesta, el identificador del usuario que ha publicado la propuesta y
el contenido de dicha propuesta. Estos datos serán estáticos una vez que se
inserten en la base de datos. Al igual que la tabla section, también tendrá co-
lumnas son datos de carácter social y estad́ıstico que irán modificándose con
la actividad de los usuarios en el sistema. Por último, para diferenciar una
propuesta publicada de una propuesta colaborativa, siendo esta última la

97



CAPÍTULO 7. ARQUITECTURA DEL PROYECTO

que hace uso de SwellRT para edición colaborativa, definiremos dos identi-
ficadores que harán referencia a los identificadores Wave de dos documentos
colaborativos alojados en el servidor. De esta forma se puede saber cuando
una propuesta se está desarrollando o está definitivamente publicada. Ya que
para las propuestas publicadas en la aplicación, estas dos columnas tendrán
el valor null, ya que no harán referencia a ningún documento colaborativo.

7.2.1.4. comment

Para almacenar los comentarios generados por los usuarios en la aplicación,
se utilizará la tabla comment que guardará el identificador del usuario y el
texto del comentario. Esta tabla guardará los comentarios realizados en las
secciones, como también los comentarios en las propuestas. De tal forma que
un comentario para una sección de un programa poĺıtico, irá acompañado de
las columnas id political party y section, de la misma manera que se relacio-
nan las secciones de programas con partidos poĺıticos. De lo contrario, si un
comentario pertenece a una propuesta, deberá contener el identificador único
de la misma mientras que los anteriores campos estarán a null. El resto de
las columnas estarán formadadas por datos de valoración y carácter social.

7.2.1.5. opinion

Esta tabla será la referencia que almacenará las opiniones o valoraciones
de un usuario en las propuestas y secciones de programas de la aplicación.
De tal forma que se guardará el identificador del usuario que ha añadido
esa opinión, acompañado del identficador de la propuesta si es el caso o el
identificador de la sección del programa y el partido poĺıtico en el caso de
que se encuentre valorando una sección. Para indicar el valor de la opinión
del usuario, es decir si ha valorado la sección o propuesta como like, dislike,
etc, se utilizarán columnas que contendrán un entero que indicará el tipo de
valoración que ha pulsado el usuario. De tal forma que el usuario siempre
pueda cambiar su opinión o borrarla.

7.2.2. Servicio Web REST

Para establecer la conexión de la aplicación desarrollada en Android con la
Base de Datos se ha utilizado Laravel como framework para desarrollo de
servicios Web. Laravel [75] es un framework de código abierto para desarrollar
aplicaciones web con PHP 5. Laravel permite además desarrollar una API

98



CAPÍTULO 7. ARQUITECTURA DEL PROYECTO

Petición Operación SQL Utilidad

GET Leer SELECT
Obtener un recurso almacenado en
el servidor.

POST Crear INSERT
Crear un nuevo recurso en el servi-
dor.

PUT Actualizar UPDATE
Actualizar un recurso almacenado
en el servidor.

DELETE Borrar DELETE
Eliminar un recurso almacenado en
el servidor.

Tabla 7.1: Funciones CRUD

REST (Representational State Transfer), un estilo de arquitectura software
para sistemas hipermedia. Este término se originó en una tesis doctoral sobre
la web escrita por Roy Fielding [111].

Laravel permite implementar un sistema RESTful para que el cliente móvil
pueda hacer peticiones al servicio web y que dicho servicio responda a éstas
de la forma que se quiera. Estas peticiones se realizan mediante el protocolo
HTTP. En función de la operación que se desee hacer, se clasificarán estas
funciones en el acrónimo CRUD [112] (del original en inglés: Create, Read,
Update and Delete).

Dependiendo de las peticiones que se realicen al servicio mediante el protocolo
HTTP, el servidor devolverá un código de estado para obtener feedback de
lo sucedido. Por tanto se distinguirán diferentes códigos de estado cuando se
quiera obtener un recurso, actualizar un recurso, crear uno nuevo o borrarlo.
En la siguiente tabla se definen los códigos de estado que puede devolver el
servidor en función de las peticiones.

99



CAPÍTULO 7. ARQUITECTURA DEL PROYECTO

Petición Status Code Descripción

GET 200 (OK)
El recurso solicitado ha sido devuelto co-
rrectamente.

GET 404 (Not Found)
El recurso solicitado no ha sido encontra-
do.

POST 201 (Created)
El nuevo recurso ha sido creado correcta-
mente.

POST 404 (Not Found)
No se ha especificado el nuevo recurso a
crear.

POST 409 (Conflict)
No se ha podido crear el recurso porque
ya existe.

PUT 200 (OK)
El recurso ha sido actualizado correcta-
mente.

PUT 204 (No Content)
No se ha especificado el recurso que pre-
tende ser actualizado.

PUT 404 (Not Found)
El recurso a actualizar no ha sido encon-
trado.

DELETE 200 (OK) El recurso solicitado ha sido borrado.

DELETE 404 (Not Found)
El recurso solicitado para borrar, no ha
sido encontrado.

Tabla 7.2: Códigos de estado de la respuesta del servidor

Usar un servicio RESTful proporciona una gran flexibilidad a la hora de
independizar la tecnoloǵıa del servidor de la del cliente. Mediante la arqui-
tectura basada en peticiones HTTP no solo se podrán hacer peticiones desde
el cliente en Android, sino que más adelante se podŕıa desarrollar una versión
web o incluso un cliente para iOS sin tener que modificar el servicio, ya que
las peticiones HTTP serán las mismas.

7.2.2.1. Arquitectura

Laravel utiliza e implementa un funcionamiento basado en el patrón MVC
(Model–View–Controller), separando el modelo de la vista, y delegando la
gestión al controlador. En este caso tendŕıamos un modelo almacenado en
las tablas de la Base de Datos, donde se guardará toda la información dinámi-
ca y estática de la aplicación. El controlador seŕıa en elcargado de gestionar
las peticiones del cliente en Android en función del tipo de operación que re-
quiera. Por último, se tendŕıa como vista el resultado devuelto por el servidor
con los datos solicitados por el cliente, que a su vez los representaŕıa en la

100



CAPÍTULO 7. ARQUITECTURA DEL PROYECTO

Figura 7.6: Arquitectura de Laravel

aplicación móvil. Esta estructura de comportamiento hace independiente el
modelo controlado por el servidor de la vista que obtiene el usuario final en
su cliente móvil. Con esto se consigue elaborar un código más claro y sencillo,
aśı como también evitar conflictos entre el modelo y la vista.

Para comprender la arquitectura de Laravel se van a destacar tres componen-
tes clave. En primer lugar está una primera capa que gestiona las peticiones
del cliente. Esta capa estará compuesta por una serie de rutas a las que
el cliente realizará la petición en función de la operación que desee realizar.
Después, en función de la ruta a la que haya realizado la petición, se aden-
trará en una nueva capa compuesta por controladores que se encargarán
de procesar la petición y devolver al cliente lo que ha solicitado. El último
componente será la vista, que puede ser representada de muchas formas. En
este caso, la vista estará compuesta por una serie de datos en formato JSON,
que posteriormente el cliente móvil se encargará de representar en su propia
vista. Teniendo en cuenta todo esto, se procederá a detallar un poco más
estos tres componentes fundamentales.

101



CAPÍTULO 7. ARQUITECTURA DEL PROYECTO

7.2.2.2. Rutas

Cómo se citaba anteriormente, la primera capa de Laravel es un mapa de
rutas que definirá todos los caminos posibles para llegar a la funcionalidad
requerida de los controladores. Todas las rutas estarán definidas en el fichero
routes.php, alojado en la carpeta app/Http/routes.php de nuestra insta-
lación Laravel. El archivo routes.php es un fichero muy simple escrito en
PHP donde se definirán todas las rutas posibles. La definición de una ruta
irá acompañada de tres valores. El primero de ellos será el tipo de petición
que realizará el cliente (ver tabla 7.1), seguido de la definición de la URL por
la que será accesible, y por último se indicará el controlador responsable de
procesar la petición. Aparte de indicar el controlador, también hay que indi-
car el método que procesará la petición dentro del controlador como veremos
más adelante.

Para definir el conjunto de urls que forman el archivo routes.php, se han
seguido una serie de buenas prácticas [113], habituales a la hora de desarrollar
una RESTful API. Normalmente se utilizarán nombres en lugar de verbos
para acceder a los recursos. Por ejemplo, si queremos visualizar el listado de
propuestas de la aplicación, se utilizará la url /proposal. Que será definida
como:

Route ::get(’/proposal ’, ’ProposalController@index ’);

Aśı queda definida la ruta que accede a todo el listado de propuestas como una
petición GET, que se encargará de procesar el controlador ProposalController
en su método index().

Para acceder a una propuesta en concreto, se pasará un id para obtener el
recurso adecuado. Este id irá a continuación de la url anteriormente defini-
da. Por ejemplo, si se quisiera acceder a la propuesta cuyo id es igual a 5,
definiŕıamos la siguiente ruta:

Route ::get(’/proposal /{id}’, ’ProposalController@show ’);

Nótese que la ruta es la misma que la anterior, a la que se ha añadido un
nuevo parámetro que deberá especificar el usuario. Aśı, la petición GET
/proposal/5, devolveŕıa la propuesta con id 5. Se puede ver que el contro-
lador también es el mismo, pero esta vez el método encargado de procesar
la petición será show(). Además, este método recibirá el parámetro id que
env́ıe el usuario en la petición.

Para crear una nueva propuesta en la aplicación, se deberá realizar una pe-
tición POST. La ruta será exactamente igual que la primera, pero antes

102



CAPÍTULO 7. ARQUITECTURA DEL PROYECTO

se deberá especificar que se trata de una ruta que atenderá a una petición
POST:

Route ::post(’/proposal ’, ’ProposalController@create ’);

Donde una vez más en controlador ProposalController se encargará de pro-
cesar la petición en el método create. Se puede ver que la primera ruta dónde
se obteńıan las propuestas (GET /proposal, es exactamente igual que la que
se acaba de definir. Sólo les diferencia el tipo de petición que está realizando
el cliente. Para definir otros tipos de peticiones como PUT o DELETE, se
usará la misma metodoloǵıa. Un ejemplo del resultado final de las peticiones
que podŕıan realizarse a una propuesta se puede ver en la Sección A.2.1 del
Apéndice.

Para organizar el código y poder visualizarlo de forma clara se utilizarán
grupos de rutas. Esto resultará especialmente útil cuando se tengan varias
operaciones que realizar dentro de una misma dirección, definiendo una nue-
va ruta cuya función será definida a continuación, incluyendo las rutas que
vienen dentro del grupo. Se puede observar en el ejemplo anterior como to-
das las url comienzan con /proposal. Por ello no es necesario definir en cada
ĺınea la ruta /proposal, si no que bastará con definirla en un único grupo que
agrupará todas las rutas que comienzen de la misma forma. Aśı el ejemplo
anterior quedaŕıa más claro y ordenado (ver Sección A.2.2 del Apéndice).

De esta forma se pueden visualizar todas las posibilidades agrupadas dentro
de la dirección proposal. Lo que permitirá utilizar grupos para ordenar fun-
ciones comunes dentro de un mismo prefijo, y además crear subgrupos dentro
de los anteriores si se tiene algún prefijo repetido varias veces. Esto podŕıa
aplicarse a el ejemplo anterior, agrupando las peticiones que requieren como
parámetro un id de la propuesta (ver Sección A.2.3 del Apéndice).

7.2.2.3. Controladores

Los controladores son los encargados de procesar todas las operaciones que
intervienen en el modelo, es decir, en la información almacenada en la base de
datos. Un controlador es un fichero escrito en PHP que será almacenado en
la ruta /app/Http/Controllers de la aplicación. Este fichero estará formado
por una métodos y atributos que serán llamados desde las rutas definidas
en la aplicación. Cada controlador hereda de una clase abstracta llamada
Controller, que a su vez hereda de la clase abstracta BaseController. La cual
implementa la funcionalidad básica de los controladores.

Dentro de un controlador se definirán aquellos métodos que correspondan

103



CAPÍTULO 7. ARQUITECTURA DEL PROYECTO

Figura 7.7: Camino desde la ruta al método del controlador.

con las rutas de la aplicación. Estos métodos procesarán la información del
cliente, operando con los parámetros que haya obtenido, accediendo a la base
de datos, y devolviendo una respuesta en función del éxito de la operación.
Un ejemplo que muestra una implementación básica del método index() del
ProposalController se puede ver en la Sección A.2.4 del Apéndice).

La conexión a la base de datos se encuentra configurada en el archivo /confi-
g/database.php, por lo que la gestión de la conexión y desconexión será con-
trolada por Laravel, lo que proporciona más independencia y versatilidad a
la hora de programar. Como respuesta del método, Laravel utiliza por de-
fecto un fichero JSON con los resultados de la variable a la que se asigne
el resultado, o a la sentencia SQL de la consulta que se esté devolviendo.
El siguiente ejemplo muestra cuál seŕıa el resultado de realizar una petición
GET a la dirección /proposal :

[

{"id":1,"title":"Reducir la contaminaci\u00f3n en Madrid","

text":"Actualmente la contaminaci\u00f3n en Madrid est\

u00e1 llegando a unos l\u00edmites por encima de la 

media de las principales ciudades de la Uni\u00f3n 

Europea. Por ello deber\u00edamos reducir esa 

contaminaci\u00f3n ambiental acerc\u00e1ndonos a la 

media europea.","how":"Cerrando el tr\u00e1fico en 

determinadas zonas de Madrid. Distrito: Zona Centro.","

cost":"Hacer 7 km de calles peatonales: 750.000 \u20ac",

"id_image":4,"date":"2015 -05 -06 00:00:00","id_category"

:4,"id_user":"6d823fa54c6d1a12","views":4,"likes":3,"

not_understood":0,"dislikes":0}

]

104



CAPÍTULO 7. ARQUITECTURA DEL PROYECTO

7.2.3. Cliente Android

La plataforma Android divide el desarrollo de una aplicación en dos partes:
la implementación de la lógica detras de la aplicación mediante el uso de
Activities [82] o Services [99], y la configuración del aspecto de la interfaz
mediante Layouts XML [69]. En las siguientes secciones se hablará de algu-
nos de los aspectos más destacados de este proyecto en referencia a dichas
caracteŕısticas de Android.

7.2.3.1. Interfaz Gráfica

En el desarrollo de esta aplicación se quiso utilizar un diseño plano basado
en las últimas guias de diseño de Android disponibles en su última versión
5.0. Google denominó a este diseño plano ”Material Design”. Por tanto se
usa esta versión de Android (API 21) para desarrollar la aplicación. A pesar
de que aún no mucha gente utiliza Android 5.0 ”Lollipop” (Ver figura 4.3)
muchas de sus caracteŕısticas son retrocompatibles con versiones anteriores,
por lo que aunque la gente no posea la última versión en sus dispositivos
podrá hacer uso de las caracteŕısticas de ”Material Design”.

En Android, cuando se crea una Actividad (en su método ”onCreate()”)
se asigna una Vista (”View”) a la actividad que representa la interfaz del
usuario. Esta vista está definida en un archivo de Layout XML que se de-
berá modificar para crear la interfaz gráfica añadiendo componentes gráficos
[114] (”widgets”) y modificando sus atributos mediante etiquetas XML para
adaptarlos a nuestras necesidades. Además se les puede asignar un identifi-
cador único para poder moverse por dichos widgets luego desde el código de
la aplicación mediante una navegación en árbol utilizando el método ”find-
ViewById()” proporcionado por Android.

Estos componentes gráficos pueden ser los básicos proporcionados por An-
droid (como cajas de texto, botones, listas, etc.) o se pueden crear Vistas
Personalizadas en caso de que los widgets básicos no aporten la funcionali-
dad deseada.

En este último caso será necesario definir un Layout para la vista personali-
zada (que puede a su vez estar compuesto por widgets básicos o no) y una
clase que posea referencias a los datos y a los componentes del layout que los
albergarán.

Sin embargo a menudo se querrán usar varias de estas vistas, ya sean bási-
cas o personalizadas, juntas dentro de una lista, por lo que necesitaremos
un Adaptador [115] (”Adapter”) que haga de intermediario entre el layout

105



CAPÍTULO 7. ARQUITECTURA DEL PROYECTO

y la clase que lo define para ”adaptar” los datos que posee la clase a los
componentes del layout que los muestran.

Vamos a ver un ejemplo de esto con la vista (widget) personalizada llamada
PartyWidget, creada para mostrar cada uno de los elementos de la lista
de Partidos Poĺıticos que se visualiza en la aplicación. El funcionamiento de
este widget personalizado esta formado por los siguientes tres elementos:

party widget.xml: Layout XML que define la disposición de los dos
componentes gráficos básicos que conforman esta vista: un ”Image-
View” para el logo del partido y un ”TextView” para el nombre del
partido.

PartyWidgetView.java: Clase que define el objeto que contiene refe-
rencias a los dos componentes anteriores (mediante sus IDs) y los datos
de la imagen (de tipo Bitmap) y el nombre (String) del partido.

PartyWidgetAdapter.java: Clase que extiende de un ”BaseAdap-
ter” de Android y define el adaptador que se encargará de gestionar
una lista de elementos gráficos de un mismo tipo (en este caso del tipo
”PoliticalParty”) y de crear las vistas que muestran los datos almace-
nados en dicha lista. El método más importante de un Adapter es el
”getView”, que crea la vista personalizada (en este caso de tipo ”Party-
WidgetView”) y le asigna los datos que hay dentro de cada elemento
de la lista de la forma que nosotros le definamos.

De esta manera, solo es necesario decirle al elemento que contiene la lista
de Partidos Poĺıticos (en este caso un ”GridView” que permite visualizarlos
en forma de una rejilla que se adapta al tamaño de pantalla) que use co-
mo adaptador el PartyWidgetAdapter con los datos de la lista de Partidos
Poĺıticos que previamente han sido descargados.

Navegación por Tabs:

Tras la fase de investigación se decidió que seŕıa interesante incluir en la apli-
cación distintos filtros para ver tanto las secciones como las propuestas más
valoradas positivamente, más vistas, más comentadas, etc. Para implementar
la vista de esta funcionalidad se decidió utilizar un diseño muy parecido al
que utiliza Google en su tienda de aplicaciones ”Google Play” para navegar
de forma lateral mediante pestañas (”tabs”) deslizantes. En este caso cada

106



CAPÍTULO 7. ARQUITECTURA DEL PROYECTO

Figura 7.8: Esquema de Implementación de TopItem (Con vista de Section
y Proposal)

una de las tabs mostraŕıa una lista (elemento ”ListView” de Android) de
elementos ordenados por distinto filtro.

No obstante, el método utilizado por Google en anteriores versiones de An-
droid basado en añadir Tabs a la barra superior (”Action Bar”)[116] de la
aplicación está actualmente obsoleto en el API 21, por lo que se tuvo que
recurrir a la actual implementación de Google, que no se encuentra todav́ıa
dentro del API 21 de desarrollo. Es por eso que hubo que utilizar un par
de clases (”SlidingTabLayout” y ”SlidingTabStrip”) que definen las tabs uti-
lizadas por Google en el diseño con ”Material Design”. Estas clases fueron
extraidas del GitHub[117] de la app que Google mostró en su aplicación de
prueba cuando presentó ”Material Design” a finales de 2014. Este elemen-
to trabaja definiendo el contenido de cada Tab mediante la utilización de
Fragmentos[118] (”Fragment”) de Android, que representan una porción de
lo que se muestra dentro de una Actividad.

Sin embargo, la vista (Layout) de una Sección y de una Propuesta dentro
de esta lista seŕıa muy similar (con su foto, t́ıtulo e indicadores sociales
de número de likes, vistas, etc.) por lo que ¿cómo hacer para utilizar la
misma vista en dos objetos que son de tipos distintos? La solución que se
encontró para utilizar el mismo elemento de visualización (definido en el
layout llamado ”top ranking item”) en ambos casos fue utilizar una interfaz
que implementaŕıan tanto la clase ”Section” como la clase ”Proposal”: la
interfaz ”TopItem”.

107



CAPÍTULO 7. ARQUITECTURA DEL PROYECTO

De esta forma, las clases Section y Proposal implementan los métodos ”is-
Section()” e ”isProposal()” de la interfaz devolviendo true en cada caso res-
pectivamente. Aśı, cuando dentro de el Adaptador (”TopItemAdapter”) se
traten los elementos de su lista de TopItems en su método ”getView()”, se
podrá preguntar si se trata de un Section o un Proposal para rellenar la vis-
ta del ListView con los datos correspondientes a cada caso. Solo hace falta
por tanto crear listas de Secciones o Propuestas y pasárselas al adaptador
personalizado después de definirlo como adaptador para el ListView.

Menús de Navegación:

Con el objetivo de proporcionar al usuario una navegación por la aplica-
ción que permita ir a cualquiera de sus secciones independientemente de en
qué pantalla te encuentres actualmente, se decidió utilizar un menú lateral
que se puede deslizar desde el lado izquierdo de la pantalla. Android permite
añadir menús [119] a las Actividades mediante métodos espećıficos de éstas,
aunque en este caso son menús fotantes sencillos a los que se accede mediante
el botón de opciones del móvil o de la app.

Se pretend́ıa utilizar el menú lateral deslizante presente en la mayoŕıa de apli-
caciones del estilo ”Material Design” introducido por Google en su última
versión de Android 5.0 (API 21), por lo que se utilizó un componente gŕafico
llamado ”Navigation Drawer” para ello. Este componente está presente en
todos los layouts de la aplicación y contiene dentro un ”ListView” con las
entradas del menú. Cada una de estas entradas es aśımismo un componen-
te personalizado, definido en el layout menu left item.xml (contiene un logo
y el nombre de la entrada de menú). En consecuencia, y tal y como se ha
hablado antes en esta sección, existirá también un Adapter ”MenuLeftLis-
tAdapter” que se encargará de gestionar la vista de la lista de entradas del
menú. Además, se le ha añadido una cabecera (”Header”) al menú, que con-
tiene la información de nombre de Usuario y un botón para cambiar dicho
nombre.

Sin embargo, si todas las Actividades que componen la aplicación disponen
de este menú, ¿Cómo hacer para evitar repetir el código de generación y con-
figuración de dicho menú en todas las Actividades? La solución encontrada
fue utilizar una Actividad padre llamada ”MenuActivity” que se encargaŕıa
de generar y de albergar los métodos que configuran el menú. De esta ma-
nera, cualquier Actividad de la aplicación extendeŕıa de ”MenuActivity” y
llamaŕıa a sus métodos de generación y configuración de menú con una re-

108



CAPÍTULO 7. ARQUITECTURA DEL PROYECTO

ferencia a su propia vista de Layout (véase que cada Layout contiene el
elemento ”Navigation Drawer” necesario para mostrar el menú).

Figura 7.9: Esquema de Implementación de Menú Izquierdo (Con vista del
Menú)

Existe también en la aplicación un Menú derecho deslizable que muestra un
Indice del Programa de un Partido Poĺıtico para poder navegar por él de
manera más sencilla (similar al que utiliza la aplicación de la ”Wikipedia”
para navegar por un art́ıculo). Este menú solo está presente en la activi-
dad ”SectionViewerActivity”, ya que solo es necesario acceder al indice del
programa cuando se está navegando por sus secciones. Utiliza también para
ello un ”Navigation Drawer” similar al del otro menú antes explicado. No
obstante, en este caso se decidió utilizar un tipo distinto de lista (”Expan-
dableListView”) que se diferencia de la lista normal en que posee dos niveles
de navegación que se pueden expandir. De esta forma es necesario definir
los layouts de los distintos niveles (”groups”) y los subniveles (”childrens”)
dentro de cada uno.

109



CAPÍTULO 7. ARQUITECTURA DEL PROYECTO

Adapter Layout Clase Descripción

PartyWidgetAdapter party widget.xml PartyWidgetView
Widget para mostrar
un elemento de la lista
de Partidos Poĺıticos

MenuLeftListAdapter menu left item.xml MenuLeftItem

Widget para mos-
trar las entradas del
Menú lateral izquier-
do.

TopItemAdapter top ranking item.xml TopItem

Widget para mostrar
un elemento de la lista
con los Tops de Seccio-
nes y Propuestas.

ListIndexAdapter (solo muestra texto) No es necesario

TextView (Android)
que muestra los nom-
bres del ı́ndice de un
Programa Poĺıtico.

ExpandableListAdapter
list child item.xml
list group item.xml

No es necesario

TextView que contie-
nen los t́ıtulos de las
distintas secciones y
subsecciones (desple-
gables) del ı́ndice de
un Programa Poĺıtico.

CommentListAdapter comment item.xml Comment

Widget para mostrar
un comentario de un
usuario dentro de la lis-
ta de comentarios de
una Sección o una Pro-
puesta.

SampleFragmentPagerAdapter tab page *.xml TabPageFragment

Widget para definir lo
que contiene cada tab
mediante Fragmentos
cuya vista es generada
de forma dinámica.

Tabla 7.3: Adapters, Views y Clases utilizadas en el proyecto

7.2.3.2. Estructuración de Programas Poĺıticos

A la hora de almacenar los Programas Poĺıticos en la Base de Datos hu-
bo que estudiar la forma más adecuada de hacerlo para poder estructurar
dichos programas en distintos niveles de secciones y subsecciones. En defini-
tiva, el problema radicaba en cómo codificar la información de a qué nivel de
anidamiento pertenećıa cada Sección. Además, hab́ıa dos opciones: o bien el
service REST devolv́ıa un programa ya estructurado o la propia aplicación
se encargaba de estructurarlos.

110



CAPÍTULO 7. ARQUITECTURA DEL PROYECTO

Codificación en Base de Datos:

En principio se queŕıa elegir una codificación que permitiera realizar una con-
sulta a la base de Datos que devolviera las distintas secciones y subsecciones
en el orden en el que aparecen en el Programa. Tras varios intentos con
distintos campos de Strings y enteros como atributo de la tabla de Secciones
en Base de Datos, se decidió que lo mejor seŕıa utilizar un único número ente-
ro que codificara dicha información. Tras estudiar la composición de diversos
programas se identificó que no seŕıan necesarios más de 4 niveles de
anidamiento en subsecciones. En consecuencia, el número estaŕıa forma-
do por 8 cifras, siendo cada dos cifras un nivel distinto de anidamiento. Los
siguientes ejemplos muestran cómo funciona esta codificación:

Figura 7.10: Ejemplos de Codificación de Secciones y Subsecciones

Utilizando esta codificación se consiguió que mediante una simple consulta
SQL la Base de Datos devuelva todas las secciones del programa de un de-
terminado partido de forma ordenada, siendo luego el Servicio Web REST
(Ver Sección 7.2.2) el que pasará los resultados de esta consulta en JSON a
la aplicación Android.

Estructuración y Almacenamiento de Secciones:

Con dicha codificación se consiguió ordenar las secciones en el orden en el que
aparecen en el programa, pero ahora se deb́ıan guardar en la aplicación en una
estructura que permitiera navegar por el programa de forma estructurada,
pudiendo en cada momento ver las subsecciones o volver a la sección anterior.
Se decidió por tanto guardar el programa en una estructura en árbol
formada por listas de listas. De esta forma cada elemento de la lista seŕıa

111



CAPÍTULO 7. ARQUITECTURA DEL PROYECTO

un objeto del tipo Section que contendŕıa la información de dicha sección
(t́ıtulo, texto, etc.) y otra lista con las subsecciones.

Pero, ¿cómo construir esta estructura a partir de la lista ordenada que de-
vuelve el Service REST? La solución encontrada fue utilizar una función
que construyera dicho árbol de forma recursiva (Ver clase ”GetPrograms-
Data.java”) sobre una sección ”root” vaćıa que perteneceŕıa a cada Partido
Poĺıtico. Dicha función recorreŕıa la lista de secciones sin estructurar y pa-
ra cada sección comprobraŕıa su nivel de anidamiento son el fin de saber si
colocarlo en el nivel actual, en el siguiente o en el anterior.

Se puede ver el código de esta función de construcción del árbol en la Sección
A.3.1 del Apéndice.

Además, como no se pretend́ıa tener que descargarse el programa continua-
mente, esta estructura en forma de arbol se guardaŕıa en una clase llamada
”PoliticalGroups” que alamacenaŕıa el listado de Partidos Politicos y para
cada uno de ellos almacenaŕıa la estructura en árbol de su programa (su nodo
”root”). Esta clase implementa el patrón de diseño Singleton para ase-
gurar que solo exista una instancia de ella, accesible desde cualquier punto
de la aplicación.

Figura 7.11: Esquema de estructura en árbol de Programa Poĺıtico

112



CAPÍTULO 7. ARQUITECTURA DEL PROYECTO

7.2.3.3. Conexión y Peticiones a Service REST y Base de Datos

Las peticiones de información a Base de Datos (ya sea para crear datos, des-
cargarlos o modificarlos) se realizan mediante el protocolo HTTP, enviando
dichas peticiones al Servicio Web REST (Ver Sección 7.2.2). Para enviar di-
chas peticiones es necesario por tanto realizar una conexión HTTP al Servicio
Web REST desde la aplicación Android. Aprovechando la experiencia previa
adquirida durante la migración de Wave (Ver Sección 5.1.1.2), se decidió uti-
lizar la libreŕıa ”HttpURLConnection” de Android y un esquema basado en
AsyncTask que ejecutan el proceso de conexión y descarga de datos en un
thread separado del UI Thread tal y como recomienda Google hacer para
trabajar con conexiones de red[93].

Aśı, en función de la operación que se quiera hacer en Base de Datos, para
cada tipo de consulta existirá un AsyncTask encargado de conectarse al ser-
vidor con la URL apropiada y tratar los datos en JSON que éste le pueda
devolver, ya sea para mostrarlos o guardarlos en algún objeto de la aplica-
ción. De forma general se pueden identificar cuatro tipos de peticiones al
servidor (Ver tabla 7.1).

Con el objetivo de no repetir código se decidió estructurar el esquema de
peticiones HTTP mediante herencia de AsyncTasks. El diagrama 7.12 esque-
matiza la estructura.

Hace falta también actualizar la vista del usuario cuando se reciban los da-
tos. Como un AsyncTask se ejecuta en un hilo aparte diferente del UI Thread
(para no bloquear la interacción con el usuario), a priori no tiene acceso a la
vista (Layout) que se le está mostrando al usuario. Por esta razón la solu-
ción que se encontró fue guardar una referencia a la vista del usuario dentro
del AsyncTask (ver clase ”URLConnection”). De esta manera en su método
”onPostExecute()” que se ejecuta nada más terminar la operacion de cone-
xión del ”doInbackground()”, se obtiene dicha vista y se actualiza con los
datos recién descargados. Este método de actualización de la vista es el que
se utiliza en todos los casos.

Comprobación de Conexión a Internet:

Por otro lado, para llevar a cabo un control de errores en la conexión al Ser-
vicio Web REST, antes de ejecutar la tarea en el AsyncTask se comprueba el
estado de la conexión del dispositivo móvil para asegurarse de que el usuario
dispone de conexión a Internet. En caso contrario se le muestra un mensaje

113



CAPÍTULO 7. ARQUITECTURA DEL PROYECTO

Figura 7.12: Esquema de Clases de Conexión HTTP mediante AsyncTask

114



CAPÍTULO 7. ARQUITECTURA DEL PROYECTO

de aviso para que compruebe sus conexiones y no se lleva a cabo la tarea de
conexión en el AsyncTask. Aprovechando que todas las actividades extienden
de ”MenuActivity” dicho método de comprobación se encuentra dentro de
esa clase. Además, fue necesario definir el siguiente permiso en el ”Android-
Manifest.xml” de la aplicación para acceder a la información de estado de la
conexión del dispositivo:

<uses -permission android:name="android.permission.

ACCESS_NETWORK_STATE" />

7.2.3.4. Gestión de Usuarios: ID de Android

Como esta versión de la aplicación no maneja información cŕıtica y sensible
del usuario se decidió utilizar un método de autenticación basado en el ID
almacenado en el dispositivo móvil. En Android existen varios identificadores
(IMEI, ID de dispositivo, ID de Android..) teniendo cada uno de ellos ca-
racteŕısticas distintas. En este caso se decidió utilizar el ID de Android
[120] ya que es único para cada instalación de sistema operativo y acceder a
su valor no requiere de permisos especiales en la aplicación. Se trata de un
número de 64 bits en formato hexadecimal, al cual se accede directamente
mediante la variable del sistema ”Secure.ANDROID ID”.

El acceso a este identificador se produce nada más ejecutar la aplicación en
su actividad ”MainActivity” y se guarda de forma estática en la clase ”User”
para poder acceder a él desde cualquier punto de la aplicación. Con el iden-
tificador también se accede a la Base de Datos para descargar el nombre de
Usuario que se corresponde con dicho identificador. Este nombre se mues-
tra en el menú izquierdo de la aplicación y se puede cambiar desde ah́ı. De
esta manera, todo el contenido generado por un usuario (Opiniones, comen-
tarios, propuestas,...) se guarda tambien en base de datos asociado a este
identificador único.

7.2.3.5. Servicio Android, Conexión con Wave/SwellRT y Gestión
de Propuestas Colaborativas

Al servicio (ServiceSwellRT) desarrollado durante la migración de SwellRT
a Android (Ver Sección 5.1.3) se le añadió encima el API del Modelo de
Contenidos de SwellRT (Ver Sección 7.1.2). Este API trabaja con Waves (o
”modelos”) con identificadores únicos, y dentro de cada modelo habrá un
objeto root”del tipo Mapa del que colgarán los distintos objetos con los que

115



CAPÍTULO 7. ARQUITECTURA DEL PROYECTO

podremos jugar de cada uno de los cuatro tipos básicos de datos: Mapas,
Listas, Strings y Documentos de Texto.

En este proyecto se utiliza SwellRT para soportar la edición de propuestas
colaborativas. Este tipo de propuestas puede tener asociadas dos textos co-
laborativos que se corresponden con la manera de llevar a cabo la propuesta
y cómo financiarla. Para implementar esto con wave será necesario por tanto
crear una wave por cada propuesta colaborativa, que tendrá asociados a su
mapa ’root’ dos objetos del tipo Documento de Texto (TextType). Este tipo
permite crear documentos colaborativos que pueden ser editados en tiempo
real por todo aquel usuario de wave que esté registrado como participante.

El funcionamiento del Servicio Android de conexión con SwellRT exige pri-
mero enlazar (”bind”) la Actividad actual con el Service para poder hacer
uso del API. Después de enlazar, se podrá registrarse en el servidor SwellRT
y crear, abrir, cerrar o borrar waves, a las que tambien se podrán añadir
participantes y nuevos objetos de los cuatro tipos antes mencionados.

En SwellRT se accede a estos objetos a partir del identificador que se les otor-
gue al crearlos. En este caso se creará dentro de cada wave dos TextTypes
con identificadores ”howProp 2çostProp”para cada uno de los textos colabo-
rativos antes mencionados. Aśımismo, cada propuesta tendrá asociada una
wave con un identificador único generado por el servidor al crearse la wave.
Este identificador será el que se guarde en la base de datos para que cualquier
usuario pueda acceder a la edición colaborativa de la propuesta. El siguiente
es un esquema del uso de SwellRT en el proyecto.

En el caso de DemoCritics lo primero que se tendrá que hacer será registrar al
usuario usando su ID (Ver Sección 7.2.3.4). Esto se hace en el ”MainActivity”
al ejecutar la aplicación. Una vez registrado solo será necesario utilizar el
ServiceSwellRT para llevar a cabo dos actividades: crear una nueva propuesta
colaborativa y editar una propuesta ya creada.

Un ejemplo de cómo registrarse con SwellRT se puede encontrar en el Apéndi-
ce A.3.2.

116



CAPÍTULO 7. ARQUITECTURA DEL PROYECTO

Figura 7.13: Esquema de Uso de Wave/SwellRT

Figura 7.14: Esquema de Registro en SwellRT

Crear Propuesta Colaborativa:

Esta es una opción que se le ofrece al usuario en el caso de que, al hacer
una propuesta nueva, deje alguno de los campos de ”¿Cómo lo haŕıa?” o
de ”¿Cómo lo financiaŕıa?” en blanco. En tal caso, lo primero que se hace
es hacer un login en el servidor Wave llamando al método ”startSession”

117



CAPÍTULO 7. ARQUITECTURA DEL PROYECTO

del Service. Una vez que se ha iniciado sesión, se abre un nuevo modelo
(wave) en el servidor (ver Sección 7.1.2) para esta propuesta y se obtiene el
Id (”WaveId”) de dicho modelo creado para guardarlo en la base de datos
junto al resto de datos de la propuesta. Además, se le asocian al elemento
”root” del modelo uno o dos documentos colaborativos del tipo TextType
llamados ”padHow” y ”padCost”, en función de si ha dejado los dos campos
vaćıos o sólo uno. Por último se añade como participante del modelo creado
al usuario que lo ha creado (su ID USER). Cabe destacar que la mayor parte
de la programación con el serviceSwellRT se lleva a cabo mediante callbacks
que responden a eventos como iniciar sesión, crear modelos, etc.

Un ejemplo simplificado del código encargado de crear el modelo se puede
ver en el Apéndice A.3.3.

Figura 7.15: Esquema de Creación de Pad Colaborativo en SwellRT

Editar Propuesta Colaborativa:

Cuando un usuario quiere echar una mano a otro en la redacción de su
propuesta, puede acceder a la propuesta colaborativa y editar los campos de
”¿Cómo lo haŕıa?” o de ”¿Cómo lo financiaŕıa?” en función de en qué necesite

118



CAPÍTULO 7. ARQUITECTURA DEL PROYECTO

ayuda el usuario. Para cada uno de estos campos existe un ”pad” en el
servidor wave asociado a una wave (ver Sección 7.1.2) cuyo identificador
”WaveId” está guardado en la base de datos. Cuando el usuario pulsa en uno
de los dos campos, se abre una nueva actividad ”EditWaveActivity” que le
ofrece un campo ”EditText” de Android en el que puede escribir y ver lo
que otros escriben en tiempo real. Para esto hace falta abrir una sesión en
Wave, abrir el modelo con su WaveId, obtener el modelo y el pad, y asociar
(”bind”) el pad a el EditText del usuario para que el servicio sea capaz de
obtener los eventos de escritura del usuario.

Un ejemplo simplificado del código encargado de abrir el modelo y asociar el
pad colaborativo se puede ver en el Apéndice A.3.4.

Figura 7.16: Esquema de Apertura y Edición de Pad Colaborativo en SwellRT

119





Caṕıtulo 8

Evaluación con Usuarios

En esta última fase del proyecto, se realizarán evaluaciones de usuarios con el
prototipo final desarrollado en Android. Con esto se comprobará la experien-
cia de los usuarios evaluados con el resultado final del proyecto y se podrán
ver los objetivos que han sido logrados y posibles mejoras y modificaciones
futuras.

8.1. Propósitos y objetivos de la evaluación

El objetivo principal de la evaluación pretende poner a prueba la funcionali-
dad de la aplicación con los usuarios. Queremos analizar cómo se desenvuel-
ven los usuarios con la aplicación y cómo utilizan las funcionalidades que
ofrece. Para ello determinamos si se cumplen los siguientes objetivos:

El usuario siente el control total sobre la aplicación.

El usuario es capaz de comprender las actividades que realiza.

Se cumplen los objetivos iniciales del proyecto (Ver Sección 1.2)

8.2. Preguntas de evaluación

A continuación se expone un listado de preguntas a las que se quiere respon-
der con los resultados de la evaluación.

¿Es fácil distinquir los elementos de la aplicación?

• ¿Se distinguen bien los iconos y śımbolos?

• ¿Es fácil acordarse de la ubicación de cada elemento?

¿Se entienden las transiciones entre pantallas?

121



CAPÍTULO 8. EVALUACIÓN CON USUARIOS

• ¿Puede saberse lo que esta realizando la aplicación por detrás?

¿Se pueden llevar a cabo las acciones con pocas pulsaciones?

• ¿Cuánto se tarda en realizar una acción?

• ¿Hay alguna tarea que requiera muchas pulsaciones?

¿Se pueden visualizar todas las opciones disponibles de un solo vistazo?

• ¿Es complicado localizar algún elemento o información a simple
vista?

8.3. Requisitos para los participantes de la

evaluación

La evaluación será realizada por dos tipos objetivo de participantes que se co-
rresponden con los definidos en la fase de modelado de personas (Ver Sección
6.3.3):

Ciudadano

• Ciudadano de a a pie inscrito en el censo con capacidad para votar
en las próximas elecciones.

• Edad: a partir de 18 años.

• Familiarizados con el uso de herramientas móviles, preferiblemente
en dispositivos Android.

Activista social

• Activista social que participa activamente en movimientos sociales
afines a una causa.

• Edad: a partir de 18 años.

• Familiarizados con el uso de herramientas de participación ciuda-
dana.

122



CAPÍTULO 8. EVALUACIÓN CON USUARIOS

8.4. Diseño experimental

Las evaluaciones tendrán una duración estimada entre 4 y 7 minutos. Rea-
lizando un total de 5 evaluaciones, formadas por ciudadanos y activistas
sociales mayores de 18 años. En cada una se deberán cumplir las siguientes
normas y pasos:

1. Se dará una breve introducción a los participantes, explicándoles la
temática de la aplicación y el objetivo que se persigue con ella.

2. El usuario recibirá una lista con las tareas a realizar durante la evalua-
ción. Para llevarlas a cabo, el usuario evaluado podrá tomarse todo el
tiempo que estime oportuno.

3. Durante la evaluación se mantendrá una reunión en un entorno cerrado
libre de distracciones con la persona evaluada para observar todas las
reacciones a la hora de realizar las tareas en la aplicación. El moderador
también apuntará los tiempos que tarda en finalizar las tareas.

4. Si el usuario evaluado no pudiera resolver una tarea en menos de 3-4
minutos, o quedase atascado en la misma por un tiempo superior a 45
segundos, el moderador le indicará que pase a la siguiente tarea. Se ano-
tarán con especial atención las tareas que no pudieran ser completadas
con éxito durante la evaluación.

5. Al final de la sesión el moderador apuntará todas las objeciones de la
evaluación, aśı como las conclusiones del mismo, para posteriormente
ponerlas en común y analizarlas.

8.5. Lista de tareas a realizar

Este es el listado de tareas que deberá realizar el usuario en la aplicación en
función del tipo:

Ciudadano

• Visualizar los diferentes programas poĺıticos que se prensentan a
las elecciones.

• Acceder a las secciones más debatidas, valoradas, comentadas, etc.

123



CAPÍTULO 8. EVALUACIÓN CON USUARIOS

• Visualizar una sección de la categoŕıa cultura y realizar un comen-
tario en ella.

• Cambiar su nombre de usuario de ”Anónimo” por otro.

• Añadir una sección a mis favoritos.

• Visualizar sus secciones favoritas.

• Valorar una sección después de haberla léıdo y realizar un comen-
tario valorando la sección.

Activista Social

• Visualizar el listado de propuestas publicadas en el sistema.

• Mostrar las propuestas de la categoŕıa educación publicadas hasta
el momento.

• Leer el contenido de una propuesta, valorarlo y realizar un comen-
tario.

• Añadir una propuesta a mis favoritos.

• Visualizar sus propuestas favoritas.

• Publicar una nueva propuesta en la categoŕıa vivienda.

• Colaborar en el desarrollo de una propuesta colaborativa.

• Publicar una propuesta colaborativa para que pueda desarrollarla
la comunidad.

8.6. Entorno y herramientas empleadas

Para realizar las evaluaciones se realizarán reuniones con los usuarios a eva-
luar en un entorno cerrado y libre de distracciones que le permita realizar
las tareas de evaluación explicando en voz alta sus impresiones y problemas.
Toda esta información será anotada para después ser debatida y contrastada
con el usuario.

En cuanto a la aplicación, se utilizará un archivo .apk en modo debug que se
le proporcionará al usuario evaluado para que la pueda instalar en su disposi-
tivo. Como requisito fundamental, el dispositivo de la persona evaluada debe
contar con una versión de Android igual o superior al API 15 (Ice Cream
Sandwich), y poseer una conexión a Internet estable para interactuar con la
aplicación sin problemas.

124



CAPÍTULO 8. EVALUACIÓN CON USUARIOS

8.7. Tareas del moderador

El moderador será el responsable de gúıar el proceso de la evaluación con
el usuario. Al comienzo de la evaluación el moderador solicitará al usuario
la instalación de DemoCritics en su dispositivo. Durante la evaluación el
moderador deberá realizar las siguientes acciones:

1. Mostrar al usuario la lista de tareas a realizar con la aplicación.. Se
informará al usuario de que deberá realizar las tareas sin ayuda, ni
interrupciones hasta el final.

2. Indicar al usuario que debe expresar en voz alta sus impresiones y
problemas que encuentre durante la interacción con la aplicación.

3. El moderador interrumpirá al usuario por un motivo de fuerza mayor,
es decir, si sucede algún acontecimiento que impida continuar con la
evaluación (fallo en la aplicación, servidor cáıdo, etcétera).

4. Si el usuario evaluado estuviera más de 2.5 minutos para resolver una
tarea, o quedara atascado más de 45 segundos en la misma, el mode-
rador comunicará al usuario que procesa con la siguiente tarea.

5. El moderador tomará nota de los tiempos que el usuario tarda en reali-
zar cada tarea. Aśı como también el tiempo total que dura la evaluación
con todas las tareas realizadas.

6. Tras completar todas las tareas asignadas, iniciará una breve sesión de
debriefing con el usuario para contrastar sus anotaciones.

8.8. Resultados de la evaluación con los usua-

rios

Se realizaron un total de 5 evaluaciones: 3 con usuarios ”ciudadanos” y 2
con usuarios con un perfil de ”activista social”. En la mayoŕıa de los casos se
completaron las tareas asignadas con mayor o menor soltura en función de
su experiencia previa con herramientas similares.

La mayor parte de los usuarios respondieron de forma flúıda al uso de la
aplicación. Bien porque al estar acostumbrados al utilizar aplicaciones en
Android que utilizaran interfaces basadas en Material Design, los elemen-
tos visuales de la aplicación les resultaron familiares. Sin embargo, algunos

125



CAPÍTULO 8. EVALUACIÓN CON USUARIOS

conceptos internos en la aplicación resultaron algo confusos para algunos
usuarios.

Comenzando por los usuarios que representaban el papel de ciudadano, es-
tos mostraban cierta confusión respecto a la representación de los programas
poĺıticos. Una de las movivaciones principales del proyecto es fomentar la
lectura de los programas poĺıticos por los electores, pues actualmente pocos
conocen cómo se estructura un programa poĺıtico en ĺıneas generales. Ha si-
do un factor determinante la incomprensión de los usuarios al ver secciones
que inclúıan texto, otras que no y otras que inclúıan enlaces a otras sub-
secciones. No obstante es un factor que viene condicionado de la estructura
que ha establecido el partido poĺıtico para su programa electoral. Por lo que
podemos encontrar programas que se adapten mejor o peor a esta forma de
representarlos.

Para los usuarios que juagaban el rol de activista social la interacción con
la aplicacion fue más flúıda que el perfil anterior, pues normalmente estaban
acostumbrados a herramientas relacionadas con el mundo de la poĺıtica y la
participación ciudadana. Para las propuestas normales los usuarios reaccio-
naron de forma normal, visualizando, creando, valorando o comentando las
propuestas publicadas. Sin embargo, una vez más el concepto de propuesta
colaborativa no fue del todo comprendido en un primer momento. Pero una
vez que el usuario vió cómo su propuesta pod́ıa ser editada en tiempo real
por otros usuarios, el concepto quedó más claro y les pareció bastante útil y
llamativo.

8.8.1. Comentarios sobre la interfaz

Respecto a la interfaz de la aplicación, su actual diseño no representó muchos
problemas graves. La selección de los iconos quizá no fue la mejor para repre-
sentar los elementos de la aplicación. Algunos usuarios tuvieron que leer la
descripción de cada elemento para saber a qué acción les llevaŕıa pulsar ese
elemento. En cuanto a la navegación y representación de los menús dentro
de la aplicación, los usuarios no tuvieron demasiados problemas por estar
familarizados con Material Design y el botón ”hamburguesa” de menú. Por
otro lado hubo usuarios que no entendieron a primera vista el uso de los bo-
tones de like, dislike, etc. pues no les quedó claro que pudieran pulsarlos para
opinar. Además, el ı́ndice desplegable accesible en la parte superior derecha
de las secciones solo fue utilizado por uno de los usuarios, pues los otros no
se dieron cuenta de su existencia.

Por otro lado los usuarios entendieron bien la navegación por tabs, y todos

126



CAPÍTULO 8. EVALUACIÓN CON USUARIOS

Tabla 8.1: Dificultad y tiempos de las tareas para el usuario del tipo ciuda-
dano.

Tarea Dificultad Tiempo
Visualizar los diferentes programas poĺıticos que se
prensentan a las elecciones.

1/5 <30 s

Acceder a las secciones más debatidas, valoradas,
comentadas, etc.

2/5 <30 s

Visualizar una sección de la catgoŕıa cultura de un
partido poĺıtico en concreto.

3/5 <45 s

Añadir una sección a mis favoritos. 2/5 <15 s
Visualizar tus secciones favoritas. 4/5 <45 s
Valorar una sección después de haberla léıdo y rea-
lizar un comentario valorando la sección.

1/5 <45 s

valoraron positivamente la opción de explorar el contenido por categoŕıas y de
guardar secciones o propuestas en favoritos. También destacaron la elección
de distintos colores para distinguir las distintas partes de la aplicación.

Sin embargo, en el caso de la edición de propuestas colaborativas, el no poder
diferenciar a los usuarios que estaban escribiendo en un mismo pad al mismo
tiempo es un problema del que se quejaron varios usuarios, pues algunos
estaban acostumbrados a utilizar herramientas como Google Docs que si que
los distinguen. Diferenciar a los usuarios que están escribiendo al mismo
tiempo por colores o marcadores ayuda a poder concentrarse en la escritura
y a poder distinguir el contenido de todo el documento. No obstante, les
gustó el uso de edición en tiempo real para colaborar unos con otros.

8.8.2. Resultados de las tareas

La mayor parte de las tareas fueron completadas con éxito. En la tablas 8.1
y 8.2, podemos ver el tiempo promedio que tardaron los usuarios en realizar
las tareas propuestas.

En cada tabla se muestra el tiempo promedio en segundos que los usuarios
consumieron en llevar a cabo la tarea, y la dificultad media sobre un total de
cinco puntos (siendo 0 una tarea fácil de realizar y 5 una tarea compleja
de realizar) que costó a los usuarios realizar las tareas.

127



CAPÍTULO 8. EVALUACIÓN CON USUARIOS

Tabla 8.2: Dificultad y tiempos de las tareas para el usuario del tipo activista
social.

Tarea Dificultad Tiempo
Visualizar el listado de propuestas publicadas en
el sistema.

1/5 <15 s

Mostrar las propuestas de la categoŕıa educación
publicadas hasta el momento.

3/5 <30 s

Leer el contenido de una propuesta, valorarlo y
realizar un comentario.

2/5 <45 s

Añadir una propuesta a mis favoritos. 2/5 <15 s
Visualizar tus propuestas favoritas. 2/5 <15 s
Publicar una nueva propuesta en la categoŕıa vi-
vienda en el sistema.

3/5 <45 s

Colaborar en el desarrollo de una propuesta cola-
borativa.

4/5 <60 s

Publicar una propuesta colaborativa para que pue-
da desarrollarla la comunidad.

3/5 <30 s

128



Caṕıtulo 9

Resultados y Trabajo Futuro

En este caṕıtulo se analizarán y discutirán los resultados en conjunto de todo
el Trabajo de Fin de Grado, aśı como algunas ĺıneas de trabajo futuro para
este proyecto.

Todo el código de Software libre desarrollado por nosotros está disponible en
el GitHub de la organización del proyecto:

https://github.com/Zorbel

9.1. Discusión de Resultados

SE ha desarrollado DemoCritics, una plataforma para dispositivos móvi-
les Android cuyo objetivo es juntar en un único sitio el mensaje de
la poĺıtica tradicional (visto en forma de su Programa Poĺıtico) con el
mensaje de los ciudadanos (visto en forma de Propuestas).

No podemos olvidar del ”leitmotiv” inicial de este proyecto, utilizar las capa-
cidades de colaboración en tiempo real de Wave/SwellRT en Android. Aśı, na-
cieron las propuestas colaborativas (o ”abiertas”). Propuestas en las que
un usuario al crearlas dejaba alguno de los dos campos (”¿Cómo la llevaŕıa a
cabo?” y ”¿Cómo la financiaria?”) en blanco para permitir a otros usuarios
que le echaran una mano mediante la edición colaborativa y en tiempo real
de esa parte de la propuesta. De esta manera utilizamos Wave/SwellRT en
un contexto más lógico que el de redactar la propuesta entera, pues al me-
nos dichos campos están sujetos a menos subjetividad que la declaración de
intenciones de una propuesta más al uso de las que se encuentran en las pla-
taformas actuales. Además, solamente el usuario inicial de la propuesta es el
único capaz de convertir la propuesta en ”definitiva”, cerrando la posibilidad
de su edicion con Wave cuando estime que la comunidad de ”expertos” ha
podido ayudarle a proponer algo coherente y viable.

Por otro lado, se ha querido aprovechar el auge de las redes sociales para ”so-
cializar” la plataforma. De esta forma los usuarios pueden generar contenido
e interés en el uso de la aplicación. Pueden dar su opinión mediante el uso de

129

https://github.com/Zorbel


CAPÍTULO 9. RESULTADOS Y TRABAJO FUTURO

”indicadores sociales” similares a los ”Me gusta” o ”No me gusta” tan pre-
sentes en las redes sociales. También pueden realizar sus propios comentarios
para generar debate y marcar contenido como favorito. Todo ello aplicado
tanto a secciones de programas poĺıticos como a propuestas hechas por otros
usuarios. Esto, por otro lado, nos permite en cierta manera ”cuantificar” el
interés de las personas, lo cual siempre resulta útil para clasificar el contenido
en forma de ”tops” de lo más valorado, lo más comentado, etc.

Aunque no solo es de utilidad para elaborar dichos filtros de visualización que
atraigan la atención de los usuarios, sino que también los propios partidos
poĺıticos podŕıan beneficiarse de ello para identificar sus propuestas poĺıticas
más controvertidas o más valoradas. Al final se trata de una especie de ”red
social” aplicada al ámbito poĺıtico en el que cualquiera de los actores puede
intervenir y beneficiarse del contenido que genera la comunidad.

También se utiliza un sistema de categorización tanto de secciones como de
propuestas para llevar a cabo esa unión entre los programas politicos y las
propuestas que tan necesaria nos parećıa para fomentar tanto la lectura de
secciones como la elaboración de propuestas. De hecho, esto atraeŕıa a usua-
rios que, lejos de querer leerse un programa poĺıtico, lo que buscan es conocer
el contenido de una determinada categoŕıa de su interés. Aunque actualmen-
te existen 6 categoŕıas (Sanidad, Educación, Empleo, Vivienda, Impuestos y
Cultura) la intención es que existan más y que incluso los propios usuarios in-
teresados puedan crear sus propias categoŕıas, tal y como se discutirá después
en el trabajo a futuro.

Desde un punto de vista técnico el desarrollo de DemoCritics aporta una
plataforma que es independiente de la tecnoloǵıa del cliente, pues se ha desa-
rrollado un Servicio Web REST que responde a peticiones HTTP accesibles
desde cualquier tipo de cliente que pueda realizar este tipo de peticiones.
Además se trata de un proyecto en el que se aporta una solución de Software
libre que no exist́ıa previamente, pues las opciones de colaboración en tiem-
po real en Android pasaban únicamente por soluciones privativas como el
Real Time API de Google. Su código está disponible en GitHub y cualquiera
puede estudiarlo, contribuir, copiarlo y utilizarlo libremente.

9.1.1. Resultados de la Evaluación con usuarios

En ĺıneas generales se puede decir que la aplicación ha sido recibida de forma
positiva por la mayor parte de los usuarios, siendo la innovación en torno a la
idea el factor potencial de la aplicación. Algunos de los usuarios estaban fa-
miliarizados con herramientas similares en otros entornos (Web), y valoraron

130



CAPÍTULO 9. RESULTADOS Y TRABAJO FUTURO

positivamente su traslado a una plataforma móvil.

Los usuarios apreciaron la posibilidad de poder leer los programas en el móvil,
como si de un programa de bolsillo se tratase, y poder valorarlos y opinar
sobre ellos. No obstante, la apariencia o representación de los programas es
algo que no ha atráıdo demasiado su atención. Por ello, se deberá trabajar
más en otra posible representación gráfica que capte más la atención del
usuario.

La interacción entre las tareas y la transición de las pantallas, no ha supuesto
un problema para los usuarios. A excepción de las propuestas colaborativas,
pues habŕıa que rediseñar el concepto para hacer la edición en tiempo real
más amigable en consonancia con otras herramientas similares.

Para la siguiente interacción del proceso de desarrollo, se proponen los si-
guientes puntos por orden de prioridad, teniendo en cuenta las recomenda-
ciones y evaluaciones de los usuarios:

1. Cambiar el aspecto de los iconos de la pantalla inicial por otros más
representativos a la actividad que respresentan.

2. Dar más visibilidad a los botones de opinión en secciones y propuestas.

3. Rediseñar la visualización de las secciones para una lectura más cómoda
y diferenciar bien los elementos con los que puede interactuar el usuario
de los que no.

4. Estudiar la visibilidad del ı́ndice de programa expansible en cada sec-
ción.

5. Mejorar el concepto de propuestas colaborativas con diferenciación de
usuarios por colores o etiquetas para mejorar su comprensión durante
su edición.

6. Estudiar la creación de nuevas categoŕıas que representen mejor las
prouestas y secciones de la aplicación.

7. Ofrecer más funcionalidades de personalización al usuario.

131



CAPÍTULO 9. RESULTADOS Y TRABAJO FUTURO

9.2. Reparto de Trabajo entre los componen-

tes del grupo

DemoCritics es un proyecto desarrollado por dos personas. Para su desarrollo
hemos elegido una metodoloǵıa de control de versiones que nos permite repar-
tir las tareas de forma eficaz (cualquiera de los dos puede ver en pocos pasos
lo hecho por el otro) y eficiente (lleva poco tiempo subir o descargarse los
cambios). Para ello creamos una organización en GitHub llamada ”Zorbel”
y gestionamos con git los cambios en el código de cualquiera de las partes
que conforman DemoCritics. Además, esto nos permitió también facilitar la
revisión del código por parte de los profesores del proyecto.

En general, todas las tareas se han llevado a cabo en forma paralela y con
una carga de trabajo equitativa entre ambos miembros. A continuación se
detallan un poco más estas tareas:

- Migración de SwellRT a Android: Tanto la investigación del funcio-
namiento de la tecnoloǵıa como la metodoloǵıa de migración se llevaron a
cabo por ambos miembros. Estos cambios se contrastaron en reuniones con
el director Pablo Ojanguren (desarrollador de SwellRT) a medida que se pro-
dućıan. De poner el API de trabajo con waves de SwellRT sobre el servicio
migrado se encargó Pablo.

- Desarrollo de la idea de la app: los dos miembros del proyecto nos
reunimos con los directores Samer y Pablo para hacer una sesión de brains-
torming y dar con una idea de aplicación que a ambos nos gustaŕıa realizar
y que hiciera uso de SwellRT.

- Diseño e Investigación: ambos hicimos reuniones periódicas para discutir
ideas iniciales, planificar la investigación y diseñar prototipos. Durante las
entrevistas de investigación procuramos estar ambos presentes para exponer
las idea, discutirlas y enseñarles los prototipos básicos a los entrevistados.
Posteriormente nos reunimos para sacar conclusiones y modificar los proto-
tipos. En definitiva, toda la fase basada en el Diseño Guiado por Objetivos
la realizamos en conjunto.

- Implementación de la aplicación: En este caso śı que hubo un reparto
de tareas más marcado por la poca experiencia previa que teńıamos con
distintas tecnoloǵıas. El diseño general de la aplicación, el Service REST y
la Base de Datos lo discutimos entre ambos. A la hora de implementarlo uno
de nosotros (Javier) conoćıa mejor la arquitectura de Android y se dedicó a
elaborar el funcionamiento del cliente mientras que el otro (Jaime) hab́ıa

132



CAPÍTULO 9. RESULTADOS Y TRABAJO FUTURO

trabajado previamente con Laravel y se dedicó a investigar y desarrollar
el Service REST y la conexión con la Base de Datos. No obstante, ambos
pusimos en común los cambios realizados, de manera que los dos tuvimos
un conocimiento de cómo funcionaba la aplicación en su conjunto. Durante
la última fase del proyecto de prefeccionamiento de detalles de la aplicación
ambos trabajamos para mejorar el cliente Android.

- Evaluación con Usuarios: planificamos juntos la dinámica de las evalua-
ciones y realizamos dos evaluaciones con usuarios cada uno de un total de 4
evaluaciones, procurando poner luego en común los resultados para discutir-
los y sacar conclusiones.

- Elaboración de la memoria: para la redacción de esta memoria pro-
cedimos a realizar varios posibles ı́ndices para su estructuración hasta que
obtuvimos un primer esqueleto de su estructura. Posteriormente nos reparti-
mos su redacción, procurando verificar con el compañero el contenido de todo
lo escrito. Esto se vió facilitado por el uso también para la memoris de git
GitHub como sistema de control de versiones (ver organización del proyecto
en GitHub). En general, habremos escrito ambos aproximadamente la mitad
del contenido de este documento cada uno (siendo siempre verificado por el
otro).

La tabla 9.1 muestra el reparto colaborativo de tareas entre los integrantes
del grupo.

Para el seguimiento del proyecto procuramos realizar mı́nimo una reunión
al mes, ya fuera con Samer, con Pablo o con ambos. Cabe destacar que,
si bien a veces no pudimos reunirnos en persona, el uso de herramientas de
mensajeŕıa instantánea (con especial mención a Telegram) y de videollamada
como Skype y Hangouts fue constante entre los involucrados en el proyecto.

9.3. Trabajo Futuro

Como ya se ha comentado con anterioridad la presente es una primera versión
de DemoCritics que nos sirve para tener una primera prueba de concepto de
algunas de sus funcionalidades y que haga uso de la migración de SwellRT
a Android. En esta versión hemos podido evaluar el funcionamiento general
de la idea y ponerla a prueba con algunos usuarios para mejorar su utilidad
de cara a continuar su desarrollo. Nuestro objetivo en este momento es apro-
vechar la oportunidad que se nos presenta en este año electoral para poner
realmente a prueba esta plataforma en las próximas elecciones generales. De
esta forma también podriamos analizar su uso antes, durante y después de

133



CAPÍTULO 9. RESULTADOS Y TRABAJO FUTURO

Tabla 9.1: Reparto colaborativo de tareas.
T

a
re

a
D

e
sc

ri
p

ci
ó
n

J
a
im

e
J
a
v
ie

r

M
ig

ra
ci

ón
d
e

S
w

el
lR

T
A

n
-

d
ro

id

M
ig

ra
r

la
p
la

ta
fo

rm
a

en
d
es

a-
rr

ol
lo

S
w

el
lR

T
a

A
n
d
ro

id
,

ad
ap

ta
n
d
o

la
s

cl
as

es
y

co
m

o-
p

on
en

te
s

p
ri

n
ci

p
al

es
p
ar

a
su

fu
n
ci

on
am

ie
n
to

en
A

n
d
ro

id
.

A
d
ap

ta
r

li
b
re

ŕı
a

H
T

T
P

p
a-

ra
re

la
li
za

r
p

et
ic

io
n
es

al
se

r-
v
id

or
y

es
ta

b
le

ce
r

la
co

n
e-

x
ió

n
.

E
st

ab
le

ce
r

la
co

n
ex

ió
n

b
id

i-
re

cc
io

n
al

a
tr

av
és

d
e

W
eb

-
S
o
ck

et
s

p
ar

a
el

in
te

rc
am

b
io

d
e

co
n
te

n
id

o
en

ti
em

p
o

re
al

.

D
es

ar
ro

ll
o

d
e

la
id

ea
ap

li
ca

ci
ón

E
st

u
d
ia

r
y

va
lo

ra
r

la
s

p
os

ib
le

s
so

lu
ci

on
es

p
ar

a
el

d
es

ar
ro

ll
o

d
e

u
n
a

ap
li
ca

ci
ón

m
óv

il
co

la
b

or
a-

ti
va

en
ti

em
p

o
re

al
.

E
va

lu
ar

el
d
es

ar
ro

ll
o

d
e

ap
li
ca

ci
on

es
co

la
b

or
at

iv
as

q
u
e

u
ti

li
za

ra
n

té
cn

ic
as

d
e

In
te

li
ge

n
ci

a
A

rt
ifi

ci
al

,
d
es

ti
n
ad

as
a

la
ed

u
ca

ci
ón

.

P
ro

m
ov

er
el

d
es

ar
ro

ll
o

d
e

ap
li
ca

ci
on

es
re

la
ci

on
a-

d
as

co
n

ge
ol

o
ca

li
za

ci
ón

en
m

ap
as

y
p
ro

d
u
cc

ió
n

au
d
iv

is
u
al

.

D
is

eñ
o

e
in

ve
st

i-
ga

ci
ón

C
on

cr
et

ar
en

tr
ev

is
ta

s
co

n
p

er
-

so
n
as

d
e

in
te

ré
s

p
ar

a
el

d
is

eñ
o

d
e

la
ap

li
ca

ci
ón

,
d
es

ar
ro

ll
ar

lo
s

b
o
ce

to
s

y
d
efi

n
ir

su
in

te
ra

c-
ci

ón
.

S
eg

u
im

ie
n
to

y
an

ál
is

is
d
e

la
s

en
tr

ev
is

as
y

d
es

ar
ro

ll
o

y
d
i-

se
ñ
o

d
e

lo
s

b
o
ce

to
s

a
p
ap

el
.

S
eg

u
im

ie
n
to

y
an

ás
li
si

s
d
e

la
s

en
tr

ev
is

ta
s

y
d
efi

n
ic

ió
n

d
e

la
in

te
ra

cc
ió

n
d
e

lo
s

p
ro

-
to

ti
p

os
.

Im
p
le

m
en

ta
ci

ón
d
e

la
ap

li
ca

ci
ón

D
es

ar
ro

ll
o

d
el

cl
ie

n
te

m
óv

il
en

A
n
d
ro

id
,

d
is

eñ
o

d
e

la
b
as

e
d
e

d
at

os
y

d
es

ar
ro

ll
o

d
el

S
er

v
ic

io
W

eb
.

D
is

eñ
o

d
e

la
b
as

e
d
e

d
at

os
,

d
es

ar
ro

ll
o

d
el

S
er

v
ic

io
W

eb
y

ap
oy

o
en

el
cl

ie
n
te

A
n
-

d
ro

id
.

D
is

eñ
o

d
e

la
b
as

e
d
e

d
at

os
,

d
es

ar
ro

ll
o

d
el

cl
ie

n
te

A
n
-

d
ro

id
y

ap
oy

o
en

el
S
er

v
ic

io
W

eb
.

E
va

lu
ac

ió
n

co
n

u
su

ar
io

s
E

va
lu

ac
io

n
es

d
e

la
ap

li
ca

ci
ón

fi
n
al

a
d
if

er
en

te
s

u
su

ar
io

s.
E

va
lu

ac
io

n
es

a
p

er
so

n
as

co
n

el
p

er
fi
l

d
e

ac
ti

v
is

ta
so

ci
al

.

E
va

lu
ac

io
n
es

a
p

er
so

n
as

co
n

el
p

er
fi
l

d
e

ci
u
d
ad

an
o

d
e

a
p
ie

.
E

la
b

or
ac

ió
n

d
e

m
em

or
ia

D
es

ar
ro

ll
o

d
e

la
m

em
or

ia
fi
n
al

d
el

p
ro

ye
ct

o
en

LA
T
E
X

˙
D

is
eñ

o,
es

tr
u
ct

u
ra

ci
ón

y
re

-
d
ac

ci
ón

d
e

la
m

em
or

ia
.

D
is

eñ
o,

es
tr

u
ct

u
ra

ci
ón

y
re

-
d
ac

ci
ón

d
e

la
m

em
or

ia
.

134



CAPÍTULO 9. RESULTADOS Y TRABAJO FUTURO

unas elecciones.

Para ello nos proponemos seguir poniéndonos en contacto con actores relacio-
nados con el mundo de la poĺıtica (activistas, poĺıticos, periodistas, académi-
cos, etc.) para realizar más entrevistas y someter la plataforma a nuevas
iteraciones del proceso de diseño, implementación y evaluación con los que
ir poco a poco mejorando sus caracteŕısticas. De paso también iremos gene-
rando interés entre los entrevistados y publicitando su uso.

En cualquier caso, el proyecto está disponible en forma de software libre bajo
licencia GNU GPLv3 que cualquiera puede estudiar, copiar y modificar para
desarrollar sus propias ideas inspirado por las nuestras.

9.3.1. Mejoras a la versión actual

Teniendo en cuenta los resultados de la evaluación con usuarios (Ver sección
9.1.1 creemos que las ĺıneas de trabajo futuro debeŕıan ir orientadas a me-
jorar la experiencia de usuario, modificando aspectos de la interfaz gráfica
que pudieron resultar más incomprensibles a las personas evaluadas, como
los iconos de la aplicación y su significado. También habŕıa que mejorar la
visualización de las distintas secciones del programa, que resultó confusa para
algunos de ellos.

Desde el punto de vista del desarrollo colaborativo en tiempo real de pro-
puestas, se debeŕıa estudiar la posibilidad de poder distinguir a los usuarios
participantes en la Wave y lo que escriben mediante el uso de indicadores de
color o etiquetas al estilo de otras plataformas web como Google Docs.

9.3.2. Nuevas caracteŕısticas

Durante el desarrollo del proyecto han ido surgiendo diversas ideas intere-
santes que se podŕıan aplicar en un futuro próximo dentro de la plataforma
de DemoCritics. Algunas de las posibilidades son:

- Desarrollo de Encuestas: de intención de voto, de afinidad, etc. con posibi-
lidad de obtener los resultados en tiempo real mediante SwellRT.

- Abrir la creación de categoŕıas nuevas a los usuarios, de manera que demos
más flexibilidad a la hora de crear y clasificar contenidos.

- Permitir que los usuarios hagan comparativas por temas entre las secciones
de los distintos programas de partidos poĺıticos. Buscar para ello la partici-
pación de colectivos sociales interesados.

135



CAPÍTULO 9. RESULTADOS Y TRABAJO FUTURO

- Creación de una hemeroteca de programas poĺıticos que permita navegar por
programas poĺıticos de anteriores elecciones. Útil por ejemplo para comprobar
la evolución de las propuestas de los partidos.

- Integración con redes sociales y mensajeŕıa instantánea para compartir
contenidos de la aplicación.

- Oraganizar jerárquicamente los usuarios, pudiendo existir grupos de usua-
rios que comparten las mismas inquietudes e intereses.

- Uso de inteligencia artificial para integrar sistemas recomendadores de con-
tenido por afinidad o de puesta en contacto entre usuarios por intereses si-
milares.

Asimismo, y gracias a la flexibilidad que nos permite el uso de un Service
REST, se estudiará la posibilidad de desarrollar un cliente web para la
aplicación, especialmente pensado para usuarios que están más familiariza-
dos con la elaboración de textos largos, como los de las propuestas, usando
un teclado. De esta manera enfocaŕıamos la aplicación móvil a la lectura de
contenidos y generación de opiniones y comentarios, mientras que las pro-
puestas se podŕıan redactar en el ordenador. Entendemos que la postura de
uso de un móvil es para usarlo durante un espacio corto de tiempo, por lo
que la existencia de un cliente web para ordenadores haŕıa la generación de
contenidos más serios y extensos, como las propuestas, mucho más cómoda.

Por otro lado, en el desarrollo de este proyecto hemos centrado la plataforma
en los programas poĺıticos, pero se podŕıa utilizar para mostrar otros tipos de
documentos estructurados susceptibles de ser sometidos a debate y opinión.
Como por ejemplo normativas, leyes, manuales, etc.

136



Conclusions

Developing a project like DemoCritics has not been simple. Being an applica-
tion made from scratch from our own idea and initiative, it requires a lot
of dedication in the form of time and motivation. Moreover, if we talk about
a topic such as politics, which unfortunately doesn’t seem to attract all the
attention and interest of the people it should really have as we are part of
our society. In this sense, the time spent on the previous work of planning,
research, design and evaluation of prototypes was necessary to establish
a solid foundation on which to build the implementation of useful social
characteristics.

This process demonstrates the importance of the developer, usually used to
have a fairly low vision of technical aspects, being aware of the need to
involve in developing other voices. These voices may not have the exper-
tise needed to ” implement ” the idea, but it does provide a broader overview
that helps to better understand the real needs of the user, which ultimately
is the recipient of the application. Therefore, conducting interviews and
subsequent evaluations to take into account the opinion of the potential
” client ” has confronted us with a necessary reality for any developer who
wants to get a serious product. Moreover when we consider DemoCritics
as an application that goes beyond the scope of the Final Degree
Project and will become a useful tool in the near future.

The results achieved are reflected in the current state of DemoCritics. For the
first time citizens have within reach a space to consult all political options
(wherever they come), learn about them, discuss them and value them. As
well as participate in a participatory process of citizens’ proposals, giving
them the opportunity to give visibility to their proposal or collaborate in the
development of others. The social potential of the application is also utilised
by the possibility of review, comment and bookmark all the contents of the
application.

Also it makes real-time collaboration technology available for the com-
munity of Free Software developers in Android, so they could use of these
features in future development of applications. As well as the application that
contains the Free Software platform for citizen participation DemoCritics,
that any user could adapt to the needs and options of their region, country
or community.

137



CAPÍTULO 9. RESULTADOS Y TRABAJO FUTURO

There is still room for improvements, because this platform is a first
version of a project that, with further research and development, we
intend to put into practice in a real scenario of the upcoming general
elections that will be held during the coming months.

138



Conclusiones

Desarrollar un proyecto como DemoCritics no ha sido tarea sencilla. Al tra-
tarse de una aplicación que parte de cero desde nuestra propia idea e
iniciativa, exige bastante dedicación en forma de tiempo y motivación. Más
aún si hablamos de una temática como es la poĺıtica, que desgraciadamente
parece no atraer toda la atención e interés de las personas que realmente de-
beŕıa tener como actividad de la que formamos parte como sociedad. En este
sentido el tiempo dedicado a las labores previas de planificación, investi-
gación, diseño y evaluación de prototipos era necesario para establecer
unas bases sólidas sobre las que asentar la implementación de caracteŕısticas
que resultaran de utilidad social.

Este proceso demuestra la importancia de que el desarrollador, acostumbrado
normalmente a tener una visión bastante reducida a aspectos técnicos, sea
consciente de la necesidad de implicar en el desarrollo otras voces.
Dichas voces quizás no posean los conocimientos técnicos necesarios para
”implementar” la idea, pero śı que aportan una visión de conjunto más am-
plia que ayuda a entender mejor las necesidades reales del usuario, que a fin
de cuentas es el destinatario de la aplicación. Realizar por tanto entrevistas
y posteriores evaluaciones para tener en cuenta la opinión del futurible
”cliente” nos ha enfrentado a una realidad necesaria para cualquier desarro-
llador que quiera conseguir un producto serio. Más aun cuando nos plan-
teamos DemoCritics como una aplicación que trascienda el alcance
del Trabajo de Fin de Grado y se convierta en una herramienta
útil en el futuro próximo.

Los resultados obtenidos se plasman en el estado actual de DemoCritics.
Por vez primera la ciudadańıa tiene al alcance de sus manos un espacio
donde consultar todas las opciones poĺıticas (vengan de donde vengan),
aprender sobre ellas, debatirlas o valorarlas. Aśı como también participar en
un proceso participativo de propuestas ciudadanas, dándole la posibilidad
de dar visibilidad a su propuesta o colaborar en el desarollo de otras. Se
explota también el potencial social de la aplicación mediante la posibilidad
de opinar, realizar comentarios y marcar como favorito en todo el contenido
de la aplicación.

Se pone aśı tambien la tecnoloǵıa de colaboración en tiempo real a
disposición de la comunidad de desarrolladores de Software libre en An-
droid para que hagan uso de estas funcionalidades en sus futuras aplicaciones.

139



CAPÍTULO 9. RESULTADOS Y TRABAJO FUTURO

Aśı como también la aplicación que contiene la plataforma de Software libre
de participación ciudadana de DemoCritics, que cualquier usuario podŕıa
adaptar a las necesidades y opciones de su región, páıs o comunidad.

Existe todav́ıa margen de mejora, pues la presente plataforma es una
primera versión de un proyecto en el que pretendemos seguir investigando
y desarrollando para ponerla en práctica en un escenario real de cara a
las próximas elecciones generales que se celebrarán durante los próximos
meses.

140



Apéndice A

Listados de Código Fuente

En este apéndice se recogen solo algunos fragmentos de código que se estiman
representativos para complementar la información que se expone a lo largo
de todo este documento. Se recoge código tanto de la Migración de SwellRT
a Android, del desarrollo del Servicio Web REST y de la implementación de
la aplicación Android.

Todo el código del proyecto es libre y está disponible en forma de repositorio
bajo la organización llamada ”Zorbel” en la siguiente URL:

HTTPs://github.com/Zorbel

A.1. Migración de Wave a Android: SwellRT

A.1.1. Esquema de conexión HTTP

import java.net.HttpURLConnection;

private void login(final String user , final String password ,

final Callback <String , String > callback) {

// Construct the URL String urlStr with the server , user

and password parameters

URL url = new URL(urlStr); // String

HttpURLConnection connection = (HttpURLConnection) url.

openConnection (); //Open the connection to the given

URL

connection.setDoOutput(true); // allow the POST

connection

connection.setRequestProperty("Accept -Charset", CHARSET);

connection.setRequestProperty("Content -Type", "

application/x-www -form -urlencoded;charset=" + CHARSET)

;

OutputStream out = connection.getOutputStream ();

out.write(queryStr.getBytes(CHARSET)); //Set the POST

parameters

141

HTTPs://github.com/Zorbel


APÉNDICE A. LISTADOS DE CÓDIGO FUENTE

if (connection.getResponseCode () != 200) {

//ERROR during the connection

connection.disconnect (); // Disconnect from the server

.

} else {

// Continue with the login process (WebSocket)

connection.disconnect (); // Disconnect from the server

.

}

}

A.1.2. Esquema de conexión con AsyncTask

private class LoginTask extends AsyncTask <String , Void ,

String > {

@Override

protected String doInBackground(String ... params) { //

method that executes on the new Thread without

blocking the UI Thread

login(params [0], params [1], params [2]); //Do the login

return sessionId // String needed for the WebSocket

connection and based on the cookie received from the

server.

}

@Override

protected void onPostExecute(String result) { // method

that executes on the UI Thread once doInBackground ()

finishes its execution.

if (result != null) {

callback.onLogin (); // Notify the login success using

the proper callback method

} else { //The doInBackGround method has had a problem

and the result of its execution was null

callback.onError("Wave Login Error"); // Notify the

login error using the proper callback method

}

}

}

142



APÉNDICE A. LISTADOS DE CÓDIGO FUENTE

A.1.3. Esquema de uso de WAsync

// Create the atmosphere client

AtmosphereClient client = ClientFactory.getDefault ().

newClient(AtmosphereClient.class);

// Configure client with URL

AtmosphereRequestBuilder requestBuilder = client.

newRequestBuilder ()

.method(Request.METHOD.GET).trackMessageLength(true).uri(

WaveSocketWAsync.this.urlBase)

.transport(Request.TRANSPORT.WEBSOCKET)

// Create and configure socket

WaveSocketWAsync.this.socket = client.create(client.

newOptionsBuilder ().runtime(ahc).build ())

.on(Event.OPEN.name(), new Function <String >() { //

Equivalent to GWT onOpen () method

@Override

public void on(String arg0) {

// set the actions to do and call the proper

callback function (callback.onConnect ())

}

}).on(Event.CLOSE.name(), new Function <String >() { //

Equivalent to GWT onClose () method

@Override

public void on(String arg0) {

// set the actions to do and call the proper callback

function (callback.onDisconnect ())

}

}).on(Event.MESSAGE.name(), new Function <String >() {

@Override

public void on(String arg) { // Equivalent to GWT

onMessage () method

// set the actions to do and call the proper callback

function (callback.onMessage ())

}

}).on(new Function <Throwable >() {

@Override

public void on(Throwable t) {

// catch possible exceptions

}

});

try {

143



APÉNDICE A. LISTADOS DE CÓDIGO FUENTE

// connect to the server

socket.open(requestBuilder.build());

} catch (IOException e) {

// catch possible exceptions

}

//send a given message to the server , equivalent to GWT send(

msg) method

socket.fire(Data);

A.2. Servicio Web REST (Laravel)

A.2.1. Esquema de Rutas Simple

// Posibles operaciones con el objeto "propuesta"

Route ::get(’/proposal ’, ’ProposalController@index ’);

// Obtiene el listado de todas las propuestas

Route ::get(’/proposal /{id}’, ’ProposalController@show ’);

// Obtiene la prupuesta pasada por el campo {id}

Route ::post(’/proposal ’, ’ProposalController@create ’);

// Crea una nueva propuesta en el servidor

Route ::put(’/proposal /{id}’, ’ProposalController@update ’);

// Actualiza la propuesta pasada por {id}

Route :: delete(’/proposal /{id}’, ’ProposalController@destroy ’)

;

// Borra la propuesta pasada por {id}

A.2.2. Esquema de Rutas Agrupadas

Route ::group ([’prefix ’ => ’proposal ’], function ()

{

Route ::get(’/’, ’ProposalController@index ’);

Route ::get(’/{id}’, ’ProposalController@show ’);

Route ::post(’/’, ’ProposalController@create ’);

Route ::put(’/{id}’, ’ProposalController@update ’);

Route :: delete(’/{id}’,’ProposalController@destroy ’);

});

A.2.3. Esquema de Rutas de Propuestas Agrupadas

144



APÉNDICE A. LISTADOS DE CÓDIGO FUENTE

Route ::group ([’prefix ’ => ’proposal ’], function ()

{

Route ::get(’/’, ’ProposalController@index ’);

Route ::post(’/’, ’ProposalController@create ’);

Route ::group ([’prefix ’ => ’/{id}’], function ()

{

Route ::get(’/’, ’ProposalController@show ’);

Route ::put(’/’, ’ProposalController@update ’);

Route :: delete(’/’,’ProposalController@destroy ’);

});

});

A.2.4. Esquema de Controlador de Propuestas

<?php namespace App\Http\Controllers;

use App\Http\Requests;

use App\Http\Controllers\Controller;

use DB;

class ProposalController extends Controller {

/**

* Display a listing of the resource.

*

* @return Response

*/

public function index()

{

return DB:: select(’SELECT * FROM ‘proposal ‘’);

}

}

A.3. Aplicación Android

A.3.1. Función de construcción del árbol de Programa
Poĺıtico

protected int createIndex(Section parent , List <Section >

JSONResult , int index) {

// X = currentSection

Section currentSection = JSONResult.get(index);

145



APÉNDICE A. LISTADOS DE CÓDIGO FUENTE

if (parent.getlSections () == null) {

parent.setlSections(new ArrayList <Section >());

}

parent.addSubSection(currentSection);

// c = nextIndex

int nextIndex = index + 1;

while (( nextIndex < JSONResult.size()) && (getLevel(

JSONResult.get(nextIndex)) >= getLevel(currentSection)

)) {

if (getLevel(JSONResult.get(nextIndex)) == getLevel(

currentSection)) {

currentSection = JSONResult.get(nextIndex);

nextIndex ++;

parent.addSubSection(currentSection);

} else if (getLevel(JSONResult.get(nextIndex)) >

getLevel(currentSection))

nextIndex = createIndex(currentSection , JSONResult ,

nextIndex);

}

return nextIndex;

}

protected int getLevel(Section sec) {

int id_sec = sec.getmSection (), level;

if (id_sec % 100 != 0) {

level = 4;

} else if (id_sec % 10000 != 0) {

level = 3;

} else if (id_sec % 1000000 != 0) {

level = 2;

} else

level = 1;

return level;

}

A.3.2. Registrar Usuario en SwellRT

146



APÉNDICE A. LISTADOS DE CÓDIGO FUENTE

public class MainActivity implements ServiceConnection ,

SwellRTServiceCallback {

private SwellRTService mSwellRT;

protected void bindSwellRTService () {

if (mSwellRT == null) {

final Intent mWaveServiceIntent = new Intent(this

, SwellRTService.class);

bindService(mWaveServiceIntent , this , Context.

BIND_AUTO_CREATE);

}

}

@Override

protected void onCreate(Bundle savedInstanceState) {

// Create view and get view references

bindSwellRTService (); //Bind to the service

}

// AsyncTask for registering the user.

public void registerWaveUser () {

AsyncTask mRegisterTask = new AsyncTask <String , Void ,

Boolean >() {

@Override

protected Boolean doInBackground(

String ... params) {

return mSwellRT.registerUser(params

[0], params [1], params [2]);

}

@Override

protected void onPostExecute(Boolean

result) {

if (result)

Toast.makeText(MainActivity.this , "

User created successfully", Toast.

LENGTH_LONG).show();

else

Toast.makeText(MainActivity.this , "Error 

creating user", Toast.LENGTH_LONG).show();

}

};

// Execute task with the server , user and

password

147



APÉNDICE A. LISTADOS DE CÓDIGO FUENTE

mRegisterTask.execute(WAVE_SERVER , "" + User.ID_USER

+ "@local.net", "password");

}

// Callback called when the service is connected.

@Override

public void onServiceConnected(ComponentName name ,

IBinder service) {

mSwellRT = (( SwellRTService.SwellRTBinder) service).

getService(this);

Log.d(this.getClass ().getSimpleName (), "SwellRT 

Service Bound");

registerWaveUser (); //Do the register.

}

@Override

public void onServiceDisconnected(ComponentName name) {

mSwellRT = null;

Log.d(this.getClass ().getSimpleName (), "SwellRT 

Service unBound");

}

}

A.3.3. Crear nueva Wave (Model) en SwellRT

public class NewProposalActivity extends SwellRTActivity {

@Override

protected void onCreate(Bundle savedInstanceState)

{

//Get the proposal info from the user view ,

if there is no ’’how ’’ or ’’cost ’’, create

a new wave model.

}

public void doStartSession () {

// Open Session with ID_USER

try {

mSwellRT.startSession(MainActivity.WAVE_SERVER ,

"" + User.ID_USER + "@local.net", "

password");

} catch (MalformedURLException e) {

e.printStackTrace ();

} catch (InvalidParticipantAddress

invalidParticipantAddress) {

invalidParticipantAddress.printStackTrace ();

148



APÉNDICE A. LISTADOS DE CÓDIGO FUENTE

}

}

// SwellRT Service Callbacks

@Override

public void onServiceConnected(ComponentName name ,

IBinder service) {

mSwellRT = (( SwellRTService.SwellRTBinder) service).

getService(this);

doStartSession ();

Log.d(this.getClass ().getSimpleName (), "SwellRT 

Service Bound");

}

@Override

public void onStartSessionSuccess(String session) {

getService ().createModel ();

}

@Override

public void onCreate(Model model) { // Callback called

when a model is created.

// Get the Id of the wave/model to store in the

database

WaveId idW = model.getWaveId ();

String idWave = idW.toString ();

String id = "";

id = idWave.substring(8, idWave.length () - 1);

//Store the proposal (with the Wave Id) in the

database.

postCollaborativeProposal(id);

// Create a text document for each Pad

TextType padHow = model.createText(" Cmo  lo 

h a r a s ?");

TextType padCost = model.createText(" Cmo  lo 

financiarias?");

// Include the document as part of the wave/model in

the "root" map.

if(createHowWave)

model.getRoot ().put("padHow", padHow);

if(createCostWave)

model.getRoot ().put("padCost", padCost);

// Allow current user to read/write the text of the

Pad

149



APÉNDICE A. LISTADOS DE CÓDIGO FUENTE

model.addParticipant("" + User.ID_USER + "@local.net"

);

}

}

A.3.4. Abrir Pad colaborativo en SwellRT

public class EditWaveActivity extends SwellRTActivity

implements ServiceConnection , SwellRTService.

SwellRTServiceCallback {

@Override

protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_edit_wave);

//Get the id of the model from the intent

if (mModelId == null)

mModelId = getIntent ().getStringExtra("MODEL_ID")

;

//Get the id of the model from the intent

padName = getIntent ().getStringExtra("PAD_NAME");

//Get the reference to the editable EditText

mEditor = (EditText) findViewById(R.id.textWave);

}

//Start the session in the SwellRT Server

public void doStartSession () {

try {

getService ().startSession(MainActivity.

WAVE_SERVER ,

"" + User.ID_USER + "@local.net", "

password");

} catch (MalformedURLException e) {

e.printStackTrace ();

} catch (InvalidParticipantAddress

invalidParticipantAddress) {

invalidParticipantAddress.printStackTrace ();

}

}

// Connection and Events Callbacks

@Override

public void onConnect () {

doStartSession ();

}

150



@Override

public void onDisconnect () {

// Eventually unbind the EditText from the Doc

mDocBinder.unbind ();

}

@Override

public void onStartSessionSuccess(String s) {

getService ().openModel(mModelId);

}

@Override

public void onOpen(Model model) {

// Gets a reference to an already open Model

mModel = getService ().getModel(mModelId);

//Add actual participant

mModel.addParticipant("" + User.ID_USER + "@local.net

");

// Get the text document supporting the Pad from the

Model

Type instance = mModel.getRoot ().get(padName);

mText = (TextType) instance;

// Connect the EditText component to the Wave’s Doc

mDocBinder = WaveDocEditorBinder.bind(mEditor ,

getService ().getReadableDocument(mText));

}

@Override

protected void onDestroy () {

super.onDestroy ();

}

@Override

public void onBackPressed () {

getService ().closeModel(mModelId);

getService ().stopSession ();

super.onBackPressed ();

}

}

151



152



Bibliograf́ıa

[1] Glenn Greenwald and Ewen MacAskill. NSA Prism program taps in to
user data of Apple, Google and others — US news — The Guardian.
http://www.theguardian.com/world/2013/jun/06/

us-tech-giants-nsa-data.

[2] Understanding Operational Transformation.
http://www.codecommit.com/blog/java/

understanding-and-applying-operational-transformation.

[3] Paul Baran. On distributed communications networks. 1964.
Article available at https://www.rand.org/content/dam/rand/

pubs/research_memoranda/2006/RM3420.pdf.

[4] Google Inc. Realtime API: Add Realtime collaboration to your app.
https://developers.google.com/google-apps/realtime/.

[5] Microsoft. RTC Client API.
https://msdn.microsoft.com/en-us/library/ms775893%28v=vs.

85%29.aspx.

[6] Google Inc. WebRTC.
http://www.webrtc.org/.

[7] Mozilla Foundation. TogetherJS: Collaboration made easy.
https://togetherjs.com/.

[8] GitHub Inc. GitHub · Build software better, together.
https://github.com/.

[9] Joseph Gentle. ShareJS.
http://sharejs.org/.

[10] Chianwu Tian. Goodow: Google Docs–style collaboration via the use
of operational transforms.
https://github.com/goodow/realtime.

[11] Apache. Wave In A Box.
http://www.waveprotocol.org/wave-in-a-box/.

153

http://www.theguardian.com/world/2013/jun/06/us-tech-giants-nsa-data
http://www.theguardian.com/world/2013/jun/06/us-tech-giants-nsa-data
http://www.codecommit.com/blog/java/understanding-and-applying-operational-transformation
http://www.codecommit.com/blog/java/understanding-and-applying-operational-transformation
https://www.rand.org/content/dam/rand/pubs/research_memoranda/2006/RM3420.pdf
https://www.rand.org/content/dam/rand/pubs/research_memoranda/2006/RM3420.pdf
https://developers.google.com/google-apps/realtime/
https://msdn.microsoft.com/en-us/library/ms775893%28v=vs.85%29.aspx
https://msdn.microsoft.com/en-us/library/ms775893%28v=vs.85%29.aspx
http://www.webrtc.org/
https://togetherjs.com/
https://github.com/
http://sharejs.org/
https://github.com/goodow/realtime
http://www.waveprotocol.org/wave-in-a-box/


[12] Oracle Corporation. OpenJDK.
http://openjdk.java.net/.

[13] Google Inc. Google Web Toolkit.
http://www.gwtproject.org/.

[14] Apache. Install WIAB.
https://cwiki.apache.org/confluence/display/WAVE/Install+

WIAB.

[15] Apache. WIAB Repository.
https://github.com/apache/incubator-wave.

[16] WIAB Server Example.
http://waveinabox.net/.

[17] Google Inc. Google Docs.
https://drive.google.com/.

[18] The Etherpad Foundation. Etherpad.
http://etherpad.org/.

[19] TitanPad Authors. TitanPad: lets people work on one document si-
multaneously.
https://titanpad.com.

[20] Alexander Kirk. Colorillo.
http://colorillo.com/.

[21] Henry Oswald and James Allen. ShareLaTex: LaTeX, Evolved.
https://www.sharelatex.com/.

[22] Samepage Labs Inc. Samepage — The num. 1 Online Collaboration
Tool.
https://www.samepage.io/.

[23] Quip. Quip: Trabaja con personas, no con archivos.
https://quip.com/.

[24] Google. UPyD Parla - Aplicaciones de Android en Google Play.
https://play.google.com/store/apps/details?id=es.

kiketurry.upydparla.

[25] Google. RecuperaCórdoba - Aplicaciones de Android en Google Play.
https://play.google.com/store/apps/details?id=iucordoba.

com.recuperacordoba.

154

http://openjdk.java.net/
http://www.gwtproject.org/
https://cwiki.apache.org/confluence/display/WAVE/Install+WIAB
https://cwiki.apache.org/confluence/display/WAVE/Install+WIAB
https://github.com/apache/incubator-wave
http://waveinabox.net/
https://drive.google.com/
http://etherpad.org/
https://titanpad.com
http://colorillo.com/
https://www.sharelatex.com/
https://www.samepage.io/
https://quip.com/
https://play.google.com/store/apps/details?id=es.kiketurry.upydparla
https://play.google.com/store/apps/details?id=es.kiketurry.upydparla
https://play.google.com/store/apps/details?id=iucordoba.com.recuperacordoba
https://play.google.com/store/apps/details?id=iucordoba.com.recuperacordoba


[26] Google. PSOE Andalućıa - Aplicaciones de Android en Google Play.
https://play.google.com/store/apps/details?id=com.

phonegap.psoeandalucia.

[27] Google. PP Canarias - Aplicaciones de Android en Google Play.
https://play.google.com/store/apps/details?id=es.

ppdecanarias.app.

[28] Plaza Podemos: ¡Śı se puede!
https://www.reddit.com/.

[29] Reddit: the front page of the internet.
https://www.reddit.com/r/podemos/.

[30] Change.org · La mayor plataforma de peticiones del mundo.
https://www.change.org/.

[31] Programa colaborativo de Zaragoza en Común.
http://programa.ganemoszaragoza.com/.

[32] S.A. APPGREE. Appgree.
http://www.appgree.com/que-es-appgree/.

[33] S.A. APPGREE. DemoRank: El Algoritmo.
http://www.appgree.com/el-proceso-paso-a-paso/.

[34] Free Software Foundation. The GNU General Public License v3.0 -
GNU Project - Free Software Foundation.
https://www.gnu.org/licenses/gpl.html.

[35] The Bill and Melinda Gates Foundation. Human-Centered Design Tool-
kit: An Open-Source Toolkit to Inspire New Solutions in the Developing
World. Ideo, 2011.

[36] Alan Copper. The Inmates Are Running the Asylum: Why High Tech
Products Drive Us Crazy and How to Restore the Sanity. Sams Publis-
hing, 2004.

[37] Inc. Google. Meet Google Wave.
http://googlecode.blogspot.com.es/2009/05/

hello-world-meet-google-wave.html.

[38] Inc. Google. Google Wave Federation Protocol Over XMPP.
http://wave-protocol.googlecode.com/hg/spec/federation/

wavespec.html.

155

https://play.google.com/store/apps/details?id=com.phonegap.psoeandalucia
https://play.google.com/store/apps/details?id=com.phonegap.psoeandalucia
https://play.google.com/store/apps/details?id=es.ppdecanarias.app
https://play.google.com/store/apps/details?id=es.ppdecanarias.app
https://www.reddit.com/
https://www.reddit.com/r/podemos/
https://www.change.org/
http://programa.ganemoszaragoza.com/
http://www.appgree.com/que-es-appgree/
http://www.appgree.com/el-proceso-paso-a-paso/
https://www.gnu.org/licenses/gpl.html
http://googlecode.blogspot.com.es/2009/05/hello-world-meet-google-wave.html
http://googlecode.blogspot.com.es/2009/05/hello-world-meet-google-wave.html
http://wave-protocol.googlecode.com/hg/spec/federation/wavespec.html
http://wave-protocol.googlecode.com/hg/spec/federation/wavespec.html


[39] Inc. Google. End of Google Wave.
https://support.google.com/answer/1083134?hl=en.

[40] Google+.
https://plus.google.com/.

[41] Apache. Apache Wave (Incubating).
http://incubator.apache.org/wave/about.html.

[42] Apache. Apache License 2.0.
http://www.apache.org/licenses/LICENSE-2.0.

[43] Inc. Google. Wave Federation.
http://www.waveprotocol.org/federation.

[44] Google. Google Wave Federation Architecture White Paper.
http://wave-protocol.googlecode.com/hg/whitepapers/

google-wave-architecture/google-wave-architecture.html.

[45] Peter Saint-Andre. Extensible messaging and presence protocol
(xmpp): Core. 2011.
RFC 6120 Available at http://tools.ietf.org/html/rfc6120.

[46] Inc. Google. Google Wave Operational Transformation.
http://www.waveprotocol.org/whitepapers/

operational-transform.

[47] P2PValue. P2P Value European Project.
http://www.p2pvalue.eu/.

[48] P2PValue. SwellRT, a real-time federated collaboration framework.
https://github.com/P2Pvalue/swellrt.

[49] Google Inc. Android Developers Site.
http://developer.android.com/index.html.

[50] Eclipse Foundation. Eclipse IDE.
https://eclipse.org/ide/.

[51] Oracle Corporation. Java.
https://www.java.com/es/.

[52] Mozilla Foundation. JavaScript.
https://developer.mozilla.org/es/docs/Web/JavaScript.

156

https://support.google.com/answer/1083134?hl=en
https://plus.google.com/
http://incubator.apache.org/wave/about.html
http://www.apache.org/licenses/LICENSE-2.0
http://www.waveprotocol.org/federation
http://wave-protocol.googlecode.com/hg/whitepapers/google-wave-architecture/google-wave-architecture.html
http://wave-protocol.googlecode.com/hg/whitepapers/google-wave-architecture/google-wave-architecture.html
http://tools.ietf.org/html/rfc6120
http://www.waveprotocol.org/whitepapers/operational-transform
http://www.waveprotocol.org/whitepapers/operational-transform
http://www.p2pvalue.eu/
https://github.com/P2Pvalue/swellrt
http://developer.android.com/index.html
https://eclipse.org/ide/
https://www.java.com/es/
https://developer.mozilla.org/es/docs/Web/JavaScript


[53] Roy Fielding. Hypertext transfer protocol (http/1.1): Message syntax
and routing. 2014.
RFC 7230 Available at https://tools.ietf.org/html/rfc7230.

[54] Ian Fette and Alexey Melnikov. Hypertext transfer protocol (http/1.1):
Authentication. 2011.
RFC 6455 Available at https://tools.ietf.org/html/rfc6455.

[55] Linus Torvalds. Git.
https://git-scm.com/.

[56] Google Inc. Android Studio IDE.
https://developer.android.com/tools/studio/index.html.

[57] JetBrains. IntelliJ IDEA IDE.
https://www.jetbrains.com/idea/.

[58] Google Inc. Android 5.0 APIs.
https://developer.android.com/about/versions/android-5.0.

html.

[59] Google Inc. Android SDK.
https://developer.android.com/sdk/index.html.

[60] Google Inc. Android API Reference.
http://developer.android.com/reference/packages.html.

[61] Google Inc. Android Virtual Device Manager.
http://developer.android.com/tools/devices/managing-avds.

html.

[62] Google Inc. Using the Android Emulator.
http://developer.android.com/tools/devices/emulator.html.

[63] Google Inc. Managing AVDs with AVD Manager.
https://developer.android.com/tools/devices/managing-avds.

html.

[64] Google Inc. Android SDK Manager.
https://developer.android.com/tools/help/sdk-manager.html.

[65] Google Inc. Android Dalvik Debug Monitor Server.
http://developer.android.com/tools/debugging/ddms.html.

157

https://tools.ietf.org/html/rfc7230
https://tools.ietf.org/html/rfc6455
https://git-scm.com/
https://developer.android.com/tools/studio/index.html
https://www.jetbrains.com/idea/
https://developer.android.com/about/versions/android-5.0.html
https://developer.android.com/about/versions/android-5.0.html
https://developer.android.com/sdk/index.html
http://developer.android.com/reference/packages.html
http://developer.android.com/tools/devices/managing-avds.html
http://developer.android.com/tools/devices/managing-avds.html
http://developer.android.com/tools/devices/emulator.html
https://developer.android.com/tools/devices/managing-avds.html
https://developer.android.com/tools/devices/managing-avds.html
https://developer.android.com/tools/help/sdk-manager.html
http://developer.android.com/tools/debugging/ddms.html


[66] Google Inc. Android Debug Bridge.
http://developer.android.com/tools/help/adb.html.

[67] Google Inc. Android Versions Distribution.
https://developer.android.com/about/dashboards/index.html.

[68] World Wide Web Consortium. Extensible Markup Language (XML).
http://www.w3.org/XML/.

[69] Google Inc. Android Layouts.
https://developer.android.com/guide/topics/ui/

declaring-layout.html.

[70] Introducing JSON.
http://json.org/.

[71] ISO. ISO/IEC 9075-1:2011 - Information technology – Database
languages – SQL.
http://www.iso.org/iso/home/store/catalogue_tc/catalogue_

detail.htm?csnumber=53681.

[72] Oracle Corporation. MySQL :: The world’s most popular open source
database.
https://www.mysql.com/.

[73] The PhpMyAdmin Project. PhpMyAdmin: Bringing MySQL to the
web.
http://www.phpmyadmin.net/.

[74] The PHP Group. PHP: Hypertext Preprocessor.
https://php.net/.

[75] Taylor Otwell. Laravel - The PHP Framework For Web Artisans.
http://laravel.com/.

[76] Taylor Otwell. The Laravel PHP Framework.
https://github.com/laravel.

[77] Inc. Red Hat. OpenShift by Red Hat.
https://www.openshift.com/.

[78] Jon Skinner. Sublime Text: The text editor you’ll fall in love with.
https://www.sublimetext.com/.

158

http://developer.android.com/tools/help/adb.html
https://developer.android.com/about/dashboards/index.html
http://www.w3.org/XML/
https://developer.android.com/guide/topics/ui/declaring-layout.html
https://developer.android.com/guide/topics/ui/declaring-layout.html
http://json.org/
http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=53681
http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=53681
https://www.mysql.com/
http://www.phpmyadmin.net/
https://php.net/
http://laravel.com/
https://github.com/laravel
https://www.openshift.com/
https://www.sublimetext.com/


[79] WooMoo Inc. POP - Prototyping on Paper — Mobile App Prototyping
Made Easy.
https://popapp.in/.

[80] Google Inc. Building Apps with Over 65K Methods.
https://developer.android.com/tools/building/multidex.

html.

[81] Google Inc. ProGuard.
http://developer.android.com/tools/help/proguard.html.

[82] Google Inc. Activities.
https://developer.android.com/guide/components/activities.

html.

[83] Roy Fielding. Hypertext transfer protocol (http/1.1): Authentication.
2014.
RFC 7235 Available at https://tools.ietf.org/html/rfc7235.

[84] Google Inc. System Permissions.
https://developer.android.com/guide/topics/security/

permissions.html.

[85] Google Inc. App Manifest.
https://developer.android.com/guide/topics/manifest/

manifest-intro.html.

[86] Google Inc. Emulator Networking: Network Address Space.
https://developer.android.com/tools/devices/emulator.html#

emulatornetworking.

[87] Google Inc. Android LogCat.
https://developer.android.com/tools/help/logcat.html.

[88] Google Inc. Apache HTTP Library.
https://developer.android.com/reference/org/apache/http/

package-summary.html.

[89] Google Inc. Android’s HTTP Clients.
http://android-developers.blogspot.com.es/2011/09/

androids-http-clients.html.

[90] Google Inc. HttpURLConnection Library.
https://developer.android.com/reference/java/net/

HttpURLConnection.html.

159

https://popapp.in/
https://developer.android.com/tools/building/multidex.html
https://developer.android.com/tools/building/multidex.html
http://developer.android.com/tools/help/proguard.html
https://developer.android.com/guide/components/activities.html
https://developer.android.com/guide/components/activities.html
https://tools.ietf.org/html/rfc7235
https://developer.android.com/guide/topics/security/permissions.html
https://developer.android.com/guide/topics/security/permissions.html
https://developer.android.com/guide/topics/manifest/manifest-intro.html
https://developer.android.com/guide/topics/manifest/manifest-intro.html
https://developer.android.com/tools/devices/emulator.html#emulatornetworking
https://developer.android.com/tools/devices/emulator.html#emulatornetworking
https://developer.android.com/tools/help/logcat.html
https://developer.android.com/reference/org/apache/http/package-summary.html
https://developer.android.com/reference/org/apache/http/package-summary.html
http://android-developers.blogspot.com.es/2011/09/androids-http-clients.html
http://android-developers.blogspot.com.es/2011/09/androids-http-clients.html
https://developer.android.com/reference/java/net/HttpURLConnection.html
https://developer.android.com/reference/java/net/HttpURLConnection.html


[91] Google Inc. Processes and Threads.
https://developer.android.com/guide/components/

processes-and-threads.html.

[92] Google Inc. Android AsyncTask.
https://developer.android.com/reference/android/os/

AsyncTask.html.

[93] Google Inc. Connecting to the Network.
https://developer.android.com/training/basics/network-ops/

connecting.html.

[94] Async-IO.org. Atmosphere: The Asynchronous WebSocket/Comet Fra-
mework.
https://github.com/Atmosphere/atmosphere.

[95] Async-IO.org. wAsync: A WebSockets/HTTP Client Library for Asyn-
chronous Communication.
https://github.com/Atmosphere/wasync.

[96] Wave Client for Android.
https://github.com/Zorbel/swell-android.

[97] Async-IO.org. Configuring the underlying AHC provider.
https://github.com/Atmosphere/wasync/wiki/

Configuring-the-underlying-AHC-provider.

[98] QOS.ch. SLF4J for Android.
http://www.slf4j.org/android/.

[99] Google Inc. Android Services.
https://developer.android.com/guide/components/services.

html.

[100] Async-IO.org. Async Http Client.
https://github.com/AsyncHttpClient/async-http-client.

[101] Project Grizzly. Project Grizzly: NIO Event Development Simplified.
https://grizzly.java.net/index.html.

[102] Labodemo.
http://labodemo.net/es/.

160

https://developer.android.com/guide/components/processes-and-threads.html
https://developer.android.com/guide/components/processes-and-threads.html
https://developer.android.com/reference/android/os/AsyncTask.html
https://developer.android.com/reference/android/os/AsyncTask.html
https://developer.android.com/training/basics/network-ops/connecting.html
https://developer.android.com/training/basics/network-ops/connecting.html
https://github.com/Atmosphere/atmosphere
https://github.com/Atmosphere/wasync
https://github.com/Zorbel/swell-android
https://github.com/Atmosphere/wasync/wiki/Configuring-the-underlying-AHC-provider
https://github.com/Atmosphere/wasync/wiki/Configuring-the-underlying-AHC-provider
http://www.slf4j.org/android/
https://developer.android.com/guide/components/services.html
https://developer.android.com/guide/components/services.html
https://github.com/AsyncHttpClient/async-http-client
https://grizzly.java.net/index.html
http://labodemo.net/es/


[103] Javier de la Cueva. Javier de la Cueva: abogado, doctor en Filosof́ıa y
estudioso de las relaciones entre el Derecho y la Tecnoloǵıa.
http://www.javierdelacueva.es/bio/.

[104] Javier de la Cueva. Manual del ciberactivista. Teoŕıa y práctica de las
acciones micropoĺıticas. Bandaàparte Editores, 2015.

[105] Jakob Nielsen. 10 Heuristics for User Interface Design: Article by Jakob
Nielsen.
http://www.nngroup.com/articles/ten-usability-heuristics/.

[106] Google Inc. Material design - Google design guidelines.
http://www.google.com/design/spec/material-design/

introduction.html.

[107] Inc. Google. Google Wave Conversation Model.
https://wave-protocol.googlecode.com/hg/spec/conversation/

convspec.html.

[108] Inc. Google. Google Wave API Overview.
http://www.waveprotocol.org/wave-apis.

[109] Inc. Google. Google Wave Extensions.
http://www.waveprotocol.org/wave-apis/extensions.

[110] P2PValue. SwellRT Client for Android.
https://github.com/P2Pvalue/swellrt/tree/master/android.

[111] Roy Thomas Fielding. Architectural Styles and the Design of Network-
based Software Architectures. PhD thesis, University of California, Ir-
vine, 2000.

[112] Martin Heller. REST and CRUD: the Impedance Mismatch —
InfoWorld.
http://www.infoworld.com/article/2640739/

application-development/rest-and-crud--the-impedance-mismatch.

html.

[113] Stefan Jauker. 10 Best Practices for Better RESTful API — Thinking
Mobile.
http://blog.mwaysolutions.com/2014/06/05/

10-best-practices-for-better-restful-api/.

161

http://www.javierdelacueva.es/bio/
http://www.nngroup.com/articles/ten-usability-heuristics/
http://www.google.com/design/spec/material-design/introduction.html
http://www.google.com/design/spec/material-design/introduction.html
https://wave-protocol.googlecode.com/hg/spec/conversation/convspec.html
https://wave-protocol.googlecode.com/hg/spec/conversation/convspec.html
http://www.waveprotocol.org/wave-apis
http://www.waveprotocol.org/wave-apis/extensions
https://github.com/P2Pvalue/swellrt/tree/master/android
http://www.infoworld.com/article/2640739/application-development/rest-and-crud--the-impedance-mismatch.html
http://www.infoworld.com/article/2640739/application-development/rest-and-crud--the-impedance-mismatch.html
http://www.infoworld.com/article/2640739/application-development/rest-and-crud--the-impedance-mismatch.html
http://blog.mwaysolutions.com/2014/06/05/10-best-practices-for-better-restful-api/
http://blog.mwaysolutions.com/2014/06/05/10-best-practices-for-better-restful-api/


[114] Google Inc. Android Widget.
https://developer.android.com/reference/android/widget/

package-summary.html.

[115] Google Inc. Android Adapter.
https://developer.android.com/reference/android/widget/

Adapter.html.

[116] Google Inc. Android Action Bar.
https://developer.android.com/guide/topics/ui/actionbar.

html.

[117] Google Inc. IOsched app Sliding Tabs.
https://github.com/google/iosched/blob/master/android/

src/main/java/com/google/samples/apps/iosched/ui/widget/

SlidingTabLayout.java.

[118] Google Inc. Android Fragments.
https://developer.android.com/guide/components/fragments.

html.

[119] Google Inc. Android Menus.
https://developer.android.com/guide/topics/ui/menus.html.

[120] Google Inc. Android Secure Settings.
https://developer.android.com/reference/android/provider/

Settings.Secure.html.

162

https://developer.android.com/reference/android/widget/package-summary.html
https://developer.android.com/reference/android/widget/package-summary.html
https://developer.android.com/reference/android/widget/Adapter.html
https://developer.android.com/reference/android/widget/Adapter.html
https://developer.android.com/guide/topics/ui/actionbar.html
https://developer.android.com/guide/topics/ui/actionbar.html
https://github.com/google/iosched/blob/master/android/src/main/java/com/google/samples/apps/iosched/ui/widget/SlidingTabLayout.java
https://github.com/google/iosched/blob/master/android/src/main/java/com/google/samples/apps/iosched/ui/widget/SlidingTabLayout.java
https://github.com/google/iosched/blob/master/android/src/main/java/com/google/samples/apps/iosched/ui/widget/SlidingTabLayout.java
https://developer.android.com/guide/components/fragments.html
https://developer.android.com/guide/components/fragments.html
https://developer.android.com/guide/topics/ui/menus.html
https://developer.android.com/reference/android/provider/Settings.Secure.html
https://developer.android.com/reference/android/provider/Settings.Secure.html

	Autorización de Difusión y Uso
	Agradecimientos
	Abstract
	Resumen
	Introducción
	Antecedentes
	Marco teórico: Política en el mundo de la Informática
	Idea detrás de DemoCritics

	Objetivos del Proyecto
	Estructura del Documento

	Estado del Arte
	Edición Colaborativa en Tiempo Real
	APIs Centralizadas
	Google Realtime API
	Microsoft RTC Client API
	WebRTC
	Mozilla TogetherJS
	ShareJS
	Goodow

	Plataformas Web y Android
	Wave: Wave In A Box (WIAB)
	Google Docs
	Etherpad
	Colorillo
	ShareLaTeX
	Samepage
	Quip


	Aplicaciones de Participación Política y Ciudadana
	Programas Políticos
	UPyD Parla
	RecuperaCórdoba
	PSOE Andalucía
	PP Canarias

	Participación Ciudadana
	Reddit
	Change.org
	Programas Colaborativos de Ahora Madrid y Zaragoza en Común
	Appgree



	Metodologías del Proyecto
	Uso de Software Libre
	Migración de Wave/SwellRT a Android
	Diseño de la Aplicación
	Brainstorming
	Diseño Guiado por Objetivos (DGO)
	Brainstorming
	Diseño Guiado por Objetivos (DGO)

	Implementación de la Aplicación
	Control de versiones
	GitHub
	Reparto de tareas
	Revisiones de código
	Evaluaciones de usabilidad

	Patrones de Diseño

	Tecnologías del Proyecto
	Tecnologías de Wave
	Google Wave
	Apache Wave
	Características de Wave
	Federación
	Consistencia en tiempo real
	Escalabilidad

	Servidores Wave: SwellRT
	Eclipse
	Java
	GWT
	JavaScript
	HTTP
	WebSocket
	Git
	GitHub

	Tecnologías de la Aplicación Android
	Android Studio
	Android
	XML
	JSON
	SQL
	MySQL
	PhpMyAdmin
	PHP
	Laravel 5
	OpenShift
	Sublime Text
	POP: Prototyping On Paper


	Migración de SwellRT a Android
	Objetivo
	Migración: Identificación y Solución de Problemas
	Construcción y Depuración
	Conexión HTTP
	Conexión WebSocket
	Conexión final y Logging
	Organización del código: Servicio Android

	Dependencias
	Resultado de la Migración


	Diseño de la Aplicación
	Introducción
	Brainstorming de ideas
	Diseño Guiado Por Objetivos (DGO)
	Investigación
	Investigación
	Intención Inicial: Prototipo básico
	Hipótesis de personas
	Entrevistas

	Modelado y Definición de Personas
	Definición de Escenarios y Requisitos
	Framework de diseño
	Framework de interacción

	Verificación: Principios de Diseño


	Arquitectura del Proyecto
	Arquitectura de Wave
	Modelo Conversacional Wave
	Modelo de Contenidos SwellRT

	Arquitectura de la aplicación
	Base de datos
	political_party
	section
	proposal
	comment
	opinion

	Servicio Web REST
	Arquitectura
	Rutas
	Controladores

	Cliente Android
	Interfaz Gráfica
	Estructuración de Programas Políticos
	Conexión y Peticiones a Service REST y Base de Datos
	Gestión de Usuarios: ID de Android
	Servicio Android, Conexión con Wave/SwellRT y Gestión de Propuestas Colaborativas



	Evaluación con Usuarios
	Propósitos y objetivos de la evaluación
	Preguntas de evaluación
	Requisitos para los participantes de la evaluación
	Diseño experimental
	Lista de tareas a realizar
	Entorno y herramientas empleadas
	Tareas del moderador
	Resultados de la evaluación con los usuarios
	Comentarios sobre la interfaz
	Resultados de las tareas


	Resultados y Trabajo Futuro
	Discusión de Resultados
	Resultados de la Evaluación con usuarios

	Reparto de Trabajo entre los componentes del grupo
	Trabajo Futuro
	Mejoras a la versión actual
	Nuevas características


	Conclusions
	Conclusiones
	Listados de Código Fuente
	Migración de Wave a Android: SwellRT
	Esquema de conexión HTTP
	Esquema de conexión con AsyncTask
	Esquema de uso de WAsync

	Servicio Web REST (Laravel)
	Esquema de Rutas Simple
	Esquema de Rutas Agrupadas
	Esquema de Rutas de Propuestas Agrupadas
	Esquema de Controlador de Propuestas

	Aplicación Android
	Función de construcción del árbol de Programa Político
	Registrar Usuario en SwellRT
	Crear nueva Wave (Model) en SwellRT
	Abrir Pad colaborativo en SwellRT


	Bibliografía