Thank you for visiting the BlackBerry Support Community Forums.
BlackBerry will be closing the BlackBerry Support Community Forums Device Forums on April 1st (Developers, see below)
BlackBerry remains committed to providing excellent customer support to our customers. We are delighted to direct you to the CrackBerry Forums, a well-established and thorough support channel, for continued BlackBerry support. Please visit http://forums.crackberry.com or http://crackberry.com/ask. You can also continue to visit BlackBerry Support or the BlackBerry Knowledge Base for official support options available for your BlackBerry Smartphone.
"When we launched CrackBerry.com 10 years ago, we set out to make it a fun and useful destination where BlackBerry Smartphone owners could share their excitement and learn to unleash the full potential of their BlackBerry. A decade later, the CrackBerry community is as active and passionate as ever and I know our knowledgeable members and volunteers will be excited to welcome and assist more BlackBerry owners with their questions."
- Kevin Michaluk, Founder, CrackBerry.com
Developers, for more information about the BlackBerry Developer Community please review Join the Conversation on the BlackBerry Developer Community Forums found on Inside BlackBerry.
02-17-2011 12:27 PM
I haven't been able to figure out yet how one would implement a timed trial feature for PlayBook apps.
Using features already available in App World, one could upload two versions of an app, one marked as the "free trial" and the other as the full paid version. Users can download the one, play, then "upgrade" to the full one by just buying it as they would any app.
But how would you implement a timed trial, where the user has free access to the full functionality but only for a limited time? Is it even possible, yet?
To do this, either the PlayBook itself or App World would require a support mechanism, which would basically register metadata that says when your trial started, in a manner that the user cannot access. If the user can access it, or delete it merely by removing the app, it's not effective protection against unlimited use of the trial version.
The only approach that I've been able to think of yet is only effective for apps which could store data that's valuable to the user in the File.applicationStorageDirectory. That way, uninstalling the free trial app in order to reinstall it and reset the timer would also remove the user's data.
But what if the app doesn't involve some form of user content, so there's nothing valuable to which you can couple the trial period metadata?
02-17-2011 12:34 PM
i've been thinking about this as well. and i agree by using hte applicationStorage directory, there is a possibilty of having that data erased and inconsistent. Our best bet would be to have app world handle this for us. but that change probably wont be happening anytime soon. There is also the option of you doing it yourself using a remote server. the downside is of course if the user doesnt use his/her net connection and doesnt all you to check. kind of like an offline usage of the app.
or you can have a mandatory (yes im brainstorming as i type this hah) connection check. so if the user doesnt want to check, they cant use the software yet. yes, its annoying to the user, but if they are using a trial version, isnt that what they are all about? also if they just downloaded it via app world, they should definitely have a net connection and are willing to use their data plan / wifi.
i'll think more about this and repost any thoughts. im nearing the end of my development for my first app. so this is definitely something i need to think about.
02-17-2011 12:39 PM
That's an interesting topic.
How about rely on some sort of online activation to get the trial version enabled? I believe you could associate a Playbook's unique ID to the user registration, and just allow your application to run as trial once in each device.
The drawback is that you need to build the online side of this solution and host it somewhere, which is not really hard to get working. It would be perfect if the AppWorld had support for that, though.
Relying on local storage to this this kind of check is really hard, and you always will face a backdoor somewhere.
02-17-2011 12:40 PM - edited 02-17-2011 12:42 PM
Thinking aloud here. We have access to device data like the PIN, right? Once the time limit is up you could grab that and store it on some server and then each time the app is opened check the PIN of the device versus PINs already in your database and if it matches then don't let the app do anything. Or something along those lines. But, potential privacy concerns and also requires lots of connecting to the internet.
OT: you mention that you can submit an app as free trial. Just wondering what this entails and what are the benefits. I was planning on releasing a free version of my game with a couple of levels so users can decide if they like it before purchasing the full version. What's the difference between simply making this a 'free' app versus making it a 'free trial'?
EDIT: 'nathed twice
02-17-2011 12:43 PM
Excellent idea on the mandatory connection check, Joynal! Definitely a possibility.
If, say, the trial period was limited to a week, you could say that the app continues to function provided it is able to connect every hour or so to check the server.
Once the full product is purchased (which could just be an in-app purchase using the new Payments SDK), this requirement is disabled and the user can use the app effectively offline, at will.
For apps where the user can get value out of it even with less than an hour of usage, you could tie the functionality to some major operation... for example with a game, it could just check in with the server with every new level, or every time you start a new game.
For basic timed use, I suppose you'd want to include the device PIN in the request to your server. The server tracks the first time it hears from any given device, and for subsequent requests it sends the "okay to continue trial period" response only if the trial time limit has not been exceeded.
You could get fancy and support an auto-reset, so if a user played with the app briefly, then stopped for a while and tried again a few months later, they wouldn't be rejected out of hand... if you kept the "block" in place indefinitely you'd likely lose out on some potential sales.
In response to RottenOgre's suggestion: you wouldn't bother with any of this for the full app, once the user paid either by downloading a paid version or by paying for an upgrade in-app. The full version would simply not have this check in place. That simplifies the server stuff, and the user experience, since you're only using the mandatory check as a way of ensuring the stored "trial start" metadata is actually checked and not user-accessible, which you can't do if it's stored in the device.
02-17-2011 12:43 PM
I've been trying to work this out as well. The app world forum at
does give some insight on key generation and such, but it does not address time trials.
The best way would be the application on the PB (app world) that downloads and installs an application would maintain in its database "when" the application was installed and allow the application (by its ID) to query that information. Then timed trial version of the app would be possible.
If you use dynamic keys, you can create a database on your server of the device id, user email, app name, app version, etc. You can add a transaction date/time too so when the app is first launched, it can call your server for that start date and keep it in the local file in app-storage. So if they do uninstall it and reinstall it, you would get the original install date from your server (based on device id, app id, app version) (query only if the local file does not exist). Since they just downloaded it, you know they have WAN connectivity and most people will try an app right away after download. If you cannot get to your server and the file is not there, you can assume current date/time.
Near the end of the trial period, you can nag the user each time the app starts and give them an option to purchase. Use the purchase API to define "virtual goods" to allow them to purchase the application online (in-app). If you have a renewal period (e.g. once a year), you can reset the trial period to 365 days.
I am still trying to figure all this out too. I wished app world on the device would manage a lot of this based on some configuration given at install. For example:
trail period = 15 days
price = $2.00
renewal = 365 // -1= unlimited
renewal price = $0.99
transferable = false
02-17-2011 12:46 PM - edited 02-17-2011 12:49 PM
Completing what I was saying....
I wouldn't ask for connection each time the application is started, or even once a day. My idea is to have a "Trial Activation" mandatory window on the first run. Then your app could use the local time to keep counting the days remaining. It also could save the installation time, and the "last day" time, preventing the user to change the device date.
After your application reaches the deadline, it can show the message inviting the user to buy the full version.
02-17-2011 12:49 PM
@pedgarcia, excellent adaptation there... no reason to require a mandatory check with each run, or hourly, or whatever, if you require activation in advance. That way you simply keep the PIN info on the server and reject a subsequent activation attempt if it's too soon (indicating the user uninstalled and reinstalled in order to bypass the trial limitations).
02-17-2011 12:51 PM
Files in app-storage gets deleted when the app gets uninstalled. So they could use your app for free for ever by uninstalling and reinstalling. At some point, most people stop doing this and just buys the app, but you want to make it a little hard for them. It would be best if the app world maintained this. What ever scenerio is used, has to take into account if a person gets a new PB and wants to "transfer" their apps to the new device without having to buy them again.
02-17-2011 12:52 PM
Yes, also, depending on the kind of application, as I said before, you need to keep track the last time the user used your app. If he used on Feb 17th,2011 , and suddenly it is Feb 16th,2011, the application cannot run.
If your app depends on date/time (like a calendar), you don't need to care about it, since it doesn't make sense for the user to change the date.