Necesario para concretar el login del usuario

Crear sets de datos dentro de la DB del servidor para poder reproducir casos de uso con el cliente.

Configuración del ambiente donde se correrá el Servidor, previendo la instalación de todas las librerías necesarias en el mismo. El ambiente se configurará a partir del uso de la herramienta Docker.

En todos los request desarrollados, enviar una ÚNICA estructura JSON como respuesta. Si no está el usuario, las carpetas, etc. enviar campos nulos o vacíos, pero siempre los mismos. Si el user no existe en el caso de /token, tomamos como convención enviar userId = 0

Primeras nociones de programación y uso de la SDK de Android

• Comprensión de la estructura de directorios y archivos de un proyecto en Android Studio
• Armado de ejemplo breve para entender:
  • Clases Activity, View, Intent
  • Armado de layouts
  • Declaración y referenciación de recursos en XML (strings, dimens)
  • Seteo de theme (styles.xml)

Modelo base del cual se tomará como práctica de uso para el repositorio Git. En nuestro caso se usarán las ramas: master, develop y feature

A successful Git branching model

En la sección Network de nuestro repositorio se puede ver un diagrama de como avanzan las distintas ramas (solo las remotas).

Realizar una clase que implemente el uso básico que se le dará a la librería RocksDB

Se realizará la configuración inicial de test y de code coverage para el Servidor, que luego será disparada por la herramienta travis.

Creación de un archivo CMake para compilación del código C++ relacionado al servidor.-

• Manipulación del token en el cliente (almacenamiento, consulta, envío y eliminación)
• Agregar al header del Request HTTP el token del cliente

Configuración del archivo .travis.yml para que el entorno pueda correr todas las pruebas del servidor, realize el code coverage y pueda enviar los datos a coveralls.io

Vincular el uso de las herramientas Docker Hub con TravisCI y Coveralls.io para automatizar pruebas.

Se aprovechará el entorno de la imagen Docker -la cual se encontrará configurada para el uso del servidor- para correr las pruebas y subir los resultados del code coverage a Coveralls.io dentro del entorno de la herramienta TravisCI.

De esta forma se dejará de depender la configuración del entorno de TravisCI, sus dificultades para la instalación de dependencias, y su incompatibilidad con ciertas librerías, debido a que la herramienta se basa en Ubuntu:12.04.

Como beneficio extra, se obtendrá un tiempo de build mucho mas reducido en TravisCI.

• Desarrollo de la acción lanzada al hacer tap en "sign out": eliminar la cuenta de usuario almacenada en el cliente.

Se implementará el medotos para login/logout del lado del servidor.

Realizar un análisis sobre las herramientas de test Google Test (GTest) para su uso en el proyecto, dentro del servidor.

Testing de métodos POST y PUT mediante un servidor online para pruebas: jsonplaceholder.typicode.com.
Utilización de cURL vía bash y RESTClient (add-on para Firefox)
// Nuevo servidor de pruebas: http://quick-entities.herokuapp.com

Luego de implementada la API REST del lado del servidor, intentaremos una conexión con envío de mensajes reales de nuestra aplicación.

Este servidor estará hosteado en DC y se accederá a través de una ip:port publica.

Diseño de la pantalla de Login de Usuario siguiendo las buenas practicas de diseño para Android.

Crear una clase para manejo de datos en la BD, creando las firmas de sus principales métodos. La misma se encargará de manejar los datos necesarios para la interacción con el cliente. Se basará en los pedidos realizados por la API REST.

Links a los estándares de codificación que vamos a usar para nuestro código fuente del lado del Cliente:

• Google Java Style, incluye:
  1. Introduction
  2. Source file basics
  3. Source file structure
  4. Formatting
  5. Naming
  6. Programming Practices
  7. Javadoc
• Android Code Style Guidelines for Contributors, Incluye:
  1. Language Rules
  2. Library Rules
  3. Style Rules
  4. Javatests Style Rules
• Herramienta de Google para analizar código java: CodePro AnalytiX

Links a los estándares de codificación que vamos a usar para nuestro código fuente del lado del Servidor:

• Google C++ Style Guide, Incluye:
  1. Header Files
  2. Scoping
  3. Classes
  4. Google-Specific Magic
  5. Other C++ Features
  6. Naming
  7. Comments
  8. Formatting
  9. Exceptions to the Rules
• Verificador automatizado para el estilo de codificación de C++ de Google: cpplint

El desarrollo del código fuente será en idioma inglés, tanto para el Servidor como para el Cliente.

Incluir las dependencias necesarias en el proyecto de Android para integrar una herramienta de logging de actividades, mensajes de debug, etc.

Configurar conexiones entrantes dentro del ambiente Docker, para poder correr el servidor y que el mismo obtenga las peticiones del cliente.-

Configuración de librerías y herramientas que serán necesarias para que el código del Servidor pueda ser desarrollado y corrido, con una previo estudio de las necesidades del proyecto. Como resultado se incluirán los archivos necesarios para su funcionamiento, dado un ambiente correctamente configurado.-

• Descarga de SDK KitKat 4.4 (API 19).
• Descarga de plugins SDK sugeridos por sitio oficial Android developers.
• Descarga de imagen KitKat y configuración de AVD.

Objetivo: Hacer que arranque el servidor HTTP y resuelva algo.

Tomar por parámetro la configuración del servidor

• Ventajas, modo de utilización
• Subida (Multipart) y descarga de archivos

Creación del proyecto inicial donde se comenzará a desarrollar el Cliente.

Objetivos:

• Comprender el funcionamiento básico de la API REST
• Entender el uso y cómo estructurar el modelo del servicio de comunicación mediante Retrofit
• Empezar a pensar en el diseño de los servicios reales que deberemos utilizar

Diseño de la pantalla de Listados de documentos/carpetas a las que puede acceder el usuario siguiendo las buenas practicas de diseño para Android.

En nuestro proyecto los Issues serán empleados tanto para cuestiones de codificación como para planeamiento de tareas. Aquí reunimos algunas normas de publicación, aclarando que el contenido del mismo queda a criterio del que lo publica.

Definimos algunos puntos para poder organizarlos:

• Debe tener un título descriptivo, pudiendo desarrollar los detalles en los comentarios del mismo. NO agregamos en el título labels "manuales", del estilo "[Tarea]..." ya que para eso usamos los labels que vienen con los issues.
• Cada issue debe tener al menos un label para que pueda ser clasificado. En caso de ser necesario se pueden crear labels que no existan. Mientras mas clasificados se encuentren los issues, mas efectiva será su ayuda y administración.
• Para el caso de las tareas se debe agregar por defecto el label task y debe asignarse una persona a la misma. Luego se podrá cerrar el issue al momento de concluir la tarea. Se recomienda tener tareas atomizadas para una correcta asignación y para evitar superposiciones con otros integrantes.
• Para el caso de una práctica común para los integrantes del proyecto se agrega el label common practice y no se asigna a nadie en particular. Estos issues quedan siempre abiertos.
• Existen los labels server y client para poder difenenciar tareas, bugs y demás cuestiones que surjan para los subproyectos realcionados al servidor o al cliente.
• Para los demás casos que puedan manifestarse se agregan los labels necesarios, siempre tratando de utilizar el sentido común.

Manejo de iconos y estilos para distintas resoluciones de pantalla

Mart, como no soy el owner del proyecto no lo puedo integrar con Travis. Me haces owner?

Primer tarea del proyecto, donde se creará la estructura de los directorios básica a usar en el repositorio y se aprovechará también para tener un primer contacto con el uso del sistema Git. Se tendrá en cuenta que el mismo será usado para el desarrollo tanto del Servidor como del Cliente.-

• Compilar el proyecto existente y hacer el correcto merging del diseño de la pantalla de login

Vinculación del repositorio de GitHub con la plataforma de Docker, Docker Hub, para la posterior automatización del build.-

• La pantalla de Login no debe tener más funcionalidad que la de ingresar user y password y enviar mediante el botón "Sign in".
• El menú de opciones de la barra de acciones tiene que poder accederse desde la pantalla principal una vez que el usuario ya está autenticado.

Configuración inicial del servicio de web Coveralls, el cual realizará el code coverage del código correspondiente al Servidor. Se vinculará este servicio con el repositorio de GitHub.

Al ejecutar la prueba de RocksDB (un "hola mundo" básico donde se crea una BD se llena con datos y luego se la elimina, en LibraryTest.cpp) en el test dentro del ambiente Travis (Ubuntu 12.04) y Docker (Ubuntu 14.04), se produce un segmentation fault, cuando se realiza lo mismo en una máquina con Ubuntu 14.04 este error no se produce.

Mostrar mensaje de error al usuario en caso de no ser válidas las credenciales ingresadas.

• No incluye temas y estilos
• No incluye llamada a servicio REST para obtener los archivos del usuario