CODEWITHSUNDEEP
androidversionin-app-billing
l33t
l33t

Reputation: 19937

Best approach for Free and Paid versions of Android application?

I have developed an Android app which I want to be available both as free and paid version. What is the best approach?

I can think of three solutions:

  1. Split the project into two branches and maintain both of them.
  2. Create a library project and have two additional projects, one 'Free' and one 'Paid' version.
  3. Use in-app billing.

Q: Which solution is the best? And why?

Some things to consider:

Upvotes: 5

Views: 2581

Answers (3)

Kevin
Kevin

Reputation: 2406

I struggled to actually implement this, but figured it out. I feel the best approach is to use the Android Library feature, and differentiate with an app name string value in each project simple paid=true string value (or key file if you want a more complex solution).

Exact steps:

Library

Use this to get a 'common' copy of code, then multiple android projects that reference it`

Purpose:

Free & Paid version on Google Market

Results:

One Android Project (library) with ALL code, with 2 additional Android Project that reference code, but no actual classes. strings.xml differentiates App names (Paid & Free or whatever)`

Create Library

  • Create new project & during steps to create select option to make library
  • Convert existing: right click project->Properties->Android->Check box next to library.
    • Might want to refactor/rename as well, but not needed

Create new project to utilize library

  • Create new Android Application Project
  • Open properties for this project->Android->Add existing library to project
  • Additional Libraries if exist: Dont copy these (jar) files into new project!
    • Properties of new project->Build Path->Configure Build Path->Libraries Tab->Add Jars->Expand Library you're linking to->libs->Select libary (ie libGoogleAnalytic)->OK->Order & Exports tab->Check new library->ok
  • Manifest of new project: Need to RE call out ALL info from library, especially activities, appending FQDN from library
    • ie: android:name="com.blah.appname.library.MainActivity" (basically copy/paste everything from library manifest to new project manifest & adjust package name to reference library instead)
  • Make sure there aren't any duplicate libraries in new project lib folder vs library project! If so, delete from new project & adjust build path per step above
  • Do not need ANY classes/java files!
  • Replace resources only if you want them replaced
  • Delete all files in new Project in res\drawable\ so we utilize the ones from the library

Upvotes: 4

Bill The Ape
Bill The Ape

Reputation: 3306

Your 3rd approach, In-app billing, provides the most flexibility, but it's horribly complex (and thus error prone).

Your 2nd approach, a shared library project looks like the best compromise.

If you can use the same APK for both free and paid versions this can possibly be the best of both worlds.

Upvotes: 2

stork
stork

Reputation: 420

I'm not a big fan of using ads in apps since unless your market share is already quite big, the money you get is gonna be tiny compared to the amount you will annoy your users.

I prefer a model of writing a basic app with all the core features, then adding extra functionality to a paid app and charging for that (of course using an android library project for sharing the bulk of the code). That way people who use your app and like it can support you by paying for it and then get a bonus of some extra features.

(disclaimer: this post is personal opinion based on my own experience and anecdotal evidence I've heard)

Upvotes: 3

Related Questions