How do you make a time limited trial version, where limiting the time is fairly fool-proof? How do you know how long the user has your app installed (including the possibility that the app has been uninstalled one or more times...)?
Thanks! On Feb 25, 2:34 am, 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
