android source Création d'une application de démonstration et de version complète basée sur une base de code/projet




programmation android eyrolles pdf (3)

Je vois que l'approche la plus simple serait d'avoir trois projets:

  1. démo
  2. plein
  3. bibliothèque

La démo et les projets complets auront chacun leur propre nom de paquet, tel que défini dans leur fichier manifeste. Leurs activités sont simplement des ports qui envoient des informations dans un regroupement à l'activité principale du projet de bibliothèque. L'activité dans le projet de bibliothèque lira l'ensemble transmis pour les paramètres nécessaires qui déterminent s'il a été lancé par l'activité de démonstration ou l'activité complète. Ensuite, il procédera en conséquence.

Donc la logique est comme ceci:

L'utilisateur lance la démo Activité -> L'activité de démonstration crée un paquet avec les informations indiquant qu'il s'agit de l'activité de démonstration -> L'activité de démonstration lance la bibliothèque Activité qui exécute ensuite le reste du programme en mode démo.

OU

L'utilisateur lance l'activité complète -> L'activité complète crée un paquet avec les informations indiquant qu'il s'agit de l'activité complète -> L'activité complète lance la bibliothèque Activité qui exécute ensuite le reste du programme en mode complet.

J'ai développé une application Android dans un projet avec Eclipse - elle est structurée (provenant de l'iPhone), donc une constante définit si c'est la démo ou la version complète.

Maintenant, j'ai le problème que chaque fois que je veux créer la version de démonstration, j'ai besoin de changer la constante, mais aussi besoin de faire une copie du projet avec un nom de paquet différent.

Il est évident que le changement de code dans la version complète originale doit être copié sur la démo ou que je devrais refaire la création de l'application de démonstration chaque fois que je soumets mon application.

Je vois trois approches possibles:

1. Alors que j'ai examiné les projets de bibliothèque, je ne comprends toujours pas comment cela peut vraiment être une bonne solution dans ce cas.

Par exemple si j'ai la version complète avec une structure d'activité:

A1
A2
A3

en utilisant les classes d'utilité U1, U2

Certes U1 et U2 peuvent être dans un projet de bibliothèque et référencés à partir des deux projets - mais les activités, strings.xml, les graphiques, les mises en page doivent être dupliqués (ou existe-t-il un autre moyen que je ne vois pas?) Cela ne semble pas être un bon moyen d'aller de l'avant et n'a malheureusement pas été expliqué dans des questions similaires sur ce sujet lorsque cette approche a été suggérée.

2. L'autre façon serait de créer des noms de paquets différents basés sur différents paramètres de construction (similaire à l'iPhone), mais cela ne semble pas possible dans Eclipse plutôt que d'utiliser des scripts externes (que - honnêtement - j'évite plutôt depuis il semble plutôt sujet à erreur) alors que la compilation doit être invoquée à l'extérieur d'Eclipse

3. L'approche probablement la plus directe (et aussi actuellement avec un effort moindre) est de simplement copier manuellement le projet, changer la constante, renommer le paquet et compiler / exporter chaque fois que je soumets. Ceci - cependant - semble être plutôt «basique» et n'a certainement pas l'air professionnel (comparé à la solution de construction / cible de construction d'iPhone / xCode)

Quelle serait la meilleure approche (nécessitant un minimum de changements tout en restant stable et facile à utiliser)?

Merci beaucoup!

MODIFIER

Pour tous ceux qui ont essayé la solution de Tim - ça marche bien, mais j'ai rencontré un problème avec les attributs personnalisés.

Cochez cette case: Comment résoudre les attributs personnalisés des bibliothèques Android et le remappage des noms de package au cours de la génération? il va résoudre l'isse pour les bibliothèques


Answer #1

C'est très simple en utilisant build.gradle dans Android Studio. Lisez à propos de productFlavors . C'est une fonctionnalité très utile. Ajoutez simplement les lignes suivantes dans 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'
    }
}

Dans cet exemple, j'ajoute deux variantes de produit: d'abord pour la version allégée et ensuite pour la version complète. Chaque version possède ses propres versionCode et versionName (pour la publication Google Play).

Dans le code, vérifiez simplement BuildConfig.FLAVOR:

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

}

Pour exécuter et tester sur le périphérique, utilisez l'onglet "Variantes de construction" dans Android Studio pour basculer entre les versions:


Answer #2

Je le fais actuellement en éclipse, et ce n'est pas difficile.

  1. Convertir la source existante en projet de bibliothèque.

  2. Créez deux nouveaux projets, gratuits et payants.

  3. Inclure le projet de bibliothèque dans les projets gratuits et payants.

Il n'est pas nécessaire d'avoir une seule activité ou ressource dans les projets gratuits / payés. Tout ce dont vous avez besoin est un manifeste pour chacun qui se réfère aux activités de votre bibliothèque. Mes projets libres et complets n'ont actuellement aucun fichier java, ressource ou layout de quelque sorte que ce soit, c'est juste un manifeste qui référence les activités de la bibliothèque.

J'utilise exactement le même code pour les deux projets, et je les différencie en disant:

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

Quelques pièges que j'ai trouvés, surtout si vous avez déjà sorti votre application sur le marché:

  • Si vous changez le nom complet / le chemin de toute activité, il disparaîtra de votre écran d'accueil. Par conséquent, si votre bibliothèque a un nom de package différent de la version existante, vous perdrez toutes les icônes d'écran d'accueil. Ils peuvent être remplacés par l'utilisateur mais ce n'est pas idéal.
  • Similaire à appwidgets, si vous changez le nom de leur récepteur, ils disparaîtront lors de la mise à niveau.
  • Vous ne pouvez en aucun cas changer le nom du paquet d'une application publiée.

Si vous avez déjà publié une version gratuite et professionnelle, c'est un peu dommage, car le chemin d'accès à l'activité devra changer pour un chemin de bibliothèque commun, et vous ne pouvez pas renommer le paquet libéré pour qu'il corresponde au chemin de la bibliothèque. Donc, quelqu'un devra perdre ses icônes existantes.

Dans mon cas, je n'avais sorti qu'une version gratuite avant de les partager, et j'ai été capable de nommer la bibliothèque avec le même nom de paquet que la version gratuite. J'étais sceptique que vous seriez autorisé à inclure une bibliothèque avec le même nom de package que le package wrapper, mais apparemment, il est possible de le faire (fonctionne bien pour moi).

Donc, dans mon cas, j'ai trois projets:

  • Core Library: nom du package: com.myname.myapp
  • Version gratuite: nom du paquet: com.myname.myapp
  • Version Pro: nom du package: com.myname.myapp.Pro

Et les manifestes de version libre et complète ajoutent des activités nommées com.myname.myapp.ActivityA ou com.myname.myapp.ActivityB , qui existent uniquement dans le projet de bibliothèque.





conditional-compilation