Programar para programadores: Desarrollando una librería Android (II)
En mi anterior artículo compartí algunos consejos que pueden resultar útiles cuando se está trabajando en el desarrollo de una librería Android. Aquí pretendo agregar algunos detalles más a ser tenidos en cuenta.
En la línea del desarrollo de librerías en Android y más allá de los detalles técnicos que puedan surgir, hay algunos detalles que no tenemos que perder de vista: el foco está puesto en que nuestra librería resulte ser un producto de calidad. Entre las características que queremos que tenga, podemos mencionar que sea mantenible, seguro, testeable, bien documentado, útil y que su adopción no afecte negativamente el desarrollo del producto por parte de quien la esté actualizando.
Si los consejos de mi anterior artículo te parecieron de utilidad, quiero decirte que ¡hay más! por lo cual, veamos en qué otros puntos podemos poner nuestra atención.
Modularización
Una limitación conocida de Android es que se presenta en relación a la cantidad de métodos que pueden ser contenidos en un único DEX (64.000 aprox). Desde ya que una solución es habilitar multidex. Pero en este punto sería razonable preguntarnos si es correcto que nuestra librería contenga una cantidad de métodos dada y si esto puede afectar negativamente a quién la use.
Dada esta situación y en caso de que no se pueda reducir demasiado, se puede evaluar la posibilidad de separar nuestra librería en módulos independientes y reutilizables que puedan ser incluidos como dependencias separadas según necesidad.
Un claro ejemplo que tenemos de esta situación es la acción que realizó Google con la antigua librería de Play Services la cual actualmente está dividida en distintas dependencias (Maps, Cast, Fit, etc).
Proguard
Si bien la ofuscación de código es una operación prácticamente obligatoria en lo que respecta a la seguridad de nuestro producto, puede resultar una dificultad a la hora de hacer seguimiento de la ejecución del código de nuestra librería por parte de quien la esté utilizando.
Una medida que podemos tomar para evitar este problema es, en lugar de aplicar Proguard directamente en la librería, ofrecer detalles en la documentación de cuáles son las reglas específicas que se deben incluir para securizar su uso. Esta especificación debe ser un snippet del código que debe ser incluido en el archivo de configuración de Proguard y un buen lugar para colocarlo es en el archivo README.md o en la documentación específica de uso.
Tips para tu README.md
- Especifica detalles de compatibilidad, especialmente la versión de Java y el minSdkVersion ya que la versión de la API de Android puede ser un punto decisivo para la adopción de la librería.
- Haz un buen uso de markdowns. Separa distintas secciones y aplica formato a los bloques de código fuente que proporciones como ejemplo.
- Puedes agregar algunos badges como el enlace al repositorio de artefactos que especifique cuál es la versión actual de tu librería, el estado del último build en el servidor de integración continua o el porcentaje de cobertura de tests. En general puedes encontrar el markdown para incluir un badge en la documentación del producto que estés usando (Maven badges, Travis CI, etc).
Modo debug
En mi anterior artículo mencioné la importancia de dar visibilidad a nuestros usuarios sobre las operaciones que nuestra librería ejecuta e indiqué que una buena forma de hacer esto es haciendo uso de la impresión de mensajes en consola a través del Log.
Sería mejor aún si nuestra librería puede configurarse para habilitarlos o deshabilitarlos bajo ciertas condiciones. Por ejemplo, deshabilitar esos mensajes es una práctica recomendada cuando se realiza un build de release ya que no es deseable que estos mensajes puedan ser visibles por cualquier usuario que tenga instalada la versión productiva en su dispositivo.
Teniendo en cuenta esto, un consejo que puedo darte es ofrecer la opción de inicializar la librería especificando si se la utilizará en Modo debug. De ser así, la aplicación imprimirá los logs normalmente. En caso contrario, no.
A modo implementación, lo más sencillo es introducir un wrapper para logs que decida si debe efectivamente imprimir el mensaje en consola o no, o bien utilizar una librería configurable como Timber.
Desde mi punto de vista, la clave se encuentra en entender que cuando desarrollamos una librería debemos tener una visión global del producto que estamos desarrollando: No sólo queremos que resuelva un problema, también queremos que la experiencia de uso sea óptima antes, durante y después de su adopción. Si perseguimos este objetivo, seguramente daremos pasos acertados.
Espero que mis consejos te resulten útiles para poder tomar las decisiones adecuadas que apliquen a tu proyecto.
