Librerías en Android

Cuando desarrollamos software, disfrutamos de una cantidad enorme de recursos disponibles para facilitarnos las tareas de desarrollo. Gracias a estos recursos evitamos la reimplementación de ciertos elementos, utilizando, por tanto, una de las máximas en desarrollo de software: la reutilización de código. Esto es lo que se conoce como librerías.

Las librerías en Android

Históricamente, las librerías se han utilizado en la mayor parte de lenguajes modernos, por poner un ejemplo:

• C / C++: ficheros con extensión .a, .so, dll (dependiendo de si se trataba de librerías de uso estático – cargadas en tiempo de compilación – o dinámico – cargadas en tiempo de ejecución -).
• C# / resto de lenguajes del .Net Framework: ficheros con extensión .dll
• Java: ficheros con extensión .jar, aunque en Java, todo son ficheros jar, incluidos los “ejecutables”.

En las librerías Android, que es el caso que nos compete (y en el que nos vamos a centrar a partir de ahora), hasta hace unos años el código se desarrollaba en Java, por lo que podríamos pensar que la distribución de código reutilizable en librerías se realiza en ficheros .jar (podrían utilizarse, sí). Pero, a diferencia de los desarrollos en Java para desktop, o incluso servicios web, para Android se utilizan ficheros con extensión .aar, los cuales nos dan unas funcionalidades similares a las que un fichero jar proporciona.

Tipos de distribución de librerías en Android

A la hora de distribuir librerías para Android, tenemos dos posibilidades que van a afectar notablemente en el sistema de distribución y actualización de nuestras librerías:

• Distribución local del fichero aar (o incluso jar). Esta opción tiene como ventaja que, si es una librería muy específica (por ejemplo, proporcionada por un fabricante) o incluso descatalogada, no correremos el riesgo de que se elimine de repositorios online.
• Distribución de la librería (aar) a través de un sistema de repositorio remoto de librerías basado en maven. En el mundo Android esta es la opción más común, disponiendo además de varios servicios que nos ofrecen repositorios basados en maven:
  • MavenCentral. uno de los principales proveedores de librerías para el mundo Android, tanto público como privativo, con su sistema nexus (https://www.sonatype.com/products/sonatype-nexus-repository).
  • Maven Google. En este repositorio se almacenan los distintos recursos de desarrollo publicados por Google (más info sobre cómo integrarlo: https://cloud.google.com/artifact-registry/docs?hl=es)
  • Jcenter. Descatalogado, sólo debe utilizarse en desarrollos Android con librerías que se hayan quedado sin soporte y necesitemos descargarlas desde este repo, es incluso recomendable descargar manualmente el aar e integrarlo de forma local, obviando el uso de jcenter.
  • Servidor local maven, esta opción implica que somos nosotros los que montamos / mantenemos / securizamos el servidor de maven.

En párrafos anteriores, hemos hablado de la posibilidad de distribuir nuestro código utilizando ficheros jar, o bien ficheros aar. Como comentamos, Android soporta ambos sistemas de empaquetado, aunque se recomienda utilizar el específico aar ya que, entre otras “ventajas”, nos ofrece acceso a diversas apis del sistema operativo. Por ejemplo, por indicar uno muy evidente, la gestión de permisos.

Imaginemos un ejemplo en el que desarrollamos una librería de componentes en la cual, entre otras funcionalidades, creamos un elemento visual que dispone de un campo de texto y un botón para acceder a un mapa. En este caso, en el preciso instante en el que pulsemos el botón, accederíamos a comprobar los permisos de ubicación y, en caso de no disponer de ellos, solicitarlos.

Conclusión

Existen multitud de tutoriales en los que, paso a paso, se nos muestra cómo crear una librería en Android Studio, y publicarla en un servicio maven (concretamente en MavenCentral).

Gracias a la creación de librerías propias podemos, aparte de contribuir a la comunidad de desarrollo, automatizar, generalizar y eliminar código innecesario de nuestros proyectos (para qué copiar un componente creado, cuando podemos disponer de una base única de código que nos permitirá una mayor agilidad al agregar nueva funcionalidad, o más importante quizá, resolver bugs).

Desde hiberus, recomendamos y fomentamos la creación de librerías de componentes y/o utilidades, ya que de un modo u otro se fomenta la creación de código más conciso, a la par que optimizamos la posible detección de errores y posibles ampliaciones de funcionalidad.

En hiberus contamos con un departamento de profesionales dedicado al desarrollo de aplicaciones móviles. Ofrecemos soluciones a medida para todo tipo de plataformas: desarrollo Android, desarrollo iOS, aplicaciones híbridas, desarrollo multiplataforma, aplicaciones web, quioscos digitales, desarrollo de sistemas IoT, desarrollos en Alexa/Google… Contáctanos para más información.