Iniciar un nuevo proyecto es la oportunidad de crear una nueva feature, usar nuevas api, explorar nuevas practicas, pero muchas veces todo esto se ve demorado por la necesidad de incluir configuraciones iniciales, como dependencias, crear arboles de directorios, etc. En el mundo laboral mejorar este escenario es un plus.

Pero que tal si te digo que puedes usar una herramienta que te permite crear un nuevo proyecto a vos y demas equipos con todas esas configuraciones en un instante.

El dia de hoy veremos una tool basada en NodeJs llamada https://plopjs.com/

Plop.js es una herramienta de generación de código que ayuda a los desarrolladores a automatizar tareas repetitivas durante el proceso de desarrollo de software. Permite definir y ejecutar “generadores”, que son pequeños scripts o plantillas que crean archivos y estructuras de directorios de manera programática. Esto es útil para evitar la repetición de configuraciones y patrones comunes en proyectos de software, lo que ahorra tiempo y reduce errores. Plop.js es especialmente útil en entornos de desarrollo web, pero también se puede utilizar en una variedad de otros contextos de desarrollo de software tales como Android como veremos hoy.

Comencemos:

Veamos rapidamente de que se trata pllopjs

1-Instalar NodeJs

Lo primero que debemos hacer es instalar NodeJS, aqui dejo un articulo de como hacerlo https://kinsta.com/es/blog/como-instalar-node-js/

2-Instalar PlopJS

npm install -g plop

3-Crear archivo plop.js

Este es el archivo que sera el generador de template en este se distinguen 2 array prompts y actions.

export default function (plop) {
    // controller generator
    plop.setGenerator('controller', {
        description: 'application controller logic',
        prompts: [{
            type: 'input',
            name: 'name',
            message: 'controller name please'
        }],
        actions: [{
            type: 'add',
            path: 'src/{{name}}.js',
            templateFile: 'plop-templates/controller.hbs'
        }]
    });
};

“prompts” seran los inputs que se le mostraran al usuario.

“actions” son las acciones que se realizaran con los inputs

4- Ejecución

npm run plop

Al ejecutarlo veremos lo siguiente:

Este input responde al contenido de array prompts

{
  type: 'input',
  name: 'name',
  message: 'controller name please'
}

Al ingresar un valor lo mapeara a una variable llamada “name”

Luego ejecutara un action

{
   type: 'add',
   path: 'src/{{name}}.js',
   templateFile: 'plop-templates/controller.hbs'
 }

En este caso utilizara el action “add” https://plopjs.com/documentation/#add

este agregara dentro del path “src/{{name}}.js”

name= sera el valor ingresado en el input previo.

el contenido del template definido en “plop-templates/controller.hbs’”

Ej, si en el input ingresamos el valor “helper” el archivo final se llamara src/helper.js' y el cotenido obtenido de plop-templates/controller.hbs sera procesado y en caso de contar con {{name}}. tambien sera modificado .

DroidTemplateWizard

Arme una pequeña tool basado en lo anterior la cual nos va permitir crear nuevos proyectos usando como base un proyecto de Android Studio.

Repositorio: https://github.com/sebacipolat/DroidTemplateWizard

Este manejara 2 datos: name packageID

El archivo plop sera el siguiente:

const logo = require('./logo.js');


function welcome() {
    console.log(logo);
    console.log("********************************************"); 
    console.log("  Welcome to the Android Module Generator   "); 
    console.log("********************************************"); 
}

// Configuración de Plop
module.exports = function (plop) {
    welcome();
    // controller generator
    plop.setGenerator('controller', {
        description: 'application controller logic',
        prompts: [{
            type: 'input',
            name: 'name',
            message: 'Module name:'
        },
        {
            type: 'input',
            name: 'packageID',
            message: 'Package:'
        }],
        actions: [{
            type: 'addMany',
            destination: 'output/',
            templateFiles: 'template/**/*'
        }]
    });
};

Al ejecutarlo se crearan las siguientes variables las cuales utilizadas en los templates para ser reemplazada por el contenido ingresada en estos.

name= nombre del proyecto {{name}}

package= el package que usaremos tanto para la app y modulo {{packageID}}

En la consolo veremos:

El action a ejecutar sera “addMany” https://plopjs.com/documentation/#addmany

  actions: [{
            type: 'addMany',
            destination: 'output/',
            templateFiles: 'template/**/*'
        }]

Este tomara todos los archivos ubicado en el folder /template y los copiara al path ouput/

A su vez tambien examinara el contenido de todos los archivos del template para reemplazar si existiese el contenido de alguna de las variables ya mensionada.

Template:

Este sera la plantilla que plop utilizara para armar el output, sobre este seran reemplazadas las variables que hayan sido definidas en pasos previos.

En mi caso esta compuesto por una app y un modulo dentro, esto fue pensado para el uso en apps modulares ya que permitiria crear nuevos modulos a todos los equipos usando las mismas configuaciones iniciales.

Se lo encuentra dentro de la carpeta template:

El nombre del proyecto y el modulo sera {{name}}

{{packageID}} sera el package que usaremos

Al ejecutar el action recorrera el template y reemplazara las variables “{{name}},{{packageID}}” por los valores ingresados. Se lo reemplazara tanto en el contenido de los archidos como en su nombre.

Algunos Ejemplos:

*build.gradle

el namespace y appID sera armado usando la variable {{packageID}}

*Agregar el modulo como dependencia

*Package dentro de cada archivo

Como veras es muy simple solo debes reemplazar por una variable el contenido que deseas que se modifique segun un valor ingresador por consola. En este caso fue pensado para Android pero puede ser adaptado para cualquier lenguaje

Demo:

Ejecutamos

npm run plop

Ingresaremos:

Module name: pdf-viewer

Package: com.pdf.sdk

Veremos que luego de ingresar los valores requeridos comenzara a copiar los archivos dentro de la carpeta output

El proyecto resultante sera el siguiente:

De esta forma puedes armar tu propio generador para tus proyectos usando tus templates y ahorrar tiempo.

Agregar nuevos campos es muy facil como se muestra en los ejemplos.

Espero que te sea de utilidad!!

Plop tiene muchas funcionalidades mas de las aqui expuestas, si quieres conocer un poco mas te dejo un par de links.

Plop: Consistency Made Simple

https://www.paradigmadigital.com/dev/plop-js-creando-archivos-con-uniformidad/

Boost your coding productivity with Plop: Tutorial

https://claritydev.net/blog/scaffolding-redux-boilerplate-with-code-generators

Recientemente termine mi primera libreria para Android llamada Wolfguard esta permite realizar RASP (Runtime Application Self-Protection) para proteger nuestra app.

Para poder disponibilizarla a la comunidad debi atravezar el proceso de publicación en MavenCentral, este fue bastante complejo y me tomo casi mas tiempo que la libreria en si. Asi que el dia de hoy te explicare los pasos que realice para poder publicarla, el cual es en parte recopilación de varios post y parte mia.

Omitire todo lo relacioando a creacion de una libreria ya que no es el proposito del post.

Pasos a realizar

1. Registrar el Group ID en MavenCentral creando un ticket de jira
2. Configurar el plugin maven-publish dentro del archivo gradle.
3. Configurar credenciales de publicación y creación de llave para firmar
4. Publicar en ambiente Staging, Release
5. Consumir libreria dese MavenCentral

1-Registrar el Group ID en MavenCentral creando un ticket de jira

El acceso a maven se gestions mediante la creación de un ticket de jira por lo que primero deberas crear credenciales para poder acceder.

Acceder a https://issues.sonatype.org/secure/Signup!default.jspa

Es importante que tengas presente estas credenciales ya que las usaremos mas adente.

Inicia sesión con las credenciales creadas recientemente.

Aqui te dejo la documentación oficial sobre este proceso.https://central.sonatype.org/publish/publish-guide/#deployment

Luego pulsa el boton create para crear un ticket nuevo.

Aqui te dejo de ejemplo el ticket que cree yo para que uses de referencia https://issues.sonatype.org/browse/OSSRH-98284

Debes indicar la url del repositorio en summary.

Campo Groud id :

https://central.sonatype.org/publish/requirements/coordinates/

Este es el package que va identificar a tu libreria.

Aqui es donde empieza a complicarse el proceso ya que el valor a utilizar dependera de si eres dueño del dominio.

Ejemplo:

El package inicial de mi liberia incluia mi apellido com.cipolat.wolfguard pero para poder usarlo debia poseer el dominio cipolat.com (el cual no lo tengo) ya que debia tener que hacer una modificacion en el DNS del hosting . Mas info https://central.sonatype.org/faq/how-to-set-txt-record/

Si cargo el ticket usando ese dominio se me pedira que lo demuestre .

En este caso donde solo tengo el repositorios se me sugiere un group id io.github.sebacipolat este se armo usando la direccion de mi repositorio, por lo que opto por :

io.github.sebacipolat.wolfguard.sdk

una vez definido debemos colocarlo en el campo correspondiente y continuar con los demas, puede que necesites modificar los package dentro de tu codigo para adecuarse.

Una vez creado el ticket tardaran algunos minutos en procesarlo.

Si todo fue correcto veras un mensaje de este tipo

En mi caso se me asigno el ambiente s01.oss.sonatype.org

2-Configurar el plugin maven-publish dentro del archivo gradle.

Para realizar la subida de nuestro aar a maven usaremos el gradle de plugin maven-publish

En mi caso estoy usando la version gradle-8.0 del wraper de gradle-

Vamos a crear dentro de nuestro modulo un archivo llamado publish-package.gradle con el siguiente contenido

apply plugin: 'maven-publish'
apply plugin: 'signing'

task androidJavadoc(type: Javadoc) {
    source = android.sourceSets.main.java.srcDirs
    classpath += project.files(android.getBootClasspath().join(File.pathSeparator))

    exclude '**/R.html', '**/R.*.html', '**/index.html'
    options.encoding 'utf-8'
    options {
        addStringOption 'docencoding', 'utf-8'
        addStringOption 'charset', 'utf-8'
        links 'https://docs.oracle.com/javase/7/docs/api/'
        links 'https://d.android.com/reference'
        links 'https://developer.android.com/reference/androidx/'
    }
}

task androidJavadocJar(type: Jar, dependsOn: androidJavadoc) {
    archiveClassifier.set('javadoc')
    from androidJavadoc.destinationDir
    preserveFileTimestamps = false
    reproducibleFileOrder = true
}

task javaSourcesJar(type: Jar) {
    archiveClassifier.set('sources')
    from android.sourceSets.main.java.srcDirs
    preserveFileTimestamps = false
    reproducibleFileOrder = true
}

afterEvaluate {
    publishing {
        publications {
            release(MavenPublication) {
                from components.release
                groupId 'GROUP_ID'
                version VERSION_NAME
                pom {
                    name = artifactId
                    description = POM_DESCRIPTION
                    url = 'URL repositorio'
                    licenses {
                        license {
                            name = 'name licenca'
                            url = 'url licencia'
                        }
                    }
                    scm {
                        connection = 'scm:url repo en formato ssh' // ej en mi caso git@github.com:sebacipolat/WolfGuard.git
                        url ='https://github.com/sebacipolat/WolfGuard.git'// en mi caso fue 'https://github.com/sebacipolat/WolfGuard.git'
                    }
                    developers {
                        developer {
                            id = POM_DEVELOPER_ID
                            name = POM_DEVELOPER_NAME
                            email = POM_DEVELOPER_EMAIL
                        }
                    }
                }
            }
        }
        repositories {
            maven {
                name = "SonatypeSnapshot"
                url = "https://s01.oss.sonatype.org/content/repositories/snapshots/"

                credentials {
                    username ossrhUsername
                    password ossrhPassword
                }
            }

            maven {
                name = "sonatype"
                def releasesRepoUrl = "https://s01.oss.sonatype.org/service/local/staging/deploy/maven2/"
                def snapshotsRepoUrl = "https://s01.oss.sonatype.org/content/repositories/snapshots/"
                url = version.endsWith('SNAPSHOT') ? snapshotsRepoUrl : releasesRepoUrl
                credentials {
                    username ossrhUsername
                    password ossrhPassword
                }
            }
        }
    }
}

signing {
    sign publishing.publications
}

En el build gradle de tu modulo deberas agregar

apply(from = "../publish-package.gradle")

Luego agregaremos dentro de nuestro gradle.properties los siguientes valores:

#PUBLISHIN MAVEN CENTRAL
VERSION_NAME=#Version de la lib ej 1.0.0
VERSION_CODE=#version code ej 1000
GROUP=group_ID # el mismo que pusimos en el ticket de jira io.github.sebacipolat.wolfguard

POM_DESCRIPTION=#Desciprcion de la libreria
POM_URL=#URL repositorio
POM_SCM_URL=#URL repositorio
POM_SCM_CONNECTION=scm:git@github.com/sebacipolat/WolfGuard.git #reemplazar por el correspondiente en tu caso
POM_SCM_DEV_CONNECTION=#idem anterior
POM_LICENCE_NAME=MIT License #licencia 
POM_LICENCE_URL=https://github.com/GeofriendTech/AndroidUtils/blob/main/LICENSE
POM_LICENCE_DIST=repo
POM_DEVELOPER_ID=#username de jira
POM_DEVELOPER_NAME=#Nombre del developer
POM_DEVELOPER_EMAIL=#email

ossrhUsername=#username de jira
ossrhPassword=#Password de jira

3- Configurar credenciales de publicación y creación de llave para firmar

Crear clave GPG:

Los artefactor que subiremos deberan estar firmados con una clave la cual crearemos de la siguiente forma:

En mi caso lo hice usando Linux ubuntu

 gpg --gen-key

Te solicitara nombre, apellido, email y luego generar un passprhase

Una vez creado deberas ejecutar el siguiente para obtener el ID de la key generada

gpg --list-keys --keyid-format short

La respuesta sera de este tipo

pub   rsa4096/AAAA12345 2024-01-14 [SC]
      FA0BA8858D1CC91A433F38470760324FDF2A3EE5
uid      [  absoluta ] Nombre y apellido <email>
sub   rsa4096/F2ED5C25 2024-01-14 [E]

pon atención a la primera linea pub rsa4096/AAAA12345 2024–01–14 [SC]

en este caso AAAA12345 sera tu ID.

Luego debemos exportar estas key a un file

gpg --export-secret-keys -o secring.gpg 

Luego debemos volver al archivo gradle.properties y agregar lo siguiente:

signing.keyId=#id creado usando gdg en nuestro caso ej:AAAA12345
signing.password=#passprhase
signing.secretKeyRingFile=#path del archivo secring.gpg

ossrhUsername=#jira username
ossrhPassword=#jira password

Debemos enviar nuestra clave pública identificada por “AAAA12345” a dos servidores de claves diferentes. Estos son usados por maven para poder leer nuestro aar

gpg --keyserver hkp://pool.sks-keyservers.net --send-keys AAAA12345 #idclave
gpg --keyserver hkp://keyserver.ubuntu.com --send-keys AAAA12345   #idclave

4- Publicar en ambiente Staging, Release

En maven existen 2 tipos de publicaciones:

Snapshot:

En el contexto de Maven, un “snapshot” se refiere a una versión de desarrollo de un proyecto que está en constante evolución que aún no ha alcanzado un estado de estabilidad para ser liberada como una versión final o estable.

Estas versiones suelen tener el sufijo “-SNAPSHOT” en su número de versión. Por ejemplo, “1.0-SNAPSHOT”.

Release:

Se refiere a una versión estable y final de un proyecto que se considera apta para su uso en entornos de producción.

Generando aar:

Antes de comenzar a publicar primero sugiero generar un .aar y verificar su contenido.

gradle :module-name:assemble

Dentro de la carpeta /outputs/aar del modulo veremos que se generaran 2 archivos

Sugiero utilizar la herramienta http://java-decompiler.github.io/ para poder inspeccionar el contenido dentro, si puedes ver el codigo dentro del jar classes.jar este se empaqueto correctamente.

En caso de que no este revisa la configuración del build.gradle del modulo ya que tal vez debas ajustar tu archivo proguard.

Publicando en Maven:

Una vez que ya sabemos que nuestro aar esta correcto vamos a publicarlo.

Subir Snapshot.

Cambiemos nuestra version del modulo en el gradle.properties a

VERSION_NAME=0.0.1-SNAPSHOT

Luego ejecuta

gradle :module-name:publishReleasePublicationToSonatypeSnapshotRepository

Debes usar la url que se te asigno al momento de crear el ticket.

https://s01.oss.sonatype.org/content/repositories/snapshots/<group_id>

En mi caso: https://s01.oss.sonatype.org/content/repositories/snapshots/io/github/sebacipolat/

Si abres la versión snapshot veras el aar

Subir Relase:

Cambiar versión en gradle.properties:

VERSION_NAME=1.0.0

Ejecuta:

gradle :module-name:publishReleasePublicationToSonatypeRepository

Aqui se pone un poco mas complicado el tema ya que deberas lanzarlo manualmente desde gradle

Accede a al ambiente que se nos asigno al crear el ticket. en mi caso es

https://s01.oss.sonatype.org/#welcome

Inicia sesión usando las credenciales de jira.

En el menu lateral izquierdo deberas ir a “Snapshot Repositories”

Veras algo de este tipo

Debras escogerlo y clickear en “Close”

Esto va iniciar un proceso que tardara algunos minutos en terminar.

Debajo veras un tab “Activity” con el progreso, si no ves avance, recarga la pagina.

Una vez terminado veras algo de este tipo

Tambien te llegara un email con el reporte del analisis de tu libreria.

Una vez llegado a este punto se habilitara la opción “Release” la cual deberas pulsar

Este proceso tomara algunos minutos, pero cuando termine podras verlo publicado aqui.

en mi caso https://repo1.maven.org/maven2/io/github/sebacipolat/wolfguard-sdk/1.0.0/

Tambien si ingresamos a https://central.sonatype.com/

y buscamos por el nombre de nuestra libreria podremos encontrarla.

Ej: https://central.sonatype.com/artifact/io.github.sebacipolat/wolfguard-sdk

Maven Central: io.github.sebacipolat:wolfguard-sdk

Una vez ya publicado cualquiera que obtenga dependencias de mavencentral podra consumirla agregando simplemente

implementation("io.github.sebacipolat:wolfguard-sdk:1.0.2")

Este proceso debe repetirse cada vez que deseas subir una nueva versión

Hasta aqui llegamos el dia de hoy.

Ahora ya no tienes exucsas para no publicar tus propias librerias y compartilas con la comunidad!

Hace algunas semanas Google play introdujo nuevos cambios que aplican a todas las cuentas nuevas para usuarios particulares posteriores al 13 de Noviembre del 2023 que estan complicando a todos los desarrolladores indie.

Estos solicitan que para poder publicar una nueva aplicación deben cumplir con lo siguiente:

• Realizar una etapa de pruebas cerradas durante 14 dias con al menos 20 testers.
• Las pruebas deben ser continuas y nunca disminuir el minimo de testers requeridos ya que de lo contrarion deberan volver a realizar el ciclo de pruebas cuando cumplan con la cantidad necesaria.

La etapa de pruebas cerradas es algo que tiene sentido y es recomendable pero para un dev indie que muchas veces es el solo le resultara demasiado dificl conseguir esa cantidad de gente.

¿Cuales son los motivos por los que Google tomo esta decision?

En su comunicado menciona que es para elevar la calidad de la apps, pero esto suena raro ya que en las cuentas de tipo empresa no lo requieren.

A mi parecer es para poner un tope al tipo de apps que se estaban publicando ya que los devs indie no van a crear aplicaciones tan complejas como la de una empresa con un producto detras, sino muchisimo mas simples con una calidad muchisimo mas inferior.

¿Es el fin de Google Plays?

La realidad que no lo creo, solo va hacer que publicar una app sea mucho mas trabajoso y de seguro va desestimar la creacioón de muchas apps, tal vez gane popularidad algun store alternativo que tenga menos requerimientos, pero al ser Android la plataforma mas popular mundialmente y la mayoria ya traen pre instalado la app del playstore no creo que cambie mucho el panorama.

¿Soy un dev indie y ahora como voy a poder cumplir con todo eso yo solo?

Tranquilos que he atravezado este proceso y podido publicar una app en una cuenta nueva de forma exitosa y les voy a compartir todo lo que necesitan saber.

Subiendo nuestra app a producción

Una vez creada nuestra cuenta y dada de alta nuestra app, preparado la ficha, subir capturas, texto, etc lo primero que veremos al quere subirla a producción sera:

1. Iniciando:

Debemos crear una version de prueba usando el canal prueba cerra o closed testing, esto es algo relativamente muy simple de hacer https://support.google.com/googleplay/android-developer/answer/9845334?hl=en

2. 20 Testers

Aqui es donde empieza lo dificil conseguir 20 testers para que prueben nuestra app de forma continua durante 14 dias, en este punto hay 2 caminos que podemos seguir:

Conseguir 20 personas dispuestas a probar nuestra app diariamente:

En una empresa es algo relativamente simple de hacer con los miembros de los diversos equipos prueben y den feedback.

Para a un dev indie que probablemente sea el solo es muy dificil ya que tiene que salir a buscar gente dispuesta a probar su app de forma voluntaria.
Podria hacerse de varias formas:

• Comunidades: Intentar conseguir gente que lo ayude, hay varias donde mediante discord crearon canales para tal fin.
  Redes sociales: ej reddit:

Esto va ser dificil ya que va depender de la voluntad de otras personas.

https://www.reddit.com/r/AndroidClosedTesting/

• Contratar un servicio:
  El unico que encontre de momento es https://www.20testers.com/
  No lo he probado, pero parece estar pensado para resolver este problema.

Crear 20 cuentas de Google:

Este camino lo he probado con buenos resultados pero no puedo asegurar que te funcione ya que depende de Google pero basicamente debemos crear 20 cuentas de google, este camino es un poco trabajoso ya que cada cuenta debe estar asociado a un numero de telefono y este solo puede tener 4 cuentas asociadas, por lo que se debera conseguir varias lineas para poder crearlas.

Una vez creadas se deben agregar en el canal de prueba interna y mediante el link de invitacion web se puede ir iniciando sesion en cada una e ir uniendo manualmente a la prueba interna.

No es necesario logearlos en un telefono ni instala la aplicación.

En mi caso no hubo pruebas diarias con estos usuarios solo se crearon las cuentas y unieron a la prueba interna.

A mi parecer Google no valida si se prueba la app realmente solo es un bache que ponene en el camino para asegurarse que la app sea revisada previa a su lanzamiento, pero solo es mi conjetura, no tengo forma de validarlo.

No obstante seria buena idea que te unas con tu telefono y pruebes la app desde la prueba interna para comprobar como funciona tu apliación descargada del store.

3. Esperar

Una vez conseguida la cantidad de testers debemos esperar 14 dias.

Al pasar los dias el texto ira cambiando y nos indicaran cuantos faltan.

4. 14 dias

Al llegar a esta fecha se cumplio el tiempo requerido por google play y se habilitara el boton “Solicitar acceso a producción”.

Si no se te habilita verifica si tienes los permisos necesarios, en mi caso solo el owner de la cuenta tenia la opción habilitada.

5. Formularios

Nos solicitara información sobre como fue este proceso y que feedback nos dieron los testers.

Una vez completado todo esto la app quedara en review.

6. Acceso a producción otorgado.

Si todo fue bien recibiras un mail de este tipo

En este punto ya podemos realizar el lanzamiento de nuestra app

Duración de esta etapa:

Lamentablemente esta nueva politica introducida por Google nos impone 14 dias para realizar el lanzamiento, por lo que los tiempos serian

14 dias pruebas cerrada

7 dias como maximo puede tardar la revision de nuestra etapa de pruebas.

En mi caso tardo 1 dia.

Review del build en Google Play, tardo 1 dia en mi caso.

En resumen lanzar nuestra app nos llevara mas de 20 dias, en mi caso fueron 22.

Recomiendo ni bien se tenga un MVP muy basico subirla a Google play para ir ganando tiempo.

Tengan presente que anteriormente solo tardaba alrededor de 7 dias Google play en revision para lanzar una app.

Conclusión:

El nuevo proceso complica el lanzamiento de una app de forma considerable pero sigue siendo posible realizarlo.

Hay que tener presente los tiempos y comunicarlos en casos de desarrollos para terceros.

Esperemos que Google revise estas nuevas politicas, las revierta o le de la facilidad a los devs indie de poder cumplirlas de manera mas facil.

Espero que te haya servido y cualquier consulta te invito a que la dejes en la caja de comentarios y vere si puedo resolvertela.

Gracias!

Saludos, Sebastian

Una practica habitual en el mundo del desarrollo mobile es preestablecer la navegación de los flujos de una app en el codigo. Esto puede bastar en un proyecto simple con casos de usos muy chicos, pero en apps grandes no escala ya que para modificar un flujo es necesario subir un nuevo update.

Pensemos este escenario uno de los flujo de nuestra app consta de 3 pantallas en donde al realizar una acción avanzamos en el flujo, en cada una de estas hay una consulta al backend y este al respondernos pasamos a la que le sigue.

Supongamos que el dia de mañana se nos indica que la pantalla 2 ya no es necesaria mostrarla y debemos quitarla del flujo.

¿Como harías para dejar de mostrar una pantalla en producción?

Este es un caso complicado debido a que la app recibir el status code 200 navegara a la siguiente pantalla ya que esta prefijo su comportamiento en el código.

A lo largo de mi carrera he visto varios intentos de resolverlo uno fue mapear diferentes status al response del back y este asociarlo a una pantalla, pero no escala ya que debe mapearse todos los estados posibles lo que complica la parte backend también. Otra forma es leer del response algún elemento del json que usemos como identificador y realizar alguna acción, sigue sin ser la mejor forma.

Para poder dar solución a este escenario a mi parecer uno de los mejores camino es usar una feature que nos ofrece Android desde sus primeras versiones, estos son los DeepLinks ya son usados comúnmente para acceder a una app desde el exterior como una link en un post, un ad, etc, pero el uso poco conocido es que tmb pueden usarse para mapear pantallas dentro de una app y usarlos para navegar internamente.

Al igual que Android esta feature también esta disponible en iOS, por lo que esta solución es compatible con ambas plataforma.

Ej:

Al momento de pulsar el boton en la “pantalla 1” este realizo un request al backend al endpoint /sendform quien devolvera en alguna parte del json en el body de su response junto al status code 200 lo siguiente:

En este campo “path_next_screen” se encuentra el deeplink que apunta a la proxima pantalla a mostrar “app://screen”

En este caso nos enviara a la pantalla “Screen3” por lo que ya no se mostrara la pantalla intermedia.

Este cambio de paradigma implicara lo siguiente:

• Contemplar todos los request como correctos y solo manejar el status code 200 sin importar si la operación del usuario fue exitosa o no.
• Los códigos de respuesta 500, 403, etc se continuaran usando pero solo para el caso de fallas en el back, unauthorized, etc.
• La app ya no sabra a donde redirigir al user, solo manejara los códigos asociados a error en el backend (los previamentes descriptos).
• La logica de navegación sera movida al backend este sera quien en base al estado del user debera saber a donde redirigirlo, lo que puede aumentar la complejidad del lado del backend.
• Entender que esta flexibilidad nos ahorrara esfuerzo a futuro.

Cambios requeridos a nivel app:

Deberemos asignar a cada pantalla involucrada un deeplink.

En el caso de una app con 3 activities el mapeo dentro del AndroidManifest.xml seria el siguiente:

Como veras el deeplink mapeado sera app://screen1,2,3

En caso de tratarse de una app Single Activity puede hacerse algo similar mediante deeplinks usando navigation component.

Ejecutar navegación mediante deeplink:

Ya una vez obtenido el deeplink lo unico que debemos hacer es navegar dentro de la app usandolo como base.

Ej en caso de activities.

Seguridad en Deeplinks:

Por defecto en Android todos los activities son públicos por lo que es una buena practica que estos solo puedan ser accedido desde nuestra app solamente, ya que de otra forma cualquiera va poder acceder, ademas si por ej en un mensaje incluyo el deeplink a nuestra pantalla podrían saltar a una parte especifica de un flujo .
Para bloquear estos podemos usar el atributo exported en el AndroidManifest.xml (a partir Android 12 es obligatorio declarar su valor )

También se podra agregar una validación previa a ejecutarlos para controlar que no nos saque de la app, ya que si le paso la url de otra app o una web navegara hacia estos, a su vez también la navegación debera contar con un manejo de exception por si el deeplink no existe.

Beneficios de este nuevo enfoque:

Este enfoque nos permite que el dia de mañana contemplar nuevos casos de uso mejorar el manejo de errores ya que si el dia de mañana hay un cambio en la logica de negocio podremos enviar al user a la pantalla de error correspondiente o en el caso de tratarse de una app modular podrias enviar al user a otro flujo.

Alimentar datos a una pantalla desde el backend:

Un deeplink es basicamente una uri al que aplican los mismos conceptos que en web por lo que podemos agregarle parametros y en estos incluir contenido que consuma nuestras pantallas, por lo que el back al momento de armar su reponse podría agregar un objeto json el cual nos brindara el contenido

EJ:

Al deeplink de la pantalla 1 le agregamos parametria mediante el param ?json

Para poder ser interpretada esta debe estar encodeada en formate HTML, para nuestro ejemplo el response con el deeplink codificado seria:

este fue generado con https://meyerweb.com/eric/tools/dencoder/

Nuestra activity para poder recuperar los datos debería tomarlos del parametro ?json, una forma de hacerlo puede ser la siguiente:

En este caso obtenemos el uri del intent que abrio el activity para extraer el parametro “json” en formato string para luego convertirlo usando la libreria Gson. Esta nos permite convertir un string en un objeto en este caso mediante el metodo fromJson() le indicamos que debera realizarlo usando como referencia el modelo ResponseObject el cual contiene el formato del json enviado en el deeplink.

Pros y Contras:

Ya casi llegando al final veamos algunos pros y contras.

Pros:

• Darle flexibilidad al producto.
• Navegación modificable sin necesidad de nuevos updates de la app.
• Posibilidad de suministrar datos para el contenido de una pantalla desde el backend.
• Muy fácil A/B Testing
• Fácil implementación ya que se basa en una feature propia del SDK de Android.
• Compatible con iOS.

Contras:

• Al mover la logica de navegación al backend se crea una dependencia fuerte a este.
• Aumenta la complejidad del backend ya que los casos de uso deberán controlarse desde este lado.

Esto fue todo!

Gracias por llegar hasta aquí, espero que les haya sido util.

Hasta el proximo articulo!

Saludos

Sebastian

El score de una app es una de las primeras cosas que ven tus futuros usuarios en los stores. Un buen o mal puntaje influira en la decisión sobre la instalación de la app.

Esta es una metrica que puede variar muy rapido por eso es importante estar al dia siempre.

Es por este motivo que arme un pequeño script el cual al ejecutarse obtiene el score de una app de Google Playstore y la publica en un canal de slack, lo que le permita en un ambiente laboral que los diferentes sectores tengan visibilidad de esta.

Para esto cree un pequeño proyecto en node.js el cual se encuentra aqui:

GitHub - sebacipolat/app-score-monitor

Este utiliza la libreia google-play-scraper para extraer los datos del Google PlayStore mediante un scrapping ya que no existe un api oficial que proporcione esta información.

Al momento de ejecutar el codigo lo primero que realizara es leer un archivo de texto “last_score.txt” del cual extraera el ultimo puntaje guardado en caso de no existir creara el archivo. Luego obtendra mediante dicha libreria el score de la app y lo guardara en el archivo de texto, con el score obtenido realizara un analisis y enviara un mensaje de slack.

Estado contemplados.

Scoring muy bajo:

Si el puntaje es menor a 4.0 (puede modficarse en el file notifier.js)

El scoring en subida:

El score de la app subio respecto de la ultima ejecución.

El scoring en bajada:

El score de la app bajo respecto de la ultima ejecución.

Scoring Actual:

El score de la app no vario respecto de la ultima ejecución.

Botones:

App te llevara a la ficha de la app en Google Playstore

Score Historial Deberas definir la url de la sección Estadisticas de tu Play Console,para poder hacerlo deberas editar los archivos dentro de la carpeta ‘slack_blocks’

¿Como ejecutar el script?

Para poder ejecutarlo debemos setear las siguientes variables de entorno:

PACKAGE_ID: Es el nombre del paquete que identifica a la app

Ejemplo para mi app Anotadroid (una de mis primeras apps)

https://play.google.com/store/apps/details?id=cipolat.Anotadroid

el package id seria: cipolat.Anotadroid

COUNTRY_ID:

La libreria requiere el codigo del pais

• country (optional, defaults to 'us'): the two letter country code used to retrieve the applications. Needed when the app is available only in some countries. https://www.iso.org/obp/ui/#search

Ejemplo:

Argentina= ar

USA= us

SLACK_WEBHOOK: Webhook de Slack al canal donde se enviara el mensaje

Instalar dependencias:

npm install

Run:

node app.js

Veremos lo siguiente:

Ejecución en CI:

Este script es ideal para setear en un workflow de un CI y establecer que se ejecute mediante una tarea programada al inicio del dia por ejemplo.

Debe tenerse en cuenta lo siguiente:

Clonar este proyecto en un repositorio interno.

Configura variables de entorno.

Luego de la ejecución del script debe pushearse al repositorio donde el archivo “last_score.txt”

En el mundo de las aplicaciones móviles las aplicaciones modulares son cada vez mas populares y el camino a tomar para todo proyecto que va escalar e ira mas alla de una app pequeña.

En mi caso me especializo en el desarrollo de apps Android por lo que esta guia estara orientado a esa tecnologia.

Al trabajar con modulos es muy común utilizar herramientas como maven en donde se publicaran las diversas versiones.

Es muy importante poder saber cuales son las ultimas versiones liberadas para poder estar siempre al dia. Si utilizas algunas herramienta como jfrog no sera posible utilizar el badge de version como si podríamos hacerlo con maven publico.

Para poder resolver esto se me ocurrió una solución muy simple y rapida.

Esta consiste en inlcuir a la task de nuestro CI que sube las versiones un script que actualice en un repositorio un archivo html y luego cada vez que se lo modifica se publique en gitlab pages.

Nuestro dashboard al finalizar se vera de la siguiente forma

Manos a la obra:

1- Lo primero que debemos hacer es crear un repositorio, ej. version-status

2- Podemos crear un simple archivo html con el siguiente contenido:

En este pondremos el nombre de todos los modulos y la url con el badge y su version.

Para los badges usaremos https://shields.io/ el cual nos permite generar un badge con la parametria enviada en la url

Ej: En este caso un modulo se llama player y la ver es la 4.0.1

Su apariencia sera la siguiente:

3- Debemos asegurarnos que todos los pipeline que suban versiones en el CI puedan tener acceso a este.

4- En la tarea de nuestro pipeline que genera el release del modulo debemos poder contar con las siguientes variables de entorno:

“$MODULE” Nombre del modulo, esta puede estar prefija por nosotros al momento de configurar el pipeline o ser obtenida de alguna forma

“$VERSION” hace referencia a la version que acabamos de generar.

Para poder obtener la version de un .aar podemos obtenerla del manifest

ej:

En mi caso utilizo Bitrise con una imagen de Linux Ubunut quien nos proporciona un plugin que extrae esta información y las disponibiliza como variables de entorno

A este plugin debemos decirle cual es el path del AndroidManifest.xml resultante del proceso de release final:

En mi caso es:

“./$MODULE/build/intermediates/aapt_friendly_merged_manifests/release/aapt/AndroidManifest.xml”

- android-manifest-info@1.0:
    inputs:
       - manifest_file: "./$MODULE/build/intermediates/aapt_friendly_merged_manifests/release/aapt/AndroidManifest.xml"

Usando esta tool la variable $VERSION seria reemplazada por $AMI_VERSION_CODE

En caso de no utilizar bitrise podrás obtener esta info leyendo el archivo directamente.

Como hacerlo desde bash: https://stackoverflow.com/questions/17333755/extract-xml-value-in-bash-script

5-

Luego deberas cargar el siguiente script posterior al momento de la subida del modulo.

Explico cada linea

git clone git@gitlab.com:nx/app/version-modules.git

Clona el repositorio y descarga los archivos

cd ‘version-modules’

cambia a la carpeta clonada recientemente

Busca dentro del archivo last_version.html si existe la sección

search=”<tr><td><strong>$MODULE</strong></td>”

si nuestro modulo se llama player al momento de buscar, encontrara la primera row de la tabla

<tr><td><strong>player</strong></td>

Mediante grep busca dentro del archivo si existe una row con ese contenido en caso de existir ejecutara el comando sed buscara linea donde se encuentre la coincidencia y la reemplazara con la linea completa.

sed -i “/$MODULE/c\<tr><td><strong>$MODULE</strong></td><td style=’text-align: center;’><img src=’https://img.shields.io/badge/version-$VERSION-brightgreen'/></td></tr>" $FILE

En caso de no encontrar la linea en el archivo la agregara, por lo que el script permitira que nuevos modulos puedan irse incorporando sin necesidad de modificar manualmente el archivo

Luego commitea y realiza un push del cambio.

6-

Agregar Gitlab Page

Nuestro repositorio necesitara tener activado esta feature.

Cada vez que se pushe un archivo queremos que se actualice la Gitlab Page por lo que crearemos el archivo gitlab-ci.yml

pages:
  stage: deploy
  script:
  - mkdir .public
  - cp -r * .public
  - mv .public public
  artifacts:
    paths:
    - public
  only:

  - main

Veremos que corre el pipeline cada vez que se corre el script.

Ahora solo deberias acceder a tu gitlab page, para ver la url debers ir a

Settings->Pages

En mi caso es https://scipolat.gitlab.io/last-version-badges

per la url completa seria:

https://scipolat.gitlab.io/last-version-badges/last_version.html

Si deseas modificar la privacidad de la gitlab page puedes hacerlo en

Settings->General

Espero que este contenido te haya sido util.

Hasta la proxima!

Sebastian

Hola en el último tiempo estuve buscando formas de mejorar los code review y me tope con una tool muy interesante llamada Danger

Danger es una herramienta basada en ruby que nos permite automatizar las tareas habituales de revisión de código mediante el envío de mensajes en los PR, esta debe ser incluida dentro del proceso de build en tu CI. al crear tus propias reglas para tu equipo puedes desligar tareas habituales para concentrarte en problemas más difíciles,tambien podras reforzar la cultura de pull request.

En este artículo veremos cómo integrar danger usando Gitlab + Bitrise

Setup:

La forma más fácil de instalar Danger es mediante Bundler.

Bundler es un administrador de dependencias para Ruby que usa un Gemfile para definir todos los proyectos de Ruby que desea usar.

Abre la consola:

Primero deberías revisar si tiene instalados gem y bundler.

Deberás ejecutar

gem install bundler

Luego tendrás que crear un gemfile

bundler init

Modfica el archivo con lo siguiente

source "https://rubygems.org"

git_source(:github) { |repo_name| "https://github.com/#{repo_name}" }

gem 'danger-gitlab'

En nuestro caso usaremos danger-gitlab el cual esta pensado para poder ser usado en Gitlab, en caso que queramos usar Github habría que usar

gem ‘danger’

Luego instala las dependencias y valida la versión

bundle install
bundle exec danger --version

En este punto ya puedes crear tu dangerfile y empezar a escribir tus propias reglas.

Creando DangerFile

Ingresa en la terminal

bundle exec danger init

Te guiará a través de 4 pasos, en el que te proporcionará algunasreglas por default, y demás configuraciones para utilizar en tu repositorio y CI

Puede ejecutarlo para que cree el dangerfile.

En unos momentos veremos mas en profundidad este archivo y las reglas que puedes usar, pero llegó el momento de mostrarte cómo configurarlo en Bitrise.

Bitrise:

Hace un tiempo que ya vengo trabajando con esta herramienta y es uno de los CI cloud más fáciles y pensados para mobile.

1- Alta de proyecto:

No voy a explicar como dar de alta una app Android ya que se va del scope de este artículo, pero en el siguiente link veras como hacerlo de forma fácil.

https://devcenter.bitrise.io/getting-started/getting-started-with-android-apps/

Una vez que tu pipeline se ejecute correctamente, podemos pasar al siguiente paso.

2- Definir variables

Tendremos que definir algunas variables de entorno que utilizaremosen la configuración.

Necesitaremos dar de alta un access token en Gitlab que nos permitaacceder a nuestro repositorio, asegurate ponerle permisossuficientes para poder realizar comentarios.

Puede ser buena idea que crees una cuenta especial para danger.

Referencia: https://danger.systems/guides/getting_started.html

Ahora si abre el workflow de tu proyecto en Bitrise y ve a la seccion

Ingresa las siguientes:

DANGER_GITLAB_API_TOKEN token de acceso al repositorio

DANGER_GITLAB_HOST Host donde esta corriendo gitlab

ej gitlab.com (solo el nombre del dominio no incluir http o https)

DANGER_GITLAB_API_BASE_URL Url de GitLab Api.

Ejecutar danger en tu pipeline:

Dirigite a la sección

Luego en alguna parte del workflow deberas agregar un bloque de script

Script:

- script@1:
   run_if: ".IsPR"
   inputs:
   - content: |-
       #!/bin/bash
       set -ex
       if [ -f 'Dangerfile' ] ; then
       bundle install
       # Running Danger
       bundle exec danger --fail-on-errors=true
       fi

El siguiente script ejecutará danger solamente cuando se trate de un Pull request y el Dangerfile exista, al agregar — fail-on-errors=true el pipeline fallara, lo veremos mas adelante

Getting Set Up

Conociendo el DangerFile:

En este archivo es donde haremos nuestras reglas que nos permitirán acceder al contenido del pull request y en base a este poder dejar comentarios, fallar el pipeline, leer reportes de test xml, etc.

Como te comente danger está desarrollada en Ruby por lo que este archivo estará escrito en este lenguaje pero existen diversidad de plugins que te permitirán kotlin, swift, javascript.

https://github.com/danger/awesome-danger

En nuestro caso usaremos ruby.

Existen 3 tipos de mensajes que puedes incluir en un comentario.

Aquí te dejo un ejemplo de cómo se verían dentro del danger file y en el repositorio.

fail “Por favor incluye un resumen detallado a tu Merge Request. Puedes usar de guía el template configurado en tu repositorio.”

warn “:construction_worker: Happy coding [WIP]”

message “Gracias por tu pull request! :+1:”

En el repositorio lo veias asi:

El plugin Danger Gitlab nos dejará acceder a diversos elementos pull request:

tales como el título, cuerpo del repositorio, listado de archivos incluidos, etc.

En el siguiente link podras ver mas información y algunos ejemplos:

https://www.rubydoc.info/gems/danger/3.4.1/Danger/DangerfileGitLabPlugin

Ejemplos:

Supongamos que quieres automatizar algunas reglas que todo pull request deba cumplir y si no lo hacentrollearlos mediante un meme con un comentario de aviso.

Validar demasiados cambios:

#Pull Request demasido grande

if git.lines_of_code.length >35

warn “<img src=’https://i.pinimg.com/564x/3e/90/0f/3e900f828399313ad142fd1ea25486f3.jpg' width=’140'/>

:monkey_face: Parece que tu pull request es demasiado grande, tal vez puedas dividirlo en otros mas pequeños.”

end

Programáticamente válida si la cantidad de líneas incluidas supera a 35

“if git.lines_of_code.length >35”

Cuando se cumpla esa condición incluirá un comentario del tipo

warn con una imagen y texto.

Ticket de jira incluido en la descripción:

#Validar si incluyo ticket de jira en la descripción

if !gitlab.mr_body.include? "jira"

warn "<img src='https://pics.me.me/thumb_what-ifitold-you-no-jira-%3Eno-merge-meme-creator-funny-50240445.png

width='200'/>

:pizza: Seria genial si puede incluir el ticket de Jira asociado a este cambio."

end

if !gitlab.mr_body.include? “jira”

Válida si dentro del body de la descripción del PR no se encuentra la palabra “jira”

En caso afirmativo mostrará un meme y un aviso.

Fallar pipeline

Puedes hacer fallar un pipeline mediante el uso de “fail”

y al momento de iniciar danger incluir el siguiente parametro

 — fail-on-errors=true

Ej:

Fallar pipeline cuando el contenido es poco.

if gitlab.mr_body.length < 5

fail “:pencil:Por favor incluye un resumen detallado a tu Merge Request.

Puedes usar de guia el template configurado en tu repositorio.”

end

Presencia de unit test?

Validamos si en tu pull request modificaste código Kotlin pero no incluiste su test unitario.

#Detecta cuando hubo un cambio en un archivo *.kt pero no se incluyeron test unitarios.

modified_test = git.modified_files.select { |path| path.include? “test/” }

if git.modified_files.include? “*.kt” && modified_test.empty?

warn “<img src=’https://memegenerator.net/img/instances/75590953/unit-tests-cant-fail-if-there-are-no-unit-tests.jpg' width=’200'/>

:exclamation: No olvides incluir los test unitarios!”

end

modified_test = git.modified_files.select { |path| path.include? “test/” }

Obtiene listado de archivos que incluyan en su path la carpeta de test unitarios de android.

“if git.modified_files.include? “*.kt” && modified_test.empty?”

Si en los archivos modificados hay uno terminado en *.kt pero no haya test enviará un meme y el mensaje de error.

Ejecutar Dangerfile Desde otro repositorio

Seguramente querrás centralizar tus rules en un solo lugar y poder consumirlo desde otros repositorios.

Para poder hacerlo estos deberás crear un repositorio en donde alojar el Dangerfile

Supongamos que el repo se llama:

https://gitlab.com/user/dangerrepo

Este se encuentre dentro de una carpeta rules en el branch main

Dentro del proyecto de tu aplicacion deberas tener un Dangerfile

Dentro debera incluir lo siguiente:

Ejemplo:

danger.import_dangerfile( gitlab: 29385092 , branch: “main” , path:”rules/Dangerfile” )

Listo de esta forma cuando corra tu pipeline obtendra las rules de un unico lugar.

En resumen:

Danger nos permite enfocarnos en las tareas importante y dejar validaciones triviales a una maquina, al poder hacer tus propias reglas existen infinitas posibilidades.

Esto fue todo por hoy, en futuros articulos veremos como integrar los reportes del lint de android y llevar tus code review a otro nivel.

Gracias por tu tiempo!

Si te gusto mi contenido te invito a que me sigas!

Fuentes:

https://git.panter.ch/open-source/danger-rules

https://www.wearemobilefirst.com/blog/how-to-automate-the-android-code-review-process-using-danger

https://blog.bitrise.io/post/danger-danger-uh-that-is-using-danger-with-bitrise

https://danger.systems/guides/getting_started.html#including-danger

https://blog.bitrise.io/post/automating-code-review-tasks-for-multi-module-android-projects