Como manter a versão gratuita / paga do aplicativo separada no subversion

8

Eu tenho um aplicativo pago no Android Market, no entanto, quero lançar uma versão gratuita suportada por anúncios.

A maneira mais fácil de fazer isso foi configurar uma ramificação no meu repositório do subversion que possua o código adicional para adicionar os anúncios. No entanto, quando fui enviar isso ao mercado Android, eles exigem nomes de pacotes exclusivos. Essa solução não funciona mais para mim porque eu teria que alterar o pacote de todos os arquivos de classe, o que tornaria muito doloroso a fusão do tronco e da ramificação.

Qual é a melhor maneira de manter esses dois projetos juntos, compartilhando patches, mas com um pacote diferente?

version-control android svn

— Malfist
fonte

1

Apenas observe que esta questão não está fora de tópico aqui em Programadores. Os principais problemas são sobre a estrutura do projeto e os problemas de gerenciamento de configuração, os quais pertencem aqui (e não no Stack Overflow ou em qualquer outro site).

— Thomas Owens

9

Você já considerou as diretivas do compilador ?

Exemplo:

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

Você pode manter exatamente a mesma base de código e direcionar as duas compilações usando dois scripts de compilação separados ou um parametrável.

msbuild /p:DefineConstants=FREE

Para fazer isso com Java, leia isto e isto . E talvez isso .

— Comunidade
fonte

Eu não acho Java escutado essas coisas

— Malfist

Também existe em Java.

@ Pierre303 Me desculpe, eu não sabia que você poderia fazer isso. Ele ainda não resolve o problema do pacote .... hmmm.

— Michael K

1

@ MichaelK: isso é facilmente possível com uma tarefa bem organizada de localização e substituição em seu script de construção.

Isso também não resolve o problema de recursos condicionais na pasta / res.

— donturner

5

Somente seu pacote de aplicativos deve ser exclusivo. Veja aqui . Esse é o pacote declarado no seu arquivo de manifesto. Você pode ter a maior parte do seu código com.mydomain.myappe apenas ter uma atividade principal diferente com.mydomain.myapp.free.

— Karl Bielefeldt
fonte

3

Se você realmente deseja fazer a separação, a melhor maneira é configurá-la como duas partes do mesmo repositório. Dessa forma, você pode pelo menos mesclar alterações entre os diferentes ramos. Se você quiser manter as coisas completamente separadas, estará executando muitos arquivos de correção esquecidos.

Eu fiz isso e, francamente, não é uma ótima estratégia na prática. Muito melhor, especialmente em ambientes compilados, é ter um processo de compilação separado, gratuito e pago, para que haja uma base de código em vez de duas. Se houver duas bases de código, as coisas irão divergir.

— Wyatt Barnett
fonte

É isso, eu não os quero separados. A única coisa que eu quero é o código adicional que adiciona os anúncios. No entanto, o Android me obriga a ter um nome de pacote exclusivo para o meu aplicativo. Então, eu seria forçado a ter uma alteração maior do que apenas dois ou três arquivos.

— Malfist 18/04

Talvez um pequeno voodo pré-compilador deva funcionar também. Sistemas de construção são coisas impressionantes.

— Wyatt Barnett

0

O controle de versão é uma maneira ruim de gerenciar coisas como esta. Você acabará com um pesadelo de manutenção - dois aplicativos separados que precisam ser quase idênticos.

Você já considerou uma solução de múltiplos projetos? (caveot: na verdade, eu não fiz isso, mas parece viável, e acho que o Android permitirá. Vou tentar mais tarde e ter certeza.) Compile todo o código do seu aplicativo em uma jarra de projeto principal . Em seguida, crie dois aplicativos Android separados, um para a versão paga e outro para a versão gratuita. Isso resolverá o problema de nomeação de pacotes. Esses aplicativos delegam apenas o jar principal para praticamente tudo, exceto que a versão do seu anúncio incluirá o código para dar suporte aos anúncios.

Você também pode achar interessante essa discussão sobre um tópico semelhante .

— Michael K
fonte

O código é uma pequena parte da imagem completa e o JARring não ajuda a lidar com todos os dados adicionais, como recursos, layouts, ativos etc. que o acompanham. O fato de você não poder agrupar tudo perfeitamente é uma falha lamentável no Android, e me dói ter que reprovar coisas que não mudam muito ou que podem ser configuradas de fora.

— Blrfl

Concordo. Eles fizeram um ótimo trabalho ao facilitar a criação de aplicativos pequenos, mas difíceis de criar aplicativos grandes que precisam de manutenção. Existem algumas soluções Maven que parecem promissoras, mas ainda não fui capaz de explorá-las muito.

— 19712 Michael K

0

A criação de seu aplicativo usando a feature togglepermite atingir seu objetivo, mas pode ser necessário refazer muito código.

Ao definir 2 (eu recomendaria 3) o ambiente de contêiner de recursos em um arquivo .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

Dessa forma, você possui uma versão uniforme e requer apenas uma ramificação na fonte de controle de versão

Em seus scripts específicos, é necessário verificar se o recurso está autorizado; caso contrário, você não o exibe.

— JF Dion
fonte