¡Hola!

Hoy voy a hablar de la arquitectura que suelo seguir en mis apps. Para empezar, unas cuantas normas básicas que siempre sigo:

  • Estoy hablando de apps cliente de una api REST (o similar). Esto no sirve para juegos ni para según que cosas.
  • Todos los datos van a ser persistidos. ¡Si respetas a tu usuario, persiste los datos!
  • La base de datos local no es una base de datos per se, es una caché. La base de datos de verdad está en el servidor, y nosotros sólo tenemos una parte de ella. Tengamos esto siempre en cuenta.
  • Me permito ignorar algunas veces las formas normales en pro de la simplicidad y el rendimiento. Total, sólo soy una caché, la base de datos buena y con datos normalizados está en servidor.
  • Las pantallas de splash en apps de Android son el demonio
  • La guía de estilo es sagrada. Sólo se puede romper para innovar y mejorar. Todavía no he conocido a nadie capaz de hacerlo. Hacerlo diferente no es innovar. Hacerlo como en iPhone no es innovar.
  • Mis reglas son mías y me las salto cuando quiero

Arquitectura general por capas

Durante un par de años trabajé con Code Igniter, un excelente Framework MVC sobre PHP (sí, tengo un pasado como programador de PHP, era joven, necesitaba el dinero). Y yo lo siento, pero por más que miro, no creo que Android sea MVC. Esto es discutir el sexo de los ángeles, hay gente que está de acuerdo conmigo, y gente que no, así que vamos a partir de la idea de que nuestra arquitectura NO se va a basar en MVC.

En cuanto a capas hablamos, yo divido la aplicación en Frontend y Backend, o como les suelo llamar, ui y sdk.

De hecho, en grandes proyectos suelo montar el sdk en un proyecto librería y la ui en un proyecto principal. Esto ayuda mucho a separar estas dos capas y a distribuir el trabajo.

En la capa ui tengo todo aquello encargado de gestionar la interfaz: activities, fragments, views, adapters, etc. Todo ello objetos consumidores de datos. Cae alguna cosilla más que a veces tiene que estar aquí por la idiosincracia de Android aunque no sean ui tal cual, como el objeto Application, Notifications, el Push, etc.

Por otro lado, en la capa de sdk (que tiene la chicha) tengo lo que gestiona los datos: beans, clientes, ContentProviders y tareas (y algunas cosillas más del tipo helpers).

La capa UI

De esta hablaremos otro día a fondo con ejemplos, de momento ahí van algunas generalidades y normas que uso.

Todos los elementos de esta capa los incluyo dentro del paquete ui. Así tendremos ui.activity, ui.fragment, ui.adapter, ui.view, etc.

Todas las clases tienen como sufijo lo que son, por ejemplo MainActivity, ForlayosAdapter, etc.

Cada elemento tiene un conjunto de constantes públicas, finales y estáticas que empiezan por EXTRA con los nombres de los parámetros que pueden ir en el bundle del intent de llamada.

Los Intents entre activities y fragments no se mandan objetos enteros (y mucho menos arrays). Sólo se mandan el id del objeto. Así por ejemplo, si tengo una actividad (o fragment, ahora da igual) ProductListActivity con una lista de productos, al seleccionar uno invoco a la siguiente actividad ProductActivity sólo le paso el id, y esta segunda invoca al content provider para que le retorne el registro y lo lee. Si además los datos pueden cambiar durante su visualización por elementos externos, utilizo un loader para mostrar el detalle.

Los adapters SIEMPRE con ViewHolder.

La capa SDK

Esta capa es la que se encarga de la entrada y salida de datos hacia el servidor y de la persistencia de la misma. Aquí u gráfico con los elementos principales:

android architecture

Repasemos los paquetes que suelo crear y que hay en cada uno:

  • bean: pues aquí van todos los objetos de datos. ¿qué tu le llamas DTO, domain o algo así? pues bién, no me pelearé por eso, pero lo que no hago son distinciones. Cada vez intento que sean los más POJO posibles y no les hago ni getters ni setters, vamos, que son estructuras tontitas con anotaciones para la deserializacíon JSON.
  • client: aquí todos los clientes. Son las representaciones del los servicios web. Por ejemplo, una clase LoginClient invoca al servicio de login, gestiona la respuesta y nos la devuelve procesada. Uso una estructura de IntentService tonto que invoca al servicio web que el client le pasa como parámetros. Ya hablaremos de esto en otro artículo. La gracia del sistema es que haces los client como churros. Aquí se produce la serialización/deserialización a JSON (o lo que toque).
  • model: aquí todo el modelo de datos, en la raíz coloco el contrato de datos, el conjunto de constantes que definen tablas, campos y entidades del content provider. En algunos casos cuando las aplicaciones son muy grandes, separo el contrato de base de datos y el de content provider, pero ojo que entonces el mantenimiento es farragoso y complicado.
  • model.content: los content provider, siguiendo la estructura del artículo anterior con DespicableContentProvider y MinionContentProvider
  • model.cursor: aqui tengo un CursorHelper por entidad. Básicamente se encargan de pasar de registro del cursor a objeto y viceversa
  • model.db: el DatabaseHelper y similares.
  • service: aquí va el IntentService que invocan los clientes, así como cualquier otro servicio que pueda necesitar.
  • task: son procesos atómicos que invocan clientes y ContentProviders. Por ejemplo, la típica tarea de UpdateProductsTask invoca a GetProductsClient, hace un delete sobre el Content Provider de productos y luego un bulk insert. Este proceso tiene una salida indicando si ha ido bien o mal.

El meollo de esto está también en mi librería de acceso a servicios web llamada Rarest. Teneis info en www.rarestandroid.com.

Ale, el próximo día veremos un lindo ejemplo con todo esto.

 

2 Responses to En busca de la arquitectura de Android perfecta II: arquitectura general de una app

  1. Raúl says:

    Bon Any Sergi,

    Igual que el anterior articulo me ha parecido muy interesante, ya que todos los conceptos y conocimientos que he adquirido no hace mucho ahora los necesito saber como organizar para que luego no me salga un pupurri que ni su creador (usease yo) sepa por donde leerlo.
    Me ha parecido apropiada la separación en dos proyectos el tema de la ui respecto la sdk, no solo porque es más fácil a la hora de desarrollo en equipo, sino que también con lo que va evolucionando el sistema android y los estilos o temas a veces de una versión a otra de android, sería más cómodo de mantener e ir migrando la ui sin tener por medio “la chicha” de la sdk.

    En cuanto a la forma de organizar los packages de la sdk, desde mi punto de vista más como programador j2ee y noob en el mundillo en android (de momento o eso espero, jeje) te digo que si me encuentro un proyecto con esta estructura me sería más fácil seguir el código, y poder añadir cosas nuevas sin la necesidad de navegar dentro de líneas de código que en teoría ya funcionan y no son necesarias tocar.
    El problema que he visto en muchos tutoriales y demás info de la red es que como esto es Java y se lo traga todo, siempre que lo declares, pues a la todo junto en el package principal y para delante.

    Yo personalmente seguiré de cerca estás recomendaciones, para no coger malos vicios y poco a poco terminar creándome una arquitectura con la cual pueda desarrollar digamos un esqueleto que me pueda servir para montar los proyectos de una manera más rápida e intuitiva, por supuesto hablo de proyectos que compartan la misma forma o funcionalidad (tipo clientes api).

    Un saludo.

  2. David says:

    Muy buen y útil resumen Sergi ;) La verdad que es complicado resumir tanto en tan poco, y cada tema que tocas daría para muchos mas posts, sin embargo se agradece que expliques algunos de los principales topics.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">