Cómo mantener la versión gratuita / de pago de la aplicación separada en subversion

8

Tengo una aplicación paga en el mercado de Android, sin embargo, quiero lanzar una versión gratuita con publicidad.

La forma más fácil en que pensé hacer esto fue configurar una rama en mi repositorio de subversión que tenga el código adicional para agregar los anuncios. Sin embargo, cuando fui a enviar esto al mercado de Android, requieren nombres de paquete únicos. Esta solución ya no me funciona porque tendría que cambiar el paquete de cada archivo de clase, lo que dificultaría mucho la fusión del tronco y la rama.

¿Cuál es la mejor manera en que puedo mantener estos dos proyectos juntos, compartiendo parches, pero con un paquete diferente?

version-control android svn

— Malfist
fuente

1

Solo una nota de que esta pregunta no está fuera de tema aquí en Programadores. Los problemas principales son sobre la estructura del proyecto y los problemas de administración de la configuración, los cuales pertenecen aquí (y no en Stack Overflow o cualquier otro sitio).

— Thomas Owens

9

¿Has considerado las directivas del compilador ?

Ejemplo:

#define FREE
// ...
#if FREE
Console.WriteLine("Free version");
#else
Console.WriteLine("Paid version");
#endif

Puede mantener exactamente la misma base de código y apuntar a las dos compilaciones utilizando dos scripts de compilación separados o uno parametrizable.

msbuild /p:DefineConstants=FREE

Para hacerlo con Java, lea esto y esto . Y tal vez esto .

— Comunidad
fuente

No pensé que Java escuchara esas cosas

— Malfist

También existe en Java.

@ Pierre303 Lo siento, no sabía que podías hacer eso. Sin embargo, todavía no resuelve el problema del paquete ... hmmm.

— Michael K

1

@MichaelK: esto se puede lograr fácilmente con una tarea bien organizada de buscar y reemplazar en su script de compilación.

Esto tampoco resuelve el problema de los recursos condicionales en la carpeta / res.

— donturner

5

Solo su paquete de solicitud debe ser único. Ver aquí . Ese es el paquete declarado en su archivo de manifiesto. Puede tener la mayor parte de su código com.mydomain.myappy solo tener una actividad principal diferente com.mydomain.myapp.free.

— Karl Bielefeldt
fuente

3

Si realmente quiere hacerlo por separado, la mejor manera es configurarlo como dos partes del mismo repositorio. De esa manera, al menos puede combinar cambios en las diferentes ramas. Si desea mantener las cosas completamente separadas, entonces estará haciendo muchos archivos de parches schlepping.

He hecho esto y, francamente, no es una gran estrategia en la práctica. Mucho mejor, especialmente en entornos compilados, es tener un proceso de compilación separado de forma gratuita versus de pago, por lo que hay una base de código en lugar de dos. Si hay dos bases de código cosas se separan.

— Wyatt Barnett
fuente

Esa es la cosa, no quiero que se separen. Lo único que quiero por separado es el código adicional que agrega los anuncios. Sin embargo, Android me obliga a tener un nombre de paquete único para mi aplicación. Por lo tanto, me vería obligado a tener un cambio mayor que solo dos o tres archivos.

— Malfista

Tal vez, un pequeño vudú precompilador también debería funcionar. Los sistemas de construcción son cosas increíbles.

— Wyatt Barnett

0

El control de versiones es una forma pobre de administrar cosas como esta. Terminará con una pesadilla de mantenimiento: dos aplicaciones separadas que deben ser casi idénticas.

¿Has considerado una solución de proyectos múltiples? (Caveot: en realidad no he hecho esto, pero parece factible, y creo que Android lo permitirá. Lo intentaré más tarde y veré con seguridad). Compile todo el código de su aplicación en un frasco de proyecto principal . Luego, cree dos aplicaciones de Android separadas, una para su versión paga y otra para la versión gratuita. Esto resolverá su problema de nomenclatura de paquetes. Estas aplicaciones simplemente delegarán en el archivo jar principal para casi todo, excepto que su versión de anuncio incluirá el código para admitir los anuncios.

También puede encontrar interesante esta discusión sobre un tema similar .

— Michael K
fuente

El código es una pequeña parte de la imagen completa, y JAR no lo ayuda a manejar todos los datos adicionales como recursos, diseños, activos, etc. que lo acompañan. Que no se pueda agrupar todo de forma ordenada es una deficiencia desafortunada en Android, y me duele tener que arreglar cosas que no cambian mucho o que se pueden configurar desde afuera.

— Blrfl

Estoy de acuerdo. Hicieron un gran trabajo al facilitar la creación de aplicaciones pequeñas pero difíciles de construir grandes que necesitan mantenimiento. Hay algunas soluciones de Maven que parecen prometedoras, pero aún no he podido explorarlas demasiado.

— Michael K

0

Construir su aplicación utilizando un feature togglele permitiría alcanzar su objetivo, pero es posible que deba modificar mucho código.

Al definir 2 (recomendaría 3) entorno de contenedor de características en un archivo .ini como:

[paid]
features.ads = false
features.featureOne = true
features.featureTwo = true
features.premiumFeature = true
features.underDevFeature = false
features.debug = false;

[free:paid]
features.ads = true
features.premiumFeature = false

; And the optionnal third
[development:paid]
features.debug = true
features.underDevFeature = true

De esta manera, tiene una versión que es uniforme y requiere solo una rama en su fuente de control de versiones

En sus scripts específicos, debe verificar si la función está autorizada; de lo contrario, no la mostrará.

— JF Dion
fuente