What is the best practice for unlocking app features to the user in Android? [closed]
Asked Answered
S

3

6

I just developed an Android App which I´d like to distribute for free.

In order to be able to earn some money for my work, I´d like to add some adverts or notification to the app. If a user decides to donate some money, he will receive an unlock code for the "donate" version using some kind of unlock code.

Is there any "best practice" for implementing this in Android?

Shreveport answered 23/11, 2011 at 18:22 Comment(0)
L
8

Yes, there is. It's in-app billing.

After reading the link above, you'll understand that you can implement various packages that will provide, each, the desired functionality. In your case, you will have "donation products" (packages) that the user will buy. Some of the details that need to be addressed here, IMHO:

  1. Most simple apps are $1, $2, $5, $10 and $20, but you can provide higher values as well, of course. Comparing to the multiple-app pattern, this has the advantage of simplified code logic, since you manage everything inside one code branch, and there is no need to fiddle with different applications.

  2. Since you're providing donation packages, it's logical that the user can donate that given quantity more than once. Thus, you should just make sure that the donation package --- the product you add in the Market console --- is unmanaged.

That's the general concept together with the two main concerns about your particular case.

In-app billing is very simple to implement.

Lientery answered 23/11, 2011 at 18:30 Comment(1)
Personally, I would implement various "donate" packages, with different amounts of money that feels reasonable to your target audience. Most simple apps are $1, $2, $5, $10 and $20, but the sky is the limit. This has the advantage of simplified code logic, since you manage everything inside one code branch, and there is no need to fiddle with different applications. You don't need to provide two separate apps in the Market and all that. Finally, you can't use on 1.5, but I doubt anyone would worry about that. 1.5 is fading, and if you really need it, provide a separate package for that API.Lientery
L
7

I have used this approach:

  • I release my free android app called "My App"
  • I release an empty paid app called "MyApp Donate" (it will have just an activity with some text like "thank you for donating...bla bla")

Let's assume that in "My App" you will show ads, you can have somewhere a button "Remove Ads by donating" which takes the user to the market page for "My App Donate".

In My App you decide if you have to show or not an ad based on the fact that the package "My App Donate" is installed or not.

It sounds complicated, but it's super easy to implement. You can check if a package is installed with the following code:

public static boolean isPackageInstalled (final Context ctx, final String packageName) {
    boolean result = false;
    try {           
        final PackageManager pm = ctx.getPackageManager();
        final PackageInfo pi = pm.getPackageInfo(packageName, 0);
        if (pi != null && pi.applicationInfo.enabled)
            result = true;
    }
    catch (final Throwable e) {
        if (Dbg.IS_DEBUG) Dbg.debug("Package not installed: "+packageName);
    }

    return result;
}

ps. in-app billing is not so easy to integrate, moreover your app will be visible ONLY in the countries where in-app is supported. it's not worth it in your case.

Llamas answered 23/11, 2011 at 18:34 Comment(11)
So you're not checking anything more than that? That means that anyone could create an application with that package name, install it on their device and the ads would be removed... Granted they couldn't distribute it on the Android Market, but other than that. I guess it's not unreasonable to ignore this scenario though. People who are that determined to get rid of ads could just use an ad blocker.Mosa
Well, first, as you said, it can't be distributed and second, do you think that the avg user will develop an app for not seeing your ads? Or do they know how to install an apk without going through the market?Llamas
This has huge security issues and can be unreliable. Anyone who knows how to compile a hello-world app can spoof this method. This method was used before the in-app billing appeared, and even then people would implement some kind of communication and verification between the two apps. Just asking if a package is installed is asking for problems. Also, it gives you managing issues (overhead, more code repos to handle etc.). It's just not viable today when you have better ,more secure and more abstracted ways of implementing the same thing.Lientery
I agree David, it's not the best way to do it but on the other hand you have to deal with in-app billing integration which also limit the visibility of your app to a subset of countries and also make your base code much more complicated. In-app billing is great, I use it in my app but it has to be used when it makes sense.Llamas
1) Country restriction is the same as in paid apps, IIRC. See google.com/support/androidmarket/developer/bin/… . 2) if you are in a non-supported country, you can't sell stuff in the Market, period. See new terms that we accepted this week. 3) your base code can be lighter, but the whole code needed (base + second app) will be bigger, trust me. I follow this since the days we used this method. 4) you have twice as many apps to maintain in the market, twice as many comment/review stuff to pay attention to, twice as many sell reports to maintain and separate.Lientery
5) This package stuff was one of the reasons why Google provided in-app billing together with obfuscation, because people were doing unsecure stuff like this. 6) Finally, I agree with you that it's not a panacea, but this guy asked for a "best practice" answer, and unless you have very specific reasons (1.5 is probably the most relevant one) to not use in-app billing, you should stick to in-app billing.Lientery
7) easy is subjective. In my opinion, rewriting your own code logic to check for this isn't needed unless you have very specific reasons. use API stuff whenever you can, whenever you need, if possible. And when you have problems, people on the internet will be much more capable and willing to help you when you use standards than when you ask them to understand your own custom library. And this is all just what I can think on the top of my head. Regards!Lientery
Ops, the system is complaining about the discussion, it is too long, guess we can continue in private...Llamas
This system complains about everything. :-P Anyway, I'm sorry, but I'm extremely busy right now. I posted here without thinking it would create a lot of interesting points of view to discuss.Lientery
let us continue this discussion in chatLlamas
I think this approach can be made more secure by checking app installer (Google Play, Amazon... etc).Airglow
P
3

You can do this through the Android Marketplace with in-app billing. There are also a lot of apps that offer a free version and a paid version, where the paid version has more features or fewer ads.

Purism answered 23/11, 2011 at 18:32 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.