03-03-2012 01:38 AM
I have a PlayBook app that I want to distribute using Try & Buy. As I understand it, I am responsible for creating the logic that expires the application X days after installation. I need to do this so that the user is not able to continually uninstall and reinstall the app in order to extend the trial period. From my research it looks like phone apps have the ability to store the initial install date in "persistent" storage that will not be deleted on an uninstall. Does the PlayBook have this type of storage? I am familiar with the PlayBooks file structure so I know that I could put a file in the shared files area but this would be easy for the user to find and delete.
Does anyone have any recommendations for a good way to expire a PlayBook application in a manner that prevents uninstall/reinstall in order to prevent circumventing the trail period?
Thank you for any suggestions
Solved! Go to Solution.
03-03-2012 02:14 AM
03-03-2012 11:49 AM
This is one of the reasons I put Playbook development on hold.
I don't know which API you're working with but on Android you can't even get the PIN.
On top of that, it's pretty easy for someone to hack webworks, android, or air.
A server side solution is possible but it's a PITA and if you want the app to run when there is no network it gets complicated. Plus you gotta handle device switches yourself unless you can tie that in with dynamic licensing.
I'm missing the Java smartphone OS already.
03-03-2012 12:26 PM
03-03-2012 01:08 PM
Thank you for your responses. That is what I was afraid of. I am also very concerned about the stability of Try & Buy. Looking at all the problems reported with it on this forum scares me that users will end up getting the a trial version again if they have already purchased and then I publish an update to the original Try & Buy pair.
I posted this related question earlier: I am wondering if Free/ Static and then an In-App purchase is a better way to implement the Try & Buy? I think I read that the PlayBook DOES have the API to read the in-app purchase license keys.
03-03-2012 01:22 PM - edited 03-03-2012 01:58 PM
I don't know what the Android player supports for Payment (possibly nothing), but I believe all three other environments support Payment now. It does let you read information about the in-app purchases although I don't recall the term "license key" being clearly mentioned in the API docs. Easy to find out if you need it.
I'm not sure how that would solve the "problem" with people uninstalling the app and reinstalling it, however. There's still no mechanism you could use there to record state that persists through the uninstall/reinstall sequence.
I would say also though it may well be the better approach "structurally", you may not be happy with some of the side effects resulting from how App World works. Specifically I think your app would be considered "Free" and listed with the Free apps, which may mean you end up much lower in the lists since while you may get lots of installs, you may get few purchases and thus few good reviews.
I can't advise other than to say that based on my understanding you could do a Try/Buy mechanism effectively there aside from the uninstall/reinstall thing.
Personally, I think I'd simply limit my Trial version to have certain core features disabled and therefore ineffective. For a couple of bucks, if the Trial just gives people a general feel for the product, and they're truly potential customers, they'll just say "hmm... looks not bad" and pay the $2 or whatever...
(Edited: to add missing word "could" in second last paragraph.)
03-03-2012 02:02 PM
Thanks for your help Peter! Limiting functionality is perfect way to deal with the uninstall/reinstall. If I could ask one more thing....
I see reported problems with Try and Buy where:
The user does the buy
The developer releases a product update (e.g. bug fixes)
The user allows the update and ends up with the Trial of the update
Is this fixed in App World?? It would wreck all good will for an app.
I assume that when I upload a product update for bug fixes I upload both "binaries" (.bars) again, 1 for the updated trail, and 1 for the updated full product.
Am I correct in this assumption?
03-03-2012 02:06 PM
03-03-2012 02:30 PM
I don't see why the user couldn't re-register the app again even if they end up with an updated trial. It's not ideal but it's not a total failure.
Limited functionality sounds like a good approach, perhaps the best choice considering the current limitations.
Another option would be to have a very short trial period. This would work well if the app requires a lot of configuration or saves a lot of data as the user would get tired of unistalling/reinstalling and then reconfiguring.
03-03-2012 02:47 PM