There are several packages in my application that user can select each one according to different prices. In server side I store some information of client such as device Id, Android Id and etc.
Based on the package that user choose, for example user has chosen 2 hours plan, server sends me Expire time and I store it in local database.
The question is what is the best way to check that is trial period expired? If user buy 2 hour plan at 12:00, therefore expire time will be at 14:00. I store 14:00 in database and each time application lunched, I check the data base. But the issue is if we assuming that user is using the application how to close application or prompt user that the plan has expired? How do I understand if time of handset is changed by user?
Is use of services best way? what things do you suggest?
==============
Update:
The point that I forgot to say is, because of some restrictions in our office I have access just to three activities that I'm designing and I can't ask other developers who are working on this project, check this and check that or use this variable. But because I'm working on main activity, this activity is the only activity that has access to database.
You should maintain a flag in the SharedPreference and if the flag is set you could show an expiry message instead of your normal activity. You could update the flag using AlarmManager once your period has expired.
Here are few tutorials on AlarmManager and SharedPreferences.
The easiest and best way to do this is the implement BackupSharedPreferences.
The preferences are preserved, even if the app is uninstalled and reinstalled.
Simply save the install date as a preference and you are good to go.
Here's the theory: http://developer.android.com/reference/android/app/backup/SharedPreferencesBackupHelper.html
Here's the example:
Android SharedPreferences Backup Not Working
:) Pete
Related
I have developed an android "Group Chat" app. Me and 20 of my friends are using this app to group chat with each other. When I look at the firebase database, I obviously see 21 users (including myself). However, I can't know whether all of them actually have the app installed on their phones, or some of them have uninstalled it. Is there any way I can differentiate among my uses? Generally speaking, can I "flag" my users as, say, active, inactive, and the like?
What is if you add a timestamp every time a use log in. With this timestamp you can see how long the user not log in and so if he is in active for a long time or not. It's not say if the user have delete the app. It's only a prognosis.
If i understand correctly your question, it can be split in two parts.
First part is whether you want to know if your users are online or offline this could be achieved by an online presence system as described here
The second part is whether or not users have installed or uninstalled your app.
In my opinion easiest way to do this is by using the Firebase Analytics SDK. This way you can check the app_remove stats and whenever a user uninstalls an app, it gets updated in the console under events section.
This will give you how many devices uninstalled the app and some info on country, gender and age of the user but you could couple this with a "last login" timestamp to pinpoint the exact user.
More details along with how to include analytics SDK to your app can be found here
Or you can use the .info/connected to have this functionality in your client code. You can read more info about this here and the sample presence app at the bottom of the page will help you get a grip on how to do it.
One possible solution is to add a flag in the database as the child of the user. This flag will have an initial value of active.
And instead of uninstalling the app directly, you can have a delete account functionality in the app, and whenever someone wants to delete his/her account, it simply updates the flag to inactive in firebase database.
Now you will know actually who is active / inactive.
I've searched for trial application expiry methods and I've found good answers regarding Trial periods for apps but they're time-based.
How can I create a Trial app version that expires after clicking a button 3 times?
based on this link Creating an Android trial application that expires after a fixed time period (option 2 on the accepted answer) I would like to hard code the number of times they have used it, so even an uninstall/intall would have no effect, is this possible?
Since you don't want to allow the user to get the trial again if he reinstalls the app you will have to use the third technique where you send the data to the server because that is the only way to persist the count of button clicks and tie it to the device across app installs. So instead of using the time u can keep a count of the number of times the button have been clicked on the server. Also u can configure the number of button clicks you want to allow before the app expires instead of hardcoding in the app.
If you don't want to run your own server then you use Parse to store the number of clicks of the button and the user id. It is very easy to integrate.
https://parse.com/docs/android/guide#getting-started
On top of pgitu's answer, I also suggest using Parse Anonymous user in which the anonymous user has a field for device ID (the unique identifer for their phone).
Every time the user starts the app, check if a ParseUser is logged in (the anonymous user) if not first check if a user exists with the current device ID for your app and log them in automatically if so. If not, create a new anonymous user and associate the current device id to that new user.
Now, you won't need to force a user signup / login mechanism and you can store information like clicks and such as pgitu suggests. All the remembering of information is done using Parse Anonymous Users and is fairly easy to setup and do.
The catch would be if the user has multiple devices. In this case, you cannot do much with what I'm suggesting but that is just a caveat of having a trial based application and relying on unique devices to mitigate user's and the system. It really shouldn't be an issue though considering you keep track of devices and their # of trials is limited by their # of unique devices.
I am building an application which I wish to upload to the app store as a paid app. But i would like to post it as a trial app for a set amount of time. I looked at all the options in the app billing version 3. I have found a few problems.
If I create my app with a non-consumable inapp item then i will not be able to keep it for a set duration as a trial app(Please let me know if my assumption is correct).
I f I create it via a subscription based model then is there a way I can make the subscriptions last forever and not yearly?
I think I know what you're asking, but if I'm wrong let me know.
What you want to do is let the user download the app for free, let them use it for say 7 days, then require them to pay for the upgrade IAP (in app purchase) or prevent them using it?
If the above is correct there is one main problem that you're going to encounter. To track the date the user started using the app you will have to use something like a shared preference, an entry in a sql db or some local file etc... The only problem with all of these options is the user can erase the data and install the app again to use it free for another 7 days. The only way around this is to implement your own web registration service which I imagine would be a little too difficult.
The best way, assuming you're not too bothered about the people who will bypass it, is to capture the date/time when the app first starts and save it. Each time the app starts check if they have purchased the upgrade, if not check the current date/time against the stored value and if your trial period has elapsed, prompt them to buy the upgrade or close the app.
The main problem here is the user uninstalling / reinstalling the app and losing the shared preferences.
The easy way around this is to use Google's SharedPreferencesBackupHelper
Android SharedPreferences Backup Not Working
You simply save the install date as a preference. Even if the app is un-installed, if they install it again, the orig install date will still be available for you to query.
I am looking to make a trial version of an app I made. Basically I want to put a time limit on how long the app will function before a window comes up that states that the user must buy the paid version of the app.
Thanks for any tips ahead of time!
When your application is installed for the first time on the device, connect to your server and assign it a unique id for the device.
Every time the application is started, check for the expiration date corresponding to the device and show appropriate message when the trail period gets over.
Or otherwise, disable a few features and release them only when the user buys it.
Don't use SharedPreferences because the user can easily clear the application data and the time would be reset.
Use a server with a database that stores phone id's and dates. Then retrieve the status for the current phone. When the user installs a new rom, the id will change, so that should not be very often.
I've been asked for some review copies of an Android app I've written, which is great, but I'm not willing to give out the full app to just anyone. I want to make a time-limited version (which works for about two weeks, then gives up the ghost).
What is the easiest way to do this? I haven't tested this myself, but I think that in theory if one built the app using a keystore which expires in two weeks might work. Is that correct, or do I have to put a line of code in the app which shuts it down if you attempt to boot it after a set date?
The keystore is not checked after the application is installed; only at installation time is the date verified.
You would have to put in your own time limit code, I imagine. Though if you want to be really paranoid, you could consider that the user could alter their device's clock.
Alternatively, you could do an online check (against time on your server), or make each APK that you hand out have an individual token embedded which gets validated against your server.
I have a simplest suggestion, what if the reviewer buys the application, and you refund the payment?
I just thought of a cool way to do this.
You make a Beta version of your app, and you can define the group of testers, you just need the email address of that person, or a G+ community they can request access to, and then you add them to the Beta program.
easiest way is to hardcode an end date and no longer run after that. it can be circumvented if users change their system time, but that is kind of a hassle to go through.
otherwise, you can have your app check the license periodically by connecting to your server over http, but that requires more work.
This sounds like a great idea. You'd probably want to make the app phone home and verify with a server that a certain amount of time has elapsed. Users can always delete your preferences file on the phone or uninstall and reinstall the app to get around on-phone restrictions.
I believe the keystore approach may also work, but I'm not sure exactly how they work in Android.
Please make this an open source project when you finish - I think this would be useful to a lot of people!
You could use TelephonyManager.getDeviceId() and create a build of your application that would only ever run on the reviewer's phone.
You could either hard code this into the application or have the phone check against your server where you'd store permissions for each Device ID. With the latter case you could have your application display the Device ID when it can't find a license; the reviewer tells you this and then you enter this in your DB.
As per Google: "If you plan to publish your application(s) on Android Market, the key you use to sign the application(s) must have a validity period ending after 22 October 2033. The Market server enforces this requirement to ensure that users can seamlessly upgrade Market applications when new versions are available"
What we did with our developer challenge II entry was when we hit the expiration date any new data we processed was replaced by an expiration warning. So the application functioned with existing data but not with any new data the user entered after the expiration. Since our app processed text messages, setting back the clock was an unrealistic long-term solution for the user to overcome the expiration.
Depending on the type of application your are giving to reviewers, you may have another options.
You code it like a lot of shareware and only let the application run so many times. The code for this would be very easy to implement. Sure the reviewer could delete the data, but not very easily. I don't think they would go through that much trouble for maybe a couple dollars.