• Replies 25 replies
  • Subscribers 21 subscribers
  • Views 10060 views
  • Users 0 members are here
Options
Related

Deleting & re-loading to get around Trial Mode

Jeff
over 4 years ago

Is there anything preventing a user from deleting and re-loading an app to circumvent use duration limitations imposed by a trial version of an app ?

I don't intend to use the "Trial Mode" that shows up in the documentation, but the problem is the same no matter how you implement it.

If you want the user to be able to try out the app for a day, or a week, or a month before buying.... is there a way to accomplish that ?

My understanding is that all stored data relating to the app is removed from the device when the app is removed, so the app doesn't seem to have any way to detect re-loads, or to find data that might have been stored indicating that the trial period had expired.

Thoughts ?

Thanks

  • over 2 years ago in reply to Rick

    I'm trying to add this to my datafield. It has a base functionality that already works with lots of users, and I am adding a new feature soon that will be "behind" trial. Instead of giving X days of trial period I'll make it so it works for 10 minutes from the activity start. If someone is so cheap that wants to use the new feature without paying and prefers to cut their activities into 10 minutes chunks, then let it be. This way however I don't care how many times they delete and install the app.

  • over 2 years ago in reply to flocsy🤠

    I ended up doing something similar.

  • over 2 years ago in reply to Rick

    I ended up using kiezelpay. Install the monkey barrel and you are off.

    staight forward.  

  • over 2 years ago in reply to Nick

    I tried also, but it adds so much code I gave up on it. Now I try to do it using the app trial and try to convince kiezelay's Kristof to add support for it. If that would happen it would be a good way to use it without needing to add support for networking, background app and kiezel itself. From the app's point of view it would be just 3 lines added to manifest and a call to AppBase.isTrial() wherever it fits the business logic. Since I plan to continue provide basic functionality (that already exists in the current version of my DF) to everyone, and only check for isTrial() when they try to use some of the new features I'm planning to add soon, this would be a very good deal for me. Because it lets me use the not so much memory still left on devices with only 32K datafield memory and still get payment for it.

    The only disadvantage there might be is that the app trial is probably less flexible than kiezpay in terms of what it is able to do when the user buys a new watch. I don't know the answer, I assume that the user will need to buy a new license from the google app store's point of view. I'll need to decide how I deal with it in terms of kiezpay, whether I require a new purchase or I allow a user who alredy purchased a license for the same app to "migrate"* the license to the new device.

    *) When someone uses kiezpay as is (using network and background) then it's a real migration, meaning it disables the license on the old device. When trial app would be used then this migration would only be able to enable the Pro functionality on the new device but wouldn't be able to disable it on the old device.

    Still I think once I decide whether this is allowed or not and that decision is clearly stated before they purchase the license (especially if the decision is that for every device they need a new license) it should be OK IMHO.

  • over 2 years ago in reply to flocsy🤠

    Last I heard, trial apps required Garmin approval on a per app basis.  That's why you only see one or two apps in the store that use it.