poner - la mejor app para limpiar android 2018
Mantenimiento de las versiones gratuitas y profesionales de una aplicación. (4)
Quiero crear una versión PRO de mi aplicación para Android y me preguntaba cómo estructurar mi repositorio.
Para saberlo tengo un tronco y ramas de características. Me gustaría poner una versión pro en otra rama, pero tal vez hay una mejor manera? Por ejemplo, tal vez debería crear dos sucursales: una para la versión gratuita y otra para la profesional.
La versión Pro tendrá características adicionales y estará libre de anuncios, por ejemplo, No quiero incluir bibliotecas de AdMob en la versión pro.
¿Tiene alguna experiencia o sugerencia sobre cuál sería la mejor manera de estructurar el repositorio en este caso?
EDITAR: Creo que he encontrado la mejor solución (para mi aplicación) en este hilo: http://groups.google.com/group/android-developers/browse_thread/thread/4ad3d67f735f16d7/948b4f9eee2490a3
El truco discutido allí es acerca de tener otra aplicación que solo sirva para desbloquear la funcionalidad PRO en la aplicación real. La aplicación de desbloqueo se paga en el mercado y la aplicación real simplemente verifica su existencia en el dispositivo.
Encontré una manera fácil de hacer esto en eclipse. Me sorprendió lo fácil que fue una vez que lo descubrí.
- En las propiedades del proyecto para com.app.free, verifique que "Is Library" es verdadera (debe haber compilado el proyecto al menos una vez antes de cambiarlo; de lo contrario, aparece un error que dice que los proyectos de la biblioteca no se pueden compilar, si lo hace simplemente Desmarque, compile, luego vuelva a verificar.
- crear nuevo proyecto com.app.pro
- agregue el proyecto com.app.free como una biblioteca en la configuración del proyecto en la sección de Android del proyecto.
- crear una nueva clase MyApplication en com.app.pro y extender la aplicación
- anular onCreate () NOTA: para aquellos compañeros que copian / pegan esto NO es lo mismo que el paquete onCreate (Bundle savedInstanceState) de una actividad. Debe eliminar el argumento del paquete, ya que se trata de una aplicación y no de una actividad.
- Luego agregue o establezca la variable estática que se leerá en el método de validación para validar la licencia. EX: IS_PRO = verdadero; entonces el método de validación lee la variable y devuelve verdadero si IS_PRO es verdadero.
- Copie los contenidos de manifiesto de com.app.free a com.app.pro
- agregue android: name = "MyApplication" a la etiqueta de la aplicación en el manifiesto com.app.pro
- Agregue com.app.free en frente del nombre del atributo para todas las actividades. (Esto hace que la aplicación sepa que sus actividades se encuentran en el paquete de la biblioteca que es la versión gratuita) EX: android: name = ". MainActivity" => android: name = "com.app.free.MainActivity"
- Ahora compila y tienes una versión pro.
Este método supone que está utilizando un método de validación global. Por ejemplo, creé una clase que conecta a los usuarios con una base de datos alojada en mi dominio que determina cuándo el usuario instaló la aplicación por primera vez. Para las actividades solo profesionales verifico LicenseClass.isValidLicense () que compara fechas y devuelvo verdadero si ha sido menor que el número de días deseado. en la función isValidLicense (), compruebo si Application.IS_PRO se establece en true y devuelve true si es así.
Así que ahora puedes hacer tantos cambios como quieras y todo lo que tienes que hacer es volver a compilar ambos. Lo único que se debe tener en cuenta es que los cambios que realice en el manifiesto com.app.free deben reflejarse en el profesional. Pero este es el caso con cualquier aplicación porque las aplicaciones de Android requieren que usted declare qué actividades va a usar sin importar qué.
NOTA: Puede eliminar todos los recursos y recursos (aunque no elimine la carpeta res en sí) que se generan automáticamente en la creación del proyecto, ya que no se utilizarán. Además, el único archivo de clase que se necesita es el archivo MyApplication del paso 3. Lo que significa que también puede eliminar MainActivity.class que también se genera automáticamente, ya que nunca se usa. También puede eliminar cualquier etiqueta que no se use en la versión Pro. EX: Tengo una actividad de BuyPro que se abre si falla la validación. Dado que la validación nunca fallará en la versión pro, no es necesaria. Por supuesto, todas estas eliminaciones son opcionales y te informan lo que he aprendido.
CONTRAS: La única desventaja que encontré hasta ahora es que no puede usar declaraciones de cambio con sus variables de recursos porque ya no son constantes. Por lo tanto, cuando utiliza un proyecto como biblioteca, cualquier variable que cree en su archivo strings.xml, por ejemplo, se anulará automáticamente si declara una variable del mismo nombre en la versión pro. Para mí esto no es una estafa porque no me gusta usar los estados de conmutación en java porque te limitan a activar solo el tipo int y requieren valores constantes. Lo que significa que en java por lo general tengo para nosotros si ... de lo contrario estaments de todos modos. Además, Eclipse realmente ayudará a convertir las declaraciones de cambio si coloca el cursor en la palabra clave del interruptor y presiona Ctrl + 1 y luego hace clic en convertir a si más. Además, me parece bastante útil que los recursos se anulen porque puede hacer cosas como cambiar app_name de "app free" a "app pro" o cargar un nuevo dibujo para decir el ícono de la aplicación simplemente creando la nueva versión en la ubicación donde existe en la aplicación gratuita. EX: si res / values / string.xml contiene, por ejemplo, 100 variables de cadena, pero todo lo que necesita o desea cambiar en la versión pro es que app_name simplemente recrea la res / values / string.xml (NO copia) y agregue la variable app_name . Ahora se anulará la variable app_name en la versión gratuita, lo que significa que el archivo string.xml en la versión pro solo necesita contener la variable 1 en lugar de 100, ya que es la única variable que cambió. Pan comido. :-)
EDITAR: Descubrí que eclipse no le permite exportar .apk para bibliotecas, por lo que tiene que desmarcar la opción "Biblioteca" en la versión gratuita después de haberla agregado como una biblioteca en la versión pro. Hasta donde puedo decir, lo único que hace esto es que eclipse no le advierta sobre el problema de la instrucción de cambio. Aparte de eso, parece funcionar bien.
Sé que ya ha tomado su decisión, pero tengo otra sugerencia que podría ayudar a otros.
Yo uso git para mi repositorio. Crear y mantener sucursales es muy fácil. Tengo mi repositorio maestro "pro" y una rama "libre". Hago todos los cambios de código en el maestro. Mi rama "gratuita" solo se diferencia por los cambios que activan el comportamiento "libre". Cuando termino de hacer cambios en el código, lo confío a la rama maestra, luego cambio a la rama libre y utilizo el comando "rebase" para alcanzar al maestro.
Revierte el cambio que hace que se comporte como la versión "gratuita", aplica los cambios que hice al maestro y luego vuelve a aplicar los cambios "gratuitos".
No tengo que mantener dos versiones. No tengo que acordarme de cambiar un interruptor, o hacer los mismos cambios de un lado a otro. Es bastante elegante y me gusta más que una segunda aplicación que activa el comportamiento pro porque puedo eliminar bibliotecas que no son necesarias para la versión en cuestión.
Yo sugeriría no mantener dos sucursales, pero tener interruptores de tiempo de ejecución o de compilación para deshabilitar la funcionalidad PRO para la versión gratuita. Incluso podría eliminar archivos DLL no necesarios al construir.
Mantener dos ramas significa solucionar problemas en dos lugares, lo que se convertirá en un problema mayor a medida que las ramas divergen inevitablemente.
Tenga una versión única con public static final boolean IS_PRO
que determine el comportamiento libre / pro.
EDITAR:
El paquete de cosas. Digamos que todas tus clases residen bajo com.myapp.android.free
.
Luego, en AndroidManifest.xml declara package = "com.myapp.android"
para la versión de pago y package="com.myapp.android.free"
para la versión gratuita.
Si usa nombres completos para actividades, servicios, etc., no tendrá que cambiar nada más.
No me molestaría en eliminar las libretas no utilizadas de la versión de pago. Si lo haces, tendrás que hacerlo manualmente.