android - uber - Creación de aplicaciones de demostración y versión completa basadas en una base de código/proyecto

lector codigo de barras

Question

He desarrollado una aplicación de Android en un proyecto con Eclipse, está estructurada (viene de iPhone) por lo que una constante define si es la versión de demostración o la versión completa.

Ahora tengo el problema de que cada vez que quiero crear la versión demo necesito cambiar la constante pero también necesito hacer una copia del proyecto con un nombre de paquete diferente.

Obviamente, es necesario copiar el código en la versión original completa a la demostración o tendré que volver a hacer la creación de la aplicación de demostración cada vez que envíe mi aplicación.

Veo tres posibles enfoques:

1. Aunque he estudiado proyectos de bibliotecas, todavía no está claro cómo esto realmente proporciona una buena solución en este caso.

Por ejemplo, si tengo la versión completa con una estructura de actividad:

A1
A2
A3

utilizando las clases de utilidad U1, U2

Ciertamente, U1 y U2 pueden estar en un proyecto de biblioteca y hacer referencia a ambos proyectos, pero las actividades, strings.xml, gráficos, diseños deben duplicarse (¿o hay alguna otra manera que no veo?) Esto no parece ser un buen camino a seguir y desafortunadamente no se ha explicado en preguntas similares sobre este tema cuando se sugirió este enfoque.

2. La otra forma sería crear diferentes nombres de paquetes basados ​​en diferentes configuraciones de compilación (similar a iPhone), sin embargo, esto no parece ser posible en Eclipse en lugar de usar algunos guiones externos (que, honestamente, prefiero evitarlo). parece bastante propenso a errores) mientras que la compilación debe ser invocada fuera de Eclipse

3. El enfoque probablemente más sencillo (y también actualmente con un esfuerzo menor) es copiar el proyecto, cambiar la constante, renombrar el paquete y compilar / exportar cada vez que lo envíe. Sin embargo, esto parece ser más bien "básico" y ciertamente no parece profesional (en comparación con la configuración de compilación / objetivo de iPhone / xCode)

¿Cuál sería el mejor enfoque (que requiere una cantidad mínima de cambios y aún así es estable y fácil de usar)?

¡Muchas gracias!

EDITAR

Para todos los que probaron la solución de Tim, funciona bien, sin embargo, tuve un problema con los atributos personalizados.

Comprueba esto: ¿cómo resolver los atributos personalizados de las bibliotecas de Android y el remapeo del nombre del paquete durante la compilación? resolverá el isse para las bibliotecas

Answer 1

Veo que el enfoque más simple sería tener tres proyectos:

1. manifestación
2. completo
3. biblioteca

La demostración y los proyectos completos tendrán cada uno su propio nombre de paquete único, tal como se define en su respectivo archivo de Manifiesto. Sus Actividades son simplemente puertos que envían información en un paquete a la Actividad principal en el proyecto de la biblioteca. La actividad en el proyecto de la biblioteca leerá el paquete pasado para los parámetros necesarios que determinan si fue lanzado por la actividad de la demostración o la actividad completa. Entonces procederá en consecuencia.

Entonces la lógica es así:

El usuario inicia la demostración Actividad -> La actividad de demostración crea un paquete con la información que dice que es la demostración Actividad -> La actividad de demostración inicia la actividad de la biblioteca que luego ejecuta el resto del programa en modo demostración.

O

El usuario inicia la actividad completa -> La actividad completa crea un paquete con la información que dice que es la actividad completa -> La actividad completa inicia la actividad de la biblioteca que luego ejecuta el resto del programa en modo completo.

Answer 2

Estoy haciendo esto actualmente en eclipse, y no es difícil.

1. Convierta la fuente existente en proyecto de biblioteca.

2. Crea dos nuevos proyectos, gratis y de pago.

3. Incluya el proyecto de la biblioteca en los proyectos gratuitos y pagos.

No es necesario tener una sola actividad o recurso dentro de los proyectos gratuitos / pagos. Todo lo que necesita es un manifiesto para cada uno que haga referencia a las actividades de su biblioteca. Mis proyectos gratuitos y completos actualmente no tienen ningún archivo java, recurso o diseño de ningún tipo, es solo un manifiesto que hace referencia a actividades de la biblioteca.

Utilizo exactamente el mismo código para ambos proyectos, y los diferencio diciendo:

if(getApplicationContext().getPackageName().equals("full version package name")) {
    //do full stuff
} else {
    //do free stuff
}

Algunos problemas que he alcanzado, especialmente si ya has lanzado tu aplicación en el mercado:

• Si cambias el nombre completo / ruta de alguna actividad, desaparecerá de tu pantalla de inicio. Por lo tanto, si su biblioteca tiene un nombre de paquete diferente al de la versión existente, perderá los iconos de la pantalla de inicio. Pueden ser reemplazados por el usuario, pero no es ideal.
• Similar para aplicaciones, si cambias el nombre de su receptor, desaparecerán en la actualización.
• Bajo ninguna circunstancia puede cambiar el nombre del paquete de una aplicación lanzada.

Si ya ha lanzado una versión gratuita y pro, es algo desafortunado, porque la ruta de actividad tendrá que cambiar a una ruta de biblioteca común, y no puede cambiar el nombre del paquete liberado para que coincida con la ruta de la biblioteca. Entonces, alguien tendrá que perder sus iconos existentes.

En mi caso, solo había lanzado una versión gratuita antes de dividirla, y pude nombrar la biblioteca con el mismo nombre de paquete que la versión gratuita. Era escéptico de que se le permitiera incluir una biblioteca con el mismo nombre de paquete que el paquete contenedora, pero aparentemente es posible hacerlo (trabajando bien para mí).

Entonces en mi caso tengo tres proyectos:

• Biblioteca principal: nombre del paquete: com.myname.myapp
• Versión gratuita: nombre del paquete: com.myname.myapp
• Versión Pro: nombre del paquete: com.myname.myapp.Pro

Y la versión gratuita y completa manifiesta agregar actividades que se denominan com.myname.myapp.ActivityA o com.myname.myapp.ActivityB , que solo existen en el proyecto de la biblioteca.

Answer 3

Es muy simple al usar build.gradle en Android Studio. Lea sobre productosFlavors . Es una característica muy útil. Simplemente agregue las siguientes líneas en build.gradle:

productFlavors {
    lite {
        packageName = ''com.project.test.app''
        versionCode 1
        versionName ''1.0.0''
    }
    pro {
        packageName = ''com.project.testpro.app''
        versionCode 1
        versionName ''1.0.0''
    }
}

En este ejemplo, agrego dos sabores de producto: primero para versión lite y segundo para versión completa. Cada versión tiene su propia versionCode y versionName (para publicación de Google Play).

En el código, simplemente compruebe BuildConfig.FLAVOR:

if (BuildConfig.FLAVOR == "lite") {
   // add some ads or restrict functionallity

}

Para ejecutar y probar en el dispositivo, use la pestaña "Construir variantes" en Android Studio para cambiar de una versión a otra: