This question already has answers here:
Best way to have paid and free version of an Android app [closed]
(9 answers)
Closed 9 years ago.
I am building an android application and I want to split it into two versions, Pro and Free.
The pro app will be the complete ad-free, and the free will be limited and with ads.
The base of the business logic of the two apps will be the same... So I don't think that is correct to "write the code" twice.
Handling same code in two projects can be very annoying for bug fixing and code improvements.
Is there any way to do it with one project?
Shared-preference for example is not good solution for this because many people have root access so they can change it very easily.
Firstly Hello,
As far as I've heard or seen, two versions of the same app (Free and Pro) should be two distinct projects. You could, but should NOT, use the same app and just check for a flag saved in the Prefs, but root users can override that (as you already stated).
You could also use Google's in App purchase to verify this as the other answer states. In my opinion you should not use the same project and check for a flag because it's bound to create some overhead, especially if you check using the Internet. If the user has a slow or unreliable network connection his experience will suffer.
The "clean" way to do it is to make two distinct apps like everyone else does: users can install the free app, or the pro app. This is ideal because you have two distinct options for users and if they want the pro version they don't need to get the free one and then see the option unlock in the menu. It's just way more straightforward for users.
I recommend you build the pro app first and after it is completed derive the free version by restricting functionality and including adds because it's easier to strip it down than to add-in. After you finish the pro version, just click on:
File -> New -> Project (pop up menu appears) -> select Android folder -> select "Android Project from Existing Code" -> select your App and click Finish
The drawback is that if you spot a bug you must fix it in both projects. If you want to optimize finding bugs, you could build the free version, put it on the market and fix the bugs reported by the end-users as well as the ones you spot. After you consider everything to be fine, you can create the pro version from the existing code and carry on with that.
ps: I realize I filled this whole page, but this is my first answer here and it seems I'm overenthusiastic :-)
How about using Google's in App purchase? This way the Google server manages the PRO/Trial detail. The only con is that your app needs to have internet access for validation purpose :)
I'm sorry if this solution seems a bit raw, but...
Why not have a hard-coded flag in your code... some static variable in some class saying something like:
public static final boolean isFreeVersion = true/false;
Then, in any place where you want to decide whether or not to show adds, simply reference this boolean.
You'll still need to build your app twice and publish it to the store twice (under different app signatures), once with the boolean as true, and once as false. But at least the code base will be the same. This way, if you find a bug, you can fix it, and just publish the same app twice with only switching the boolean value.
I'm pretty sure you could even find an ant script to change the value of the boolean for you during a build.
Related
I'm trying to install Kik Messenger twice. I have two accounts and don't like to log out because I lose all of my conversation history. I'm currently using Titanium backup's profile feature, which is a very nice fix, but it's still a pain having to switch back and forth between profiles. I might be looking for "perfect" when perfect doesn't exist. I am completely new to modding apks and Android in general, all of my work on this so far has been "trial and error". Anyways, here's what I have:
I have the Google Play version of Kik installed on my phone. I have extracted that app and modified the package name successfully using apktool. However, when I try to install, I get an error saying something about duplicate provider authority. So I did some research and learned that I'm supposed to edit this part of the AndroidManifest. So I have played around with that a little bit and after I change the authorities, I am able to install the modded app. However, it crashes immediately.
Does anyone know how to fix this problem with the provider/authorities?
The issue you're hitting is that the app has registered certain classes to handle particular events. These need to be unique across all installed apps and point to existing classes in the app that will perform some activity with the supplied information.
You bypassed the safety check when installing by changing the defined handlers in the Manifest but that didn't really fix it as they still need to actually point to a valid, working class that can handle the requests/events.
You would need to decompile, rename the classes involved and all references made to them and recompile the whole app to really fix the problem. However, I'd assume that it would likely be against the license. If the code is open source then it wouldn't be too big a task to rename some classes & packages then build the app. If it's closed source then it is a harder task.
What you can do is either set up your device to use multiple accounts (the OS not the app) as each user has a separate data storage and preference location that should allow you to have two configurations. Or you can request that the developers include some sort of multiple account handling or easy account swap feature.
So I have managed to get a couple apps up on the marketplace only to have a stray thought of what is the best way to go about managing my projects/apps within eclipse to accommodate future updates to the marketplace. My question resides within Eclipse and what to do with my projects/apps as I apply updates.
Do I simply copy my project/app, paste it and the increment the version information accordingly? Or am I continuously working on my published project/app? Or...Is there a recommended/preferred method of going about this. Since they are up and good on the marketplace I am leery of doing something that will cause problems for me later on down the line.
And don't change the package name....correct?
This is what I currently have on the Marketplace...
Wind Chill Calculator
True Love Game
First of all, everyone's posts were very helpful and I have spent some time looking over documentation through the links provided.
So...and brace for impact as I say this. Being one who has NEVER used any form of SCM for my projects this is all new to me (as everyone's faces cringe), which is why I am asking the original question in the first place. I hate to say tell me anything without doing my research...so within the past few hours using git within eclipse I have gleamed the following:
Team > Share Project ...ignores...any tags(for version info)which is what I am after...commits...THEN
Clone? File -> Import -> Git -> Git Repository at this point once I have cloned my project do I create a new tag with the new version info, and go through the commit process again? If this is the case I now have two items in my Git Repository. One of which has the single tag of 1.0, and the other item which contains two tags 1.0 and 1.1, and when I look at the history I see two tags Version 1.0 and Version 1.1. Then I just switch between the resources I need from within the repository?
I just want to make sure my process is correct before I begin to implement some of this on existing projects that are pretty extensive already. As for the rest I am just going to learn on the fly...branches
You might want to use a revision control system like SVN or git or one of dozens of other options, and continuously update the single project in Eclipse. The benefit of using source control is that you can branch into a new project for major changes, update your existing code for minor changes, and tag the branches so you can revert back to an old snapshot in the future.
I personally use bitbucket which is hosted remotely and is free. It supports SVN and Mercurial.
No, dont change the package name, that will make it new app, instead of upgrade of original.
Use a version control system, like SVN.
Manage Tags for a complete working state of code(through svn), so you can always revert back to that tag.
When ready for new release, increment version no. etc and update on market...
EDIT After addition in question:
Don't get much confused with various GIT/SVN working.. There main purpose is that they will allow you to switch your code back and forth to any point in past, that allows you to code in a way properly knowing that you can always revert back to a Working state.. and it is definitely of much more benefit in a Team , when multiple people are working on same codebase and possibly same files...
Being a long-time user of SVN, I recommend subclipse (svn for eclipse). When you're ready to release another version of your app, create a 'tag' for the release version and you'll always be able to go back to that exact version.
SVN has excellent docs. There is also TortoiseSVN for repo work outside of eclipse.
I want to have two versions of my program, but how would I have the basic activities be either disabled or not respond to intents, so the more advanced one can do it?
Basically, I want the user to download the basic one, then, if they get the advanced version then it will use the new activities.
UPDATE:
After writing a long comment to one answer I thought I would put it here, perhaps more clearly.
Ideally it would be nice to have more Activities that other programs could use, so, for example, if there was a program that usees the Twitter API that was being used to allow games to be played, then, there could be a version of the application that allows some advanced functionality, so, by upgrading the application all the games using it would also get the new options, so work better.
It may be as simple as having three versions of the program.
Basic version.
Plus version to upgrade from basic
version.
Initial install of the plus version.
I would still have a problem with (2), and I can't just have it upgrade the jar file since most of the code between version (1) and (3) would be the same, but the Activity that may change could look to see if there is a better version, and either do nothing, or pass the Intent on to the new Activity. If it did nothing, then it would assume the plus version would also pick up on the Intent and handle it.
This may be a stretch but... could your basic app, upon receiving an intent, check to see if there is an instance of the advanced app installed via getInstalledApplications() from the PackageManager and if it is installed, send a custom intent to launch the advanced app?
So, I have found a bug in a specific sdk that causes it to fail on some Android phones after re-installing a new version of an app which uses the sdk (via adb install -r, and presumably when a user gets an update that has been pushed to the Android market). Is there any way to force an application's data to automatically be cleared upon update of the app? I realize there are different ways that data could be stored, but I just need to essentially simulate an invocation of the "Clear Data" button that'd you find when browsing to the application in the "Manage Applications" section of the Settings (i.e. I just want all data gone).
I am an Android noob and am doing minimal Java coding on this project, so I am basically looking for the simplest solution here. I suppose I could settle on storing a "currentVersion" to disk and then checking it upon launch every time to see if the real current version matches the version that was written to disk on the last launch. Is that the only real way to do this? If so, what's the simplest way to do so?
Thanks!
Is there any way to force an application's data to automatically be cleared upon update of the app?
No, at least for my definition of "automatic".
I suppose I could settle on storing a "currentVersion" to disk and then checking it upon launch every time to see if the real current version matches the version that was written to disk on the last launch. Is that the only real way to do this?
I'd name it lastKnownVersion, but otherwise this approach seems sound and probably is your only viable option.
If so, what's the simplest way to do so?
Ummm...do exactly what you said. Use Java I/O (storing the file somewhere inside of getFilesDir()), or SharedPreferences.
Bear in mind, though, that your users may get rather frustrated if you blow away their data on an app update. Personally, I'd rather we find a better solution to your original problem ("I have found a bug in a specific sdk that causes it to fail on some Android phones after re-installing a new version of an app which uses the sdk").
I want to create a PRO version of my application for Android and was wondering how to structure my repository.
For know I have a trunk and feature branches. I'd like to put a pro version in another branch but maybe there is a better way? For example, maybe I should create two branches - one for free version, the other for pro?
Pro version will have additional features and will be ads-free, so eg. I don't want to include AdMob libraries in the pro version.
Do you have any experience or suggestions as to what would be the best way to structure the repository in this case?
EDIT:
I think I've found the best solution (for my app) in this thread: http://groups.google.com/group/android-developers/browse_thread/thread/4ad3d67f735f16d7/948b4f9eee2490a3
The trick discussed there is about having another application that only serves the purpose of unlocking PRO functionality in the actual application. The unlocking app is paid in the market and the actual app merely checks for the existence of it on the device.
I know you have already made your decision, but I have another suggestion that might help others.
I use git for my repository. Creating and maintaining branches is very easy. I have my master "pro" repository, and a "free" branch. I make all code changes to the master. My "free" branch only differs by whatever changes trigger the "free" behavior.
Whenever I'm done making changes to the code, I commit it to the master branch, then switch over to the free branch and use the "rebase" command to catch it up with the master.
It rolls back the change that makes it behave as the "free" version, applies the changes I made to master, then re-applies the "free" changes.
I don't have to maintain two versions. I don't have to remember to toggle some switch, or make the same changes back and forth. It's pretty slick, and I like it better than a second app that triggers the pro behavior because I can strip out libraries that aren't needed for the version in question.
I would suggest not maintaining two branches, but have either runtime or compile time switches to disable the PRO functionality for the free version. You could even remove not required DLL's when building.
Maintaining two branches means fixing problems in two places, which will become more of a problem as the branches inevitably diverge.
I found an easy way to do this in eclipse. I was quite surprised at how easy it was once I discovered it.
In project properties for com.app.free check the "Is Library" as true (you must have compiled the project at least once before changing this otherwise you get an error saying that library projects cannot be compiled, if you do get this error simply un-check it, compile, then re-check.
create new project com.app.pro
add com.app.free project as a library in the project settings in the android section of the pro porject
create new class MyApplication in com.app.pro and extend Application
override onCreate() NOTE: For those fellow copy/paste'ers this is NOT the same as the onCreate(Bundle savedInstanceState) bundle of an activity. You must remove the Bundle argument as this is an application not an activity.
Then add or set the static variable which will be read in the validation method to validate license. EX: IS_PRO = true; then validation method reads variable and returns true if IS_PRO is true.
Copy manifest contents form com.app.free to com.app.pro
add android:name="MyApplication " to the application tag in the com.app.pro manifest
append com.app.free in front of name attribute for all activities. (this makes the application know that your activities are to be found in the library package which is the free version) EX: android:name=".MainActivity" => android:name="com.app.free.MainActivity"
Now compile and you have a pro version
This method assumes you are using a global validation method. For example I created a class that connects users to a DB hosted on my domain which determines when the user first installed the app. For any pro only activities I check LicenseClass.isValidLicense() which compares dates and return true if its been less than the desired number of days. in the isValidLicense() function I check if Application.IS_PRO is set to true and return true if it is.
So now you can make as many changes however often and all you have to do is recompile both. The only thing to keep in mind is what ever changes you make in the com.app.free manifest have to be reflected in the pro. But this is the case with any application because android apps require you to declare which activities you are going to use no matter what.
NOTE: You may delete all assets and resources(dont't delete the res folder itself though) that are auto generated at project creation as they will not be used. Also, the only class file needed is the MyApplication file from step 3. Which means you may also delete the MainActivity.class that is auto generated as well since it is also never used. You may also remove any tags that are not used in the used in the pro version. EX: I have a BuyPro activity which opens if validation fails. Since validation will never fail in pro version it is not required. Of course all these deletions are optional just letting you know what I've learned.
CONS: The only con I found so far is that you can't use switch statements with your resource variables because they are no longer constants. So when you use a project as a library any variable you create in your strings.xml file for example are automatically overridden if you declare a variable of the same name in the pro version. For me this is not a con because I don't like using switch states in java because they limit you to switching on int type only and they require constant values. Which means in java I usually have to us if ... else staments anyway. Plus Eclipse will actually help convert switch statements if you put your cursor on the switch key word and press Ctrl+1 then click convert to if else. Also, I find it pretty useful that the resources are overridden because you can do things like change app_name from "app free" to "app pro" or upload a new drawable for say the app icon simply by creating the new version in the location where it exists in the free app. EX: if the res/values/string.xml contains say 100 string variables but all you need or want to change in the pro version is the app_name simply recreate the res/values/string.xml (NOT copy) and add the app_name variable. Now the app_name variable in the free version will be overridden which means the string.xml file in the pro version only needs to contain the 1 variable instead of 100 since its the only variable that changed. Easy Peasy. :-)
EDIT: I found out eclipse doesn't let yo export .apk's for libraries so you have to un-check the "Is Library" option in the free version after you've added it as a library in the pro version. As far as I can tell the only thing this does is causes eclipse not to warn you about the switch statement issue. Other than that it seems to work just fine.
Have a single version with public static final boolean IS_PRO that would determine free/pro behavior.
EDIT:
The package thing. Say, all your classes reside under com.myapp.android.free.
Then, in AndroidManifest.xml you declare package="com.myapp.android" for the paid version and package="com.myapp.android.free" for the free one.
If you use full names for activities, services, etc., you won't have to change anything else.
I wouldn't bother removing unused libs from the paid version. If you do, you'll have to do this manually.