Adaptar la API del server para que se pueda obtener a partir del id la siguiente información de un usuario:

• Nombre y apellido
• Mail
• Fecha de nacimiento
• Resumen
• Ciudad
• Experiencia laboral
• Skills
• Foto de perfil

Client:

• permite iniciar una búsqueda de profesionales, según los filtros preestablecidos,
• listar los resultados;
• obtiene las categorías
• permitir su ordenamiento según popularidad

Sistema de notificaciones para advertir de la recepción de un nuevo mensaje o una nueva solicitud.
En lo posible asegurar que al presionar la notificación se accede al área apropiada dentro de la app.

Permitirle al usuario obtener autocompletar ciertos datos mediante la información que ya se encuentra en su cuenta de Facebook.

Datos posibles:
nombre, apellido, ciudad, email, fecha de nacimiento

• posee una sección de mensajería, con una lista de las conversaciones ya iniciadas (opcional)
• permite iniciar nuevas
• posee una pantalla de conversación, para enviar y recibir mensajes

Cualquier cambio en la db la rompe, hay que testear bien.

• Búsqueda de usuarios básica (nombre, apellido, mail)
• Búsqueda de usuarios avanzada mediante filtros de skill, posición de trabajo, y distancia
• Métodos de ordenamiento del listado de usuarios por popularidad tanto en skill como posición
• Especificar en la API
• Testing

La aplicación es capaz de mostrar una lista de profesionales.

En buen camino.

Si estoy en una pantalla, al apretar la misma en el menu, no debería pasar nada. Ahora lo que pasa es que se apilan activities iguales.

Propios y ajenos.

El servidor debe ser capaz de recibir una petición de creación de un usuario con un determinado nombre, y recibirá el id de ese usuario como respuesta. También debe ser capaz de recuperar dicho nombre utilizando el id mencionado. Esto a través de una interfaz REST. Para tal fin, se utilizará Mongoose.

Incluir tests en Python para validar la funcionalidad mencionada.

Detallar la espeficación de la API implementada

Seguir los estándares utilizados para la creación de la API del Shared Server y generar la documentación pertinente: http://rebilly.github.io/ReDoc/

En un patrón que no pude identificar, el primer request por un usuario devolverá algo extraño, no parseable por JSON.

Al repetir el request, devuelve lo esperado.

Actualización de ¿las coordenadas geográficas? y ¿la ciudad? a partir del GPS incluido en cualquier celular Android, al tocar el botón correspondiente en el perfil.

Tras haber investigado la herramienta, se propone proseguir con la configuración del entorno.

Revisar

Usuario A abre conversación con usuario B.
Usuario A recibe mensajes con la conversación abierta.
Usuario A va a la lista de conversaciones, ve que tiene mensajes sin abrir con B.

Al recibir un pedido de creación de usuario en base a un nombre, el servidor debe ser capaz de persistir dicha información y de devolver un identificador unívoco numérico. De esta forma, debe ser posible recuperar el nombre almacenado utilizando el identificador de usuario. Para esto, se deben implementar los mecanismos necesarios para almacenar y recuperar dicha información utilizando Leveldb.

Agregar tests unitarios para validar un correcto funcionamiento.

Los cambios visuales marcados por el profesor.

Se propone una primera instancia de investigación de la herramienta.

Permite

• recomendar a alguien, así como des-rescomendarlo
• ordenar a los usuarios por su popularidad == cantidad de recomendaciones
• consultar (listar) a los usuarios más populares del sistema
• permitir ver la lista de "recomendadores" (opcional)

Este número de recomendaciones debe devolverse en búsquedas ( #33 ) y otros listados para poder ordenarlos o simplemente mostrarlo.

• Especificar en la API
• Testing

Faltarían:

• Cargar la foto: aunque la URL todavía no se incluye en el GET, ya puedo dejarlo listo para cuando esté.
• Confirmar funcionamiento de tarjetas de contactos, cuyo testeo postergaré hasta #17 (se devuelva la lista de contactos). De esto surge un tema a resolver relacionado.

Información de los contactos

(cc @PaulaSaffioti @milenaf30 ) Hay que decidir de qué manera se consiguen los contactos de un usuario y con qué información. El cliente necesitará los datos principales para estas "cards" de contactos: nombre, foto, puesto. Opciones:

1. Se recibe un array de user IDs y se GETtean cada uno. Es lo más sencillo pero entonces el cliente tendrá que hacer un GET por cada ID para obtener esta poca información extra.
2. No se recibe información de contactos (tal vez la cantidad) y existe un GET especial de /contactos/[usuario] tal que se devuelva un array con los datos especiales ya mencionados.
3. Se recibe un array de contactos con esta información reducida de cada uno, en el GET de un usuario cualquiera. Esta es la solución que requiere menos GET, al costo de un response más extenso.

Mi voto está por 2 o 3, la diferencia siendo poca de mi lado.
[Pregunten si no se entendió algo.]

REPETIDO

• Servicio de mensajería entre usuarios activos consolidado con GCM
• Servicio de mensajería entre usuarios inactivos
• Almacenamiento de las conversaciones
• Especificar en la API
• Testing

La app debería poder mediar con una API y obtener información utilizable.

Configurar Docker para utilizarlo en el ApplicationServer

Modificación del perfil propio, incluyendo listados de work_history y skills, y la foto.

Resolver:

• Cómo subir una foto.

AppServer: Generar y guardar; recibir y revisar
Client: Recibir y guardar; enviar con cada request pertinente

Discutir posibilidades entre

• Pedir usuario y contraseña cada vez
• UyC se cargan en los input pero el usuario debe iniciar sesión nuevamente
• Tokens vencen pero con UyC guardados se pide uno nuevo automáticamente
• Tokens que no vencen (o de muy larga duración) y solo se pierden cuando se cierra sesión (con un request DELETE token?)

Votaría entre las últimas 2 posibilidades ya que son las que mantienen al usuario "conectado".
@martinvol @PaulaSaffioti @milenaf30

• Especificar en la API
• Testing

Se permite agregar a un profesional como contacto, así como aceptar o rechazar una solicitud.

Dependiente de: Que establezcamos la API para enviar solicitudes de contacto.

Solicitudes pendientes

Hay que decidir también cómo determinar si hay solicitudes pendientes. Si no entendí mal, se resolvería con que la lista de contactos propia contenga a aquellos con el estado received.

Client-side:

• Pantalla de solicitudes
• Botón de solicitud la envía