I recently finished a project where we used an in-app purchase to do the transition. Made it nice for the coders since we only had one code base (in this case we had a separate apk for an HD version with different levels, so it took it from 5 projects down to 3: sd, hd, and core with no need for sd-paid, sd-lite, etc. but this would not be typical, so you'd normally only need one), and nice for the users since their high scores and settings would carry over with no need for any migration. There was some one-time overhead since we had to make a library to manage the in-app purchase, but once done it could be moved into common and reused in other new projects. Adding a back door for debugging was easy since there were already places to do checks. When we decided half way through the project to change from an all or nothing to a pay-per-pack model, very little refactoring was needed. I didn't have to refactor otherwise concrete classes into abstract ones and have it split between projects. Assets and jars didn't have to be copied. I didn't have to ensure I was working in the right "type" of a class. Really the only reasons I can see for not using the in-app purchase model is market visibility (not being in top paid and top free simultaneously, etc.), legacy support (your app was released before in-app purchasing was available and now you need to support the old method), or fear of Lodsys (if this is your reason, then the bad guys win... or something like that).
On Jul 19, 4:21 pm, Adam Ratana <[email protected]> wrote: > I think this is a good question actually, and would like to see anyone > weigh in who has tried a few approaches. Assuming we are talking > about a 1-time purchase type app. > > For example as TreKing has suggested, the majority of your code and > resources can reside in a shared library project, I have done this as > I'm sure many others have, and it's convenient to be able to develop 2 > feature sets and apps based on that library for the paid + free model. > > I am curious what people have experienced now that the in-app billing > is here, if anyone has tried approach 2 below with just 1 app and the > ability to unlock features. I feel this may increase sales because of > the immediacy of it, but then there's also the specter of infringement > letters and cease and desists that lodsys seems to be targeting > developers with - that scares me away a bit. > > On Jul 18, 4:15 pm, androidmediadeveloper <[email protected]> > wrote: > > > > > > > > > We have a free app in the Android market from the last one year which > > has done very well, and are in the initial stages of coming up with a > > paid version of the app with an enhanced feature set. > > > In terms of continuing to support a free app and a paid app (with the > > paid app having all the features of the free app and then some), can > > anyone please advice on approaches you've taken yourself or point me > > to documentation on best practices to use in terms of > > > 1. Code structure (including resources) > > 2. Packaging (One apk with a locked set of features Vs separate apks > > for free and paid) > > > Thanks -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
