nicksaver
Curioso
Verificado
Verificación en dos pasos activada
¡Usuario con pocos negocios! ¡Utiliza siempre saldo de Forobeta!
Hola a todos.
Hace poco estuve preparando para entregar un proyecto formado por dos aplicaciones Android nativas que trabajan de manera coordinada. Las dos están desarrolladas con Kotlin, Jetpack Compose, ViewModels y Hilt para la inyección de dependencias.
El proyecto funciona bien, está ordenado y listo para implementar. Sin embargo, apareció una duda bastante común cuando un código cambia de dueño o tiene que adaptarse a otra marca: ¿hace falta cambiar por completo el paquete raíz, por ejemplo com.dominio.*?
A simple vista parece un trámite. Android Studio tiene la opción Refactor → Rename, uno cambia el nombre, vuelve a compilar y supone que quedó todo resuelto.
En un proyecto chico puede funcionar sin demasiadas vueltas. Pero cuando hablamos de aplicaciones grandes, con varios módulos, código generado y servicios externos, tocar la estructura completa puede traer bastante más trabajo del que parece.
En los proyectos Android actuales hay una diferencia importante entre el namespace y el applicationId. Muchas veces tienen el mismo valor porque Android Studio los configura así al crear el proyecto, pero no cumplen la misma función.
El namespace, definido en el build.gradle.kts, forma parte de la estructura técnica interna. Determina, entre otras cosas, dónde se generan clases como R y BuildConfig, y debe mantenerse en sintonía con los paquetes, imports y módulos del código.
Técnicamente se puede cambiar, por supuesto. El problema es que hacerlo en un proyecto avanzado no consiste solamente en reemplazar un nombre.
Si durante la refactorización queda un import viejo, una clase en la ruta anterior, un módulo fuera de lugar o alguna referencia que Android Studio no detectó, la compilación empieza a fallar. Y no siempre devuelve un error que señale claramente dónde está el problema.
Con Hilt el asunto se vuelve todavía más delicado.
Hilt y Dagger generan una buena cantidad de código durante la compilación a partir de las clases, módulos y componentes del proyecto. En condiciones normales, si la refactorización está perfectamente hecha, una limpieza y una nueva compilación deberían regenerar todo correctamente.
El problema está justamente en ese “perfectamente”. Una referencia que quedó apuntando al paquete anterior puede terminar provocando errores en el gráfico de dependencias. Muchas veces el mensaje aparece en una clase generada, aunque la causa real esté en otro archivo completamente distinto. Entonces uno termina revisando módulos, anotaciones e imports hasta encontrar qué quedó fuera de lugar.
No es algo imposible de resolver, pero puede hacerte perder horas o días, sin aportar ninguna mejora real al funcionamiento de la aplicación.
El applicationId es el identificador con el que Android, Google Play y servicios como Firebase reconocen a la aplicación.
Y acá está el punto más importante: se puede conservar el namespace y toda la estructura interna del proyecto, pero cambiar solamente el applicationId para publicar la app con la identidad del comprador.
Por ejemplo: com.empresa.toughworker
De esta manera no hace falta renombrar carpetas, paquetes, clases ni imports. El código puede seguir usando su raíz técnica original, mientras la aplicación se registra y se distribuye como un producto nuevo.
Obviamente, cambiar el applicationId también requiere hacer algunas configuraciones. Hay que crear o registrar la nueva aplicación en Firebase, descargar el google-services.json correspondiente y revisar las firmas, las huellas SHA, los proveedores de autenticación, los deep links y cualquier API vinculada al identificador anterior.
Pero eso es parte de preparar una nueva instancia de la aplicación. No implica desarmar y volver a organizar todo el código fuente.
En mi caso no se trata de una sola aplicación, sino de dos apps que se comunican y funcionan como partes de un mismo sistema. Por eso, una refactorización completa suma todavía más puntos para revisar.
Puede haber intents explícitos, permisos personalizados, autoridades de FileProvider, enlaces profundos o referencias dentro de los manifiestos y archivos de configuración. Algunas se actualizan automáticamente y otras no.
Si el proyecto fue preparado usando variables como ${applicationId} en lugar de identificadores escritos a mano, el cambio resulta mucho más simple. Pero si existen valores fijos dentro del código o de los manifiestos, hay que encontrarlos y revisarlos uno por uno.
Después de trabajar con este tipo de proyectos, mi conclusión es bastante sencilla: si el cambio es solamente comercial, no tiene sentido tocar toda la estructura técnica.
El nombre que ve el usuario, los íconos, los colores, los textos y la identidad visual pueden modificarse desde los recursos y la configuración de cada aplicación. Y si el comprador necesita publicarla con un identificador propio, se cambia el applicationId y se configuran nuevamente los servicios que correspondan.
Refactorizar el namespace completo solo para que coincida con una marca nueva agrega trabajo, aumenta el riesgo de introducir errores y no mejora en nada el producto final.
Distinto sería que existiera una razón técnica concreta para reorganizar el código. En ese caso sí, habría que hacerlo de manera planificada, con una copia previa, búsquedas globales, pruebas por etapas y una revisión cuidadosa de cada módulo.
¿Ustedes cómo manejan este tema cuando compran, venden o reciben un código fuente? ¿Mantienen la estructura técnica original o prefieren refactorizar todo antes de publicarlo?
Hace poco estuve preparando para entregar un proyecto formado por dos aplicaciones Android nativas que trabajan de manera coordinada. Las dos están desarrolladas con Kotlin, Jetpack Compose, ViewModels y Hilt para la inyección de dependencias.
El proyecto funciona bien, está ordenado y listo para implementar. Sin embargo, apareció una duda bastante común cuando un código cambia de dueño o tiene que adaptarse a otra marca: ¿hace falta cambiar por completo el paquete raíz, por ejemplo com.dominio.*?
A simple vista parece un trámite. Android Studio tiene la opción Refactor → Rename, uno cambia el nombre, vuelve a compilar y supone que quedó todo resuelto.
En un proyecto chico puede funcionar sin demasiadas vueltas. Pero cuando hablamos de aplicaciones grandes, con varios módulos, código generado y servicios externos, tocar la estructura completa puede traer bastante más trabajo del que parece.
En los proyectos Android actuales hay una diferencia importante entre el namespace y el applicationId. Muchas veces tienen el mismo valor porque Android Studio los configura así al crear el proyecto, pero no cumplen la misma función.
El namespace, definido en el build.gradle.kts, forma parte de la estructura técnica interna. Determina, entre otras cosas, dónde se generan clases como R y BuildConfig, y debe mantenerse en sintonía con los paquetes, imports y módulos del código.
Técnicamente se puede cambiar, por supuesto. El problema es que hacerlo en un proyecto avanzado no consiste solamente en reemplazar un nombre.
Si durante la refactorización queda un import viejo, una clase en la ruta anterior, un módulo fuera de lugar o alguna referencia que Android Studio no detectó, la compilación empieza a fallar. Y no siempre devuelve un error que señale claramente dónde está el problema.
Con Hilt el asunto se vuelve todavía más delicado.
Hilt y Dagger generan una buena cantidad de código durante la compilación a partir de las clases, módulos y componentes del proyecto. En condiciones normales, si la refactorización está perfectamente hecha, una limpieza y una nueva compilación deberían regenerar todo correctamente.
El problema está justamente en ese “perfectamente”. Una referencia que quedó apuntando al paquete anterior puede terminar provocando errores en el gráfico de dependencias. Muchas veces el mensaje aparece en una clase generada, aunque la causa real esté en otro archivo completamente distinto. Entonces uno termina revisando módulos, anotaciones e imports hasta encontrar qué quedó fuera de lugar.
No es algo imposible de resolver, pero puede hacerte perder horas o días, sin aportar ninguna mejora real al funcionamiento de la aplicación.
El applicationId es el identificador con el que Android, Google Play y servicios como Firebase reconocen a la aplicación.
Y acá está el punto más importante: se puede conservar el namespace y toda la estructura interna del proyecto, pero cambiar solamente el applicationId para publicar la app con la identidad del comprador.
Por ejemplo: com.empresa.toughworker
De esta manera no hace falta renombrar carpetas, paquetes, clases ni imports. El código puede seguir usando su raíz técnica original, mientras la aplicación se registra y se distribuye como un producto nuevo.
Obviamente, cambiar el applicationId también requiere hacer algunas configuraciones. Hay que crear o registrar la nueva aplicación en Firebase, descargar el google-services.json correspondiente y revisar las firmas, las huellas SHA, los proveedores de autenticación, los deep links y cualquier API vinculada al identificador anterior.
Pero eso es parte de preparar una nueva instancia de la aplicación. No implica desarmar y volver a organizar todo el código fuente.
En mi caso no se trata de una sola aplicación, sino de dos apps que se comunican y funcionan como partes de un mismo sistema. Por eso, una refactorización completa suma todavía más puntos para revisar.
Puede haber intents explícitos, permisos personalizados, autoridades de FileProvider, enlaces profundos o referencias dentro de los manifiestos y archivos de configuración. Algunas se actualizan automáticamente y otras no.
Si el proyecto fue preparado usando variables como ${applicationId} en lugar de identificadores escritos a mano, el cambio resulta mucho más simple. Pero si existen valores fijos dentro del código o de los manifiestos, hay que encontrarlos y revisarlos uno por uno.
Después de trabajar con este tipo de proyectos, mi conclusión es bastante sencilla: si el cambio es solamente comercial, no tiene sentido tocar toda la estructura técnica.
El nombre que ve el usuario, los íconos, los colores, los textos y la identidad visual pueden modificarse desde los recursos y la configuración de cada aplicación. Y si el comprador necesita publicarla con un identificador propio, se cambia el applicationId y se configuran nuevamente los servicios que correspondan.
Refactorizar el namespace completo solo para que coincida con una marca nueva agrega trabajo, aumenta el riesgo de introducir errores y no mejora en nada el producto final.
Distinto sería que existiera una razón técnica concreta para reorganizar el código. En ese caso sí, habría que hacerlo de manera planificada, con una copia previa, búsquedas globales, pruebas por etapas y una revisión cuidadosa de cada módulo.
¿Ustedes cómo manejan este tema cuando compran, venden o reciben un código fuente? ¿Mantienen la estructura técnica original o prefieren refactorizar todo antes de publicarlo?
