Funcionamiento de la sincronización con servidor para el trust

[GReaper]

Para el cálculo del trust es necesario disponer de bastante información de la red social. En esta issue se explicará el funcionamiento de la parte de obtención de dicha información y guardado en servidor. El cálculo del trust se abordará en otra diferente.

• 1.- Tablas empleadas en servidor Toda la información se almacenará en servidor (nada en cliente). Se usarán las mismas tablas que se emplean para el guardado de datos en el proyecto de Gonzalo y Lara. La información guardada también será la misma. Sí cambiarán algunos tipos (p. ej.: ciertos IDs no serán BIGINT sino VARCHAR).
• 2.- Nuevo Servlet de sincronización Para mantener los datos actualizados se creará un nuevo Servlet que permitirá a los clientes sincronizar los datos de los usuarios. Este Servlet atenderá peticiones por POST en la URL <ssii_base>/sincronizar.doy tendrá como parámetros:
  • tipo : será un enum con valores aún por determinar y que indicará el tipo de datos que se están actualizando (amigos, mensajes, etc.).
  • datos: será un JSON enviado como String que contendrá todos los datos a sincronizar. El formato dependerá del tipo de datos a sincronizar y aún está pendiente de decisión.
• 3.- Implementación en cliente
  • Se ha creado una nueva función en ConectorRedSocial denominada sincronizarDatosRedSocial que se encargará de lanzar todas las peticiones a la red social concreta y la sincronización con servidor. Todo el proceso se realizará en segundo plano, en paralelo y de forma transparente al usuario.
  • Actualmente este método ya está redefinido en ConectorFacebook.sincronizarDatosRedSocial(). Como se puede ver, lo que ocurre en ese caso es que se ha dividido la llamada en 9 subllamadas a las diferentes sincronizaciones.
  • Habrá que completar el código asociado a cada subllamada para sincronizar datos. Cada llamada:
  • (a) Generará el SQL (FQL, #85) correspondiente para obtener los datos necesarios de Facebook. Es muy importante que se traigan solamente los que se necesitan para evitar sobrecargas de datos en las conexiones. Esto es, evitar siempre que sea posible el * que se usaba en los SELECT de SQL. La información a recuperar será exactamente la misma que se guardará en las bases de datos del servidor y que se corresponderá con la mencionada en la documentación sobre el trust proporcionada.
  • (b) La llamada al endpoint de Facebook se crea de forma asíncrona por el propio SDK y contiene un callback que se llamará en el momento en que se consiga la respuesta (onCompleted). En este fragmento se tomará el JSON de la respuesta (por supuesto, previa comprobación de los datos).
  • (c) Para facilitar el tratamiento de las respuestas se ha creado la clase com.ssii.clases.ParserRespuestasFacebook. Aquí se definirán todas las funciones auxiliares (estáticas) como la que hay de ejemplo que recibirán los JSONObject recuperados de las respuestas y devolverán un String con la cadena exacta que se enviará al servidor en el campo datos. Cada función de sincronización tendrá su propia función de parse en ParserRespuestasFacebook.
  • (d) Con los datos de la respuesta ya generados, se establecerá una conexión con el servidor de forma asíncrona y transparente para actualizar la información.
  • Ejemplo: ahora mismo he completado gran parte de la llamada ConectorFacebook.sincronizarAmigos para que sirva de guía para comprender todo lo que he mencionado en los puntos anteriores y he generado el esqueleto de la función ParserRespuestasFacebook.parseRespuestaAmigos. También he creado la clase de conexión que se usará en todas las sincronizaciones de datos (ConectorFacebook.ConexionSincronizacionDatos).
  • Referencia, issues a completar: #96 #97 #98 #99 #100 #101 #102 #103 #104
  • La actualización de los datos se hará (1) tras un login (ya he incluído esta llamada) y (2) una vez al día (esta parte queda pendiente por el momento por ser más secundaria).

[GReaper]

Actualizo - IMPORTANTE He finalizado el Servlet de actualización de datos y ya puedo decir cómo se envían los datos. Lo que voy a explicar corresponde al punto 2 del comienzo de la issue, donde se pone que falta por determinar cómo se enviará el parámetro tipo y datos.

I.- Parámetro tipo Este parámetro es muy simple. Sus valores serán Strings e indicarán la operación de actualización actual. Los valores aceptados son:

• "amigos"
• "comentarios"
• "etiquetas"
• "fotos"
• "likes"
• "mensajes"
• "paginas"
• "postsdirigidos"
• "postsnodirigidos"

Ejemplo: conexion.agregarParametro("tipo", "etiquetas");

II.- Parámetro datos Este parámetro será un String. Concretamente, será el JSON que se haya generado al procesar los datos de Facebook pasado a String (no será el mismo JSON que el recibido de Facebook). Por supuesto, cada tipo de conexión sincronizará unos datos concretos y tendrá su propio formato interno de JSON a enviar. Ejemplo para fijar el campo datos: conexion.agregarParametro("datos", stringDatos);

Ahora bien, ¿Cómo se forma ese campo de datos? Todos los JSON generados tendrán un campo único y común denominado listadatos, que será una lista de JSOn que contendrá toda la información a sincronizar - una lista de elementos -. Esto es, por ejemplo:

{ listadatos : [ ] }

Lo que cambiará en cada conexión es el contenido de esta lista. Para poner un formato común se hará lo siguiente:

• Cada JSON que actualice un tipo de datos contendrá solamente los datos necesarios (que son los mismos que están en el documento de especificación de las tablas de Gonzalo y Lara)
• Cada campo se llamará exactamente igual que el correspondiente campo de las tablas mencionadas en minúsculas (muy importante)
• Todos los campos serán de tipo String a pesar de los tipos que haya declarados en las tablas de MySQL
• Las fechas (datetime en los docs. del trust) se enviarán en formato timestamp de UNIX como un entero, no como String (es el único campo que no irá como String)
• Prestar especial atención a los campos enumerados (commentdata.commenttype y likedata.liketype). El servidor admitirá todos los Strings pasados, pero, para que todo funcione, los únicos valores permitidos son los mencionados en los documentos del trust. Es decir:
  • commentdata.commenttype : "photo" o "post"
  • likedata.liketype : "photo", "post", "page" o "comment"

Por último, por sencillez, los JSON se generarán usando objetos JSONObject, JSONArray y demás elementos de la librería org.json al igual que se hace al tomar las respuestas de servidor.

Para poner todo esto en conjunto, este sería un ejemplo de JSON inventado para sincronizar mensajes - por ejemplo -:

{ "listadatos" : 
    [ 
        { "id" : "abc" , "createdtime" : 12234 , "fromid" : "daf" , "toid" : "okams"},
        { "id" : "rtw" , "createdtime" : 12764 , "fromid" : "okf" , "toid" : "mfdoas"},
        { "id" : "sdfg6" , "createdtime" : 12454 , "fromid" : "adsf" , "toid" : "rtye"}
    ]
}

Como se puede ver, hay una lista general llamada "listadatos" que tiene una serie de JSON que son los recuperados de Facebook (corresponderían a cada conjunto de datos recuperado de FQL). Cada uno de estos grupos tiene la información de ese tipo de datos.

Otro ejemplo, esta vez para sincronizar amigos:

{ "listadatos" : 
    [ 
        { "userid" : "abc" , "friendid" : "def"},
        { "userid" : "abc" , "friendid" : "ghi"},
        { "userid" : "abc" , "friendid" : "jkl"}
    ]
}

Estos JSON son los que se generarán a partir de la respuesta de Facebook en la clase ParserRespuestasFacebook.

[GReaper]

Actualizo Podéis usar el código completado en #104 como modelo. Tened cuidado y no copiéis todo porque habrá cosas que cambien como los enumerados, fechas, etc.

[GReaper]

Todos los puntos finalizados, cierro issue