Programar para programadores: Desarrollando una librería Android
Si quieres escribir una librería o ya estás trabajando en una, estos consejos te orientarán sobre algunas prácticas recomendadas para lograr un software de calidad.
Cuando hablamos de desarrollo Android, es habitual pensar que el producto resultante del código que producimos es una aplicación. En general entendemos que el público receptor de nuestro trabajo son los usuarios finales: Personas con nuestra app instalada en sus dispositivos (celulares, tablets, TVs, automóviles, etc).
Y esa es una posibilidad, pero no es la única.
En medio de nuestro proceso de desarrollo, puede que identifiquemos que una solución que encontramos puede servirle a alguien más porque resuelve un problema común, simplifica algún tipo de tarea, encapsula alguna funcionalidad reutilizable, etc. Entonces se nos abren nuevas posibilidades: el código que escribimos ya no solamente está listo para ser instalado en un dispositivo, sino que puede ser de utilidad para muchos otros desarrolladores. ¡Es el momento de crear una librería!
A continuación enumero algunos consejos que pueden resultarte de utilidad.
Piensa como desarrollador
Claro que es lo que haces siempre, pero ahora que estás desarrollando tu librería, ponte en el lugar del programador que va a utilizarla. Algunos puntos que tienes que tener en cuenta son:
- Facilidad de instalación y simple (o nula) inicialización: Mientras menos pasos de configuración obligatorios tenga tu librería para comenzar a ser utilizada, mucho mejor. Si bien es importante que tenga cierto nivel de personalización, no olvides ofrecer configuraciones por default.
- Coherencia en el código: Respeta ciertos principios para no confundir a tu usuario. Intenta que operaciones similares, se realicen de la misma forma. Por ejemplo, para instanciar objetos, el patrón de diseño Builder suele ser una buena opción ya que el código se expresa con claridad y da la flexibilidad de crear objetos complejos especificando todos o sólo algunos parámetros.
- Quita limitaciones: La incorporación de tu librería a un proyecto debe facilitarle la vida a tus usuarios, no complicarla. Por ejemplo, no hagas excesivo uso de características limitantes de la POO: Prioriza la composición por sobre la herencia ya que esta última suele ser restrictiva en ciertos lenguajes.
Por otro lado, tu implementación no debe limitar el modo en que los desarrolladores escriben unit tests. Por ejemplo, evita que tu API exponga clases con referencias estáticas ya que dificultan el modo de ser provistos en forma de mocks. - Haz uso del Log: Otorga visibilidad de las operaciones que tu librería está efectuando. Utiliza los niveles de Log correctos. Es importante que los desarrolladores puedan hacer seguimiento de qué está ocurriendo e incluso qué está fallando. Haz uso de Exceptions con mensajes claros si alguna precondición de tu código no se está cumpliendo durante su uso.
- Evita colisiones: Asegúrate de que el código de tu librería no interfiera con el de la aplicación que la use. Por ejemplo, tus resources (layouts, strings, drawables, etc) podrían ser nombrados con un prefijo para que sean claramente identificables si necesitan ser sobreescritos y además, para que no ocurran conflictos de nombres.
Distribuye actualizaciones ágilmente
Las librerías en Android resultan ser archivos .aar que pueden ser instaladas descargando el archivo e incluyéndolo manualmente en el proyecto aunque ésta no es la opción más conveniente ya que cada vez que quieras ofrecer una actualización dependerás de esta acción manual. Por eso es aconsejable que hagas uso de un repositorio de artefactos para que tu librería pueda ser descargada como una dependencia de Gradle. Algunos de los más populares son Github Package, JitPack, Nexus o JFrog.
Si distribuyes tu librería de esta forma, puedes aprovechar el chequeo de actualizaciones automático de Android Studio que notificará a tus usuarios sobre nuevas versiones. Además, puedes proveer dependencias transitivas que se descargarán automáticamente, manteniendo tu librería liviana.
Piensa en la retrocompatibilidad
Puede que tengas la necesidad de cambiar la firma de una función, el nombre de una clase, o borrar código después de un refactor. Ten en cuenta que estarás afectando la compatibilidad de aquellas aplicaciones que ya han adoptado tu librería. Por lo cual, por ejemplo, si identificas código que puede ser removido, sería una buena práctica que primero lo marques como Deprecated. Puedes mantenerlo durante algunas versiones más para darle tiempo a tus usuarios de que se adapten a la nueva API y asegurarte de que esto no sea un limitante para adoptar nuevas versiones.
Además es una buena práctica que la notación que utilices para definir versiones se condiga con los cambios introducidos. La notación más común consta de tres partes: Major, minor y build. Por ejemplo: 1.0.2. Si eres coherente en tu versionado, tus usuarios podrán obtener una primera impresión de los tipos de cambios que diferencian una versión de otra.
Proporciona documentación
Es importante que tu librería esté acompañada de instrucciones de configuración, algún ejemplo de uso básico y detalles de personalización para sacarle el máximo provecho. Si posee componentes gráficos las capturas de pantalla y los GIF suman mucho valor.
- Mantén un archivo README.md actualizado. Es el punto de entrada a tu librería y puede ser decisivo para su adopción o no.
- No olvides llevar un registro de Changelog que detalle correctamente las nuevas funcionalidades incluidas, los bugs solucionados e incluso los breaking changes. El conjunto de toda esta información es comúnmente conocido como release notes.
- Añade Javadoc a tus clases para facilitar su consulta durante el proceso de desarrollo.
Además, para demostrar los posibles usos y el poder de tu librería, te recomiendo que la acompañes de un proyecto sample que pueda servir a otros programadores como punto de partida para hacer pruebas rápidas y asegurarse de que cumple con las necesidades del negocio.
Pon atención en la seguridad
Aunque la interfaz de tu librería debe ser clara para su uso, sabe separar aquello que quieres encapsular. Utiliza correctamente los modificadores de acceso de las funciones para prevenir el mal uso. Incluso, puedes utilizar Proguard para ofuscar el código que no debe ser visible para los programadores que utilizarán tu librería.
Un consejo más es que en la medida de lo posible ofrezcas algún medio por el cual tus usuarios puedan colaborar dándote feedback. Sin duda te ayudarán a mejorar proporcionando ideas y reportando bugs. Como en todo desarrollo de software, entiende que es un proceso y será cambiante. Ofrece soporte y manténla actualizada.
Ya estás listo para escribir tu librería. ¡La comunidad de desarrolladores seguramente te lo agradecerá!
