Bob - you should be able to make Pro version look into the Lite's preferences at upgrade time, so you can copy in the settings without using a provider. Incidentally, if you do use a provider it needs to have a different name in the Lite & Pro versions - that's one of the things our Ant script changes in the manifest.
Take a look at Context.createPackageContext(), here: http://groups.google.com/group/android-developers/browse_thread/thread/9d95bdd4a1bf81f0/9926f03b990d31f7?lnk=gst&q=jarkman#9926f03b990d31f7 Richard On Feb 25, 5:05 pm, Bob Kerns <[email protected]> wrote: > While the downloadable license approach sounds good on the face of it, > there are just too many loose ends for my tastes as it stands. We > already have a very limited channel for communicating with our > customers, and I don't want to waste those characters > > What I've done is create a master build script, which takes a project > name, tags it in Subversion, cleans and switches a build working copy > (or does a checkout if needed). > > I then do two exports from that working copy. I run an XSLT script on > the AndroidManifest.xml to handle the differences there, including > changing the package, removing the debuggable='true' flag, removing > ADMOB ID's, etc. Any differences, I handle programmatically. I don't > actually change the code packages, just the references in the manifest > and the manifest's package name. > > Any excess code I'm tentatively planning to remove via Proguard, but I > haven't gotten that far yet. > > In effect, I have three versions -- DEV, FREE, and PRO. DEV is > internal-only. > > I also maintain a change log page I show the users the first time they > run after they update. I'm thinking of generating this page content > from a filtered view of the Subversion log, but for now I'm manually > updating it. It hides any changes they've already seen, based on a > record in the Shared Settings. > > Which is where this all breaks down -- these settings aren't shared > between the different versions. > > Here's my plan for dealing with that: > > 1) Create a content provider for the settings for my app. > > 2) When launching the PRO version the first time, if it detects the > FREE versions, it will suck in the existing settings from the FREE > version. > > 3) When launching the FREE version, if it detects the PRO version, it > will not launch its service, and will take the user to an explanatory > page, with a link to the application management page in the system > settings. > > 3a) I plan to listen for PACKAGE_ADDED, and transfer the settings > there. That looks to me to be the most reliable place. > > 3b) I suppose I should monitor PACKAGE_REMOVED, and if the PRO version > is uninstalled, re-enable the FREE version. I should only need these > in the FREE version, so once a user upgrades there would be no need to > launch the app on each install/uninstall. > > 4) The DEV version will have a couple extra menu items to invoke these > operations manually for testing. > > (For what it's worth, I notice that com.android.voicedialler monitors > PACKAGE_ADDED and PACKAGE_RECEIVED, as do a few others with no other > obvious reason. I wonder if some of them are doing a similar trick?) > > This looks to me to be about the best I can do. Does anybody see any > problems I've missed? Have a better/simpler idea? > > It's really too bad the platform doesn't provide a way for one app to > supersede another, when signed with the same key. This could be > handled much more cleanly at install time. > > On Feb 24, 11:34 pm, String <[email protected]> wrote: > > > On Feb 25, 4:00 am, Carmen Delessio <[email protected]> wrote: > > > > It seems like it should be possible to have 2 apps signed with same > > > certificate. > > > See the info below. If your paid app exposed functionality to your free > > > app > > > you would get the free/paid goal. > > > The free app would check whether paid app was installed, if it was it > > > would > > > be used. If not an upgrade message would be displayed. > > > This is exactly what I do with one of my apps, TerraTime. I call the > > paid app the "license", and it has essentially no functionality of its > > own; it just needs to be present for the full functionality of the > > free app to be unlocked. I have a slightly different marketing > > strategy - my free app has the full feature set, but is just time- > > limited to a trial period. It's that time limit which the license > > unlocks. But the same approach should work for a freemium model like > > yours. > > > The major advantage to this is a single code base. From this > > perspective, it works well. > > > There are a number of small drawbacks that I've found, however. > > Primarily, it causes some confusion for the user... The free app is > > named "TerraTime Trial", but it needs to stay installed when the user > > upgrades. I mostly get around this with clear instructions in all the > > relevant places. This may be less applicable with your strategy; just > > make sure you don't name the free version "Lite" or some such. And > > make VERY clear in the app description that it's a freemium model, or > > you'll get complaints. > > > Overall, it'd be better if the Market supported in-app purchases (like > > certain other App Stores do). But there are so many other, more > > serious problems with the market that this feature is probably - > > hopefully - pretty far down the priority list. > > > A completely different possibility might be to organize your code into > > a single JAR file which you can then include in both application > > packages. While this would let you maintain only a single version of > > your Java source, it wouldn't help you with other code (manifests, > > resources, etc). Also, I've personally never got it to work, but I > > think that's more to do with unfamiliarity with Eclipse & Java outside > > of the usual Android development track. > > > String > > -- 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
