J'ai déjà une application gratuite sur l'Android Market, mais je souhaite ajouter une version payante avec de meilleures fonctionnalités. Je ne peux pas télécharger la même chose avec certaines constantes modifiées pour déverrouiller ces fonctionnalités, car le Market me dit que j'ai déjà une application portant ce nom de package sur le marché.
Quel est le moyen le plus propre de le faire?
Le SDK Android officiellement traite de la question du partage ou de la base de code commune avec quelque chose qui s'appelle un projet de bibliothèque.
http://developer.android.com/tools/projects/index.html
En gros, le code partagé est défini comme un projet de bibliothèque, puis payante et une version gratuite sont tout simplement deux projets différents dans votre eclipse workbench, à la fois le référencement susmentionnés projet de bibliothèque.
Au moment de la construction, le projet de bibliothèque est fusionné avec l'une de vos rejets, qui est ce que vous voulez.
Le SDK Android exemple de code source contient un projet appelé TicTacToe qui vous aideront à vous familiariser avec les projets de la bibliothèque de l'utilisation.
Bonne chance.
Daniel
Plusieurs approches existent, mais on ne voit pas souvent les inconvénients jusqu'à ce que vous les essayer pour vous-même. Voici mon expérience:
Unlocker app. C'est très facile à mettre en œuvre, de créer une nouvelle application qui agit comme une licence: l'original de votre application doit vérifier si le unlocker application de la signature correspond à celle de votre application (si oui, le logiciel est disponible sur l'appareil, sinon aucune); votre unlocker devrait demander le téléchargement de votre application gratuite si il n'est pas installé, sinon, démarrez-le et enlevez son icône de lancement.
Avantages: facile à mettre en œuvre et il y a une seule base de code à maintenir.
Inconvénients: il est dit que les utilisateurs sont parfois confondus par ce modèle, ils ne comprennent tout simplement pas pourquoi ils ont deux icônes du lanceur, ou qu'ont-ils juste téléchargé. La suppression d'une icône de lancement est lourd, les changements ne sont visibles que si l'appareil est redémarré. Aussi, il semble que vous ne serez pas en mesure d'utiliser Google licence de l'API (LVL), parce que votre application gratuite ne peut pas faire de demandes de licences au nom de votre unlocker app. Aucune solution de contournement pour ce dernier conduit à une mauvaise expérience utilisateur.
L'achat In-app. C'est facile à mettre en œuvre si vous avez PEI, dans votre code, de toute façon, sinon, il va prendre un certain temps pour bien faire les choses.
Avantages: il y a une seule base de code à maintenir et à l'achat de débit pour l'utilisateur est très pratique.
Inconvénients: les utilisateurs sont dit être inquiète de savoir si son achat est "persisent', ce qui signifie qu'ils sont confus, qu'ils peuvent toujours utiliser les fonctionnalités de la version pro si, plus tard installé l'application sur un autre appareil ou de le réinstallé.
Les versions gratuites et payantes avec la bibliothèque partagée du projet. Cela ne devrait pas être une chose difficile à code et semble comme une décision logique d'avoir une seule base de code contenant la plupart de votre application de la logique et de ne maintenir que les différences.
Pour: les utilisateurs sont de moins confus avec ce modèle, mais ils sont sans doute inquiète de savoir si leurs préférences seront perdus si ils commencent à utiliser la version payante.
Inconvénients: Java/Eclipse dans mon expérience n'est pas vraiment sympathique quand il s'agit de bibliothèques. Il faudra un certain temps pour mettre en place les projets correctement, mais il sera toujours confus comment le tout fonctionne, que mettre dans ce qui se manifeste, ce qui se passe avec les ressources, etc. Vous ferez face à des problèmes de génération à mal des projets, créer des problèmes avec des ressources n'est pas trouvé (projet de bibliothèque ne sera pas "voir" déjà référencé de ressources, de sorte que vous aurez à modifier les références d'un-à-un). En outre, les fichiers de ressources ne sont pas pris en charge dans ce modèle, ce qui signifie que vous aurez à faire quelques trucs avec faire un lien symbolique, la copie ou l'autre magie, ce sera juste ajouter à la terrible gâchis votre "seule base de code" projet est déjà devenu. Et lorsque votre projet enfin bâtit vous avez juste à garder les doigts croisés pour que le tout fonctionne comme prévu, être préparé pour les images manquantes et les erreurs masquées à chercher. Et bien sûr, vous aurez besoin de fournir à vos utilisateurs un moyen pratique de la migration de leurs préférences dans la version payante lors de la première de lancement.
Les versions gratuites et payantes avec distinct des bases de codes et de contrôle de source. À première vue, cela semble également une bonne idée car un décent système de contrôle de source de soulever le poids sur vos épaules, mais...
Avantages:les mêmes que 3.
Inconvénients: vous serez maintaning deux bases de code et rien d'autre, mais une fusion/de la ramification de l'enfer, qui est attendue d'ici. Package de l'application des noms différents, de sorte que vous aurez probablement besoin de différencier chaque fichier que vous avez, pour garder les choses propres. Et bien sûr, vous aurez besoin de fournir à vos utilisateurs un moyen pratique de la migration de leurs préférences dans la version payante lors de la première de lancement.
Les versions gratuites et payantes avec un script qui tire l'un de l'autre. Il sonne comme un sale hack à réaliser, mais vous savez ce qu'il travaille.
Avantages:les mêmes que 3, plus vous seulement de maintenir une seule base de code.
Inconvénients: la création de scripts prend un peu de temps (assurez-vous de renommer des dossiers, remplacez paquet, l'application et les noms de projet) et vous devrez être prudent de mettre à jour vos scripts de temps en temps si nécessaire (ce qui n'arrivera pas si il n'y a pas trop de différences entre la gratuite et la version payante). Et bien sûr, vous aurez besoin de fournir à vos utilisateurs un moyen pratique de la migration de leurs préférences dans la version payante lors de la première de lancement.
Aucune solution n'est parfaite, mais le ci-dessus peut espérer de vous diriger dans la bonne direction si vous êtes sur le point de commencer à mettre en œuvre l'une des possibilités.
Un code source de deux applications (Eclipse)
Il y a un problème récurrent de la gestion d'une application avec les deux formes de présentation sur le marché, avec peut-être un tout petit peu de différence entre les deux ( paidFor = true; ) Peut-être que l'icône est différente aussi.
Cette approche utilise la description de noms de Package expliqué par Mihai à http://blog.javia.org/android-package-name/ qui souligne la distinction entre le nom du paquet utilisé pour gérer le code source et le nom de paquet utilisé pour publier le fichier apk sur Android Market. Dans cet exemple, les deux publié les noms de package: com.acme.superprogram et com.acme.superprogrampaid, le code source Java nom du package est com.acme.superprogram.
Dans le manifeste, les Activités sont répertoriées et nommé comme .ActivityName. Mike Wallace l'a souligné dans sa présentation récente que la précédente point est important et il peut être remplacé par un package complet. Par exemple "com.acme.superprogram.DialogManager" peut remplacer ".DialogManager" dans le manifest.xml texte.
L'étape 1 consiste à remplacer l'ensemble de l'activité android:les entrées de nom avec ces package complet de noms, en utilisant le code source java, gestion de nom de paquet (com.acme.superprogram).
Puis le Manifeste nom de Package peut être changé...
Dans Eclipse, ce qui oblige à recompiler et une nouvelle R.java est créé dans le dossier. C'est là que ça devient un peu délicat; il y a deux dossiers com.acme.superprogram et com.acme.superprogrampaid, un seul a un R.java. Il suffit de copier le R.java dans l'autre dossier, de sorte que le programme peut résoudre le R. layout.xyz éléments.
Lorsque vous modifiez le paquet dans l'
Je l'ai essayé sur un couple d'applications. J'ai à la fois exécuté sur l'émulateur, mon 2.1 téléphone et ils sont tous les deux sur l'Android Market.
J'ai eu le même problème, que j'ai réglé sur est de faire deux applications android, l'une appelée my_epic_app_free, et de l'autre my_epic_app_paid. Ce que je voudrais faire est de seulement apporter des modifications à la version payante, puis-je avoir une console java du programme, tout ce qu'il fait est d'accéder à tous les .java fichiers directement depuis le disque dur, de les copier dans la mémoire, du violon avec les noms de package et de manifester des lignes, puis de les coller directement dans l'app gratuite". J'ai cela sur un bouton poussoir sur le bureau de sorte que lorsque j'ai terminé le développement sur la version payante, j'appuie sur le bouton, puis de compiler la version gratuite. J'ai à la fois l'application payante et gratuite app communiquer à l'eachother, l'utilisateur peut même installer les deux d'entre eux, et la version gratuite voit le payé, et se déverrouille à la version payante.
Une autre idée est de rendre l'application payante juste une bare bone programme qui contient un fichier de clés. L'application payante, si elle est exécutée, exécutera automatiquement la version gratuite et la version gratuite se comporte comme la version payante.
L'application gratuite vérifie la présence de l'application payante du fichier de la clé, et si elle existe, alors il serait déverrouiller l'application gratuite. Cela empêche la duplication de code. Les noms doivent encore être différents, mais, idéalement, l'application payante n'aurait pas besoin d'être changé souvent.
Avantage: Pas de données de l'utilisateur/paramètres sont perdus lors de la "mise à niveau" à la version payante.
Inconvénient: Si l'utilisateur installe la version payante d'abord, ils devront être adressées à installer la version gratuite qui ne sert à rien, pourquoi ont-ils pour installer deux applications pour la version payante?
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
