I'm making an Android application that uses a coin in-game currency (that can be bought using in apps billing) and with that virtual currency the user can buy items that can only be bought once.
To manage every purchase and how much coins each user has, I initially though of using a table for every purchase and user used in the application on the server where I keep my item list, but since my server is a low cost one and i think / hope there will be a lot of transactions, the server will not be able to deal with every user request in time (answering update lists, managing purchases, sending the items to user and so forth).
Recently I found out about BackupManager and I was thinking if I used a local file to save the user coins, the updated list of items and the purchases the user has done instead of using the server, and then when one of these changes (when purchasing a new item, when updating the list of items, etc) i would update the local file and the backup using BackupManager without even contacting my server. Is that doable, is the BackupManager designed to work with very frequent backups like this?
This is wrong approach as you are open to "frauds". On rooted devices people could easily replace or modify your "wallet" file and without own records you will not be able to catch that.
And BackupManager is well... for backups, so I am not really see a correlation between your needs and backups.
Related
I've been setting up in app billing the last couple of days and been trying to go the right way about it. The guides recommend using a secure back-end server to store the purchase token rather than storing the data locally. The documentation on verifying the purchases on a server is very thin and I'm not sure whether am going the right way about it.
I am using cloud fire store to store the purchase information mentioned in the title. I have a couple of questions:
Should I be reading my product id from a server rather than having it hard-coded in the apk?
How often should I/Do I need to read the device id in this case and search on the DB to make sure the user has a valid purchase? Just the once when making the purchase or intermittently?
If I am to do this, what happens when the buyer changes their phone? The device ID will be different and I wont have a record of their new device making a successful purchase. Or here do I query a skupurchase and it returns the item is already owned, write these new details to the DB?
and finally should I store a successful purchase flag in shared preferences or something so I am not constantly reading the DB and the user can use the device offline?
I was going to go down the route of getting users email using this answer here but there is a lot of comments saying this is very intrusive and I only need it for a simple thing. So I went the device ID route.
BTW I only have one product that unlocks full features and is non-consumable.
What is the correct way to go about this?
This was my approach to the same problems. It may not be relevant to your scenario. Hope it helps.
Should I be reading my product id from a server rather than having it
hard-coded in the apk?
You should store productIDs in the code as they will be used to provide features coded into the app.
How often should I/Do I need to read the device id?
You should not rely on the device id as you have raised the concern about the user changing the phone. You would want to implement the login system and make user login into the app before purchasing the product. This will make your subscription device independent.
The process should be:
User tries to use the locked feature.
App asks for login. Make user register and log in.
User clicks on the buy button again and completes the purchase.
Your server stores the user login information with the purchase information.
User changes the device.
User tries to use the locked feature.
App asks for login. User logs in.
The server returns purchase details with user info.
The app unlocks the feature.
How often should I check purchase details from the server?
You should check for purchase details intermittently.
Why? The user may ask for a refund after some time or the payment gateway would void the purchase for some reason.
IMO, there should be two types of sync methods silent and forced.
In my approach, silent sync would check for internet every 9 days. If the internet is not available, it would not do anything. While the forced sync would check for internet every 25 days from the last sync. If the internet is not available it would ask the user to turn it on otherwise, the user wouldn't be able to use the app.
I was using the subscription period of one month but as you have a non-consumable product you can afford 2-4 months forced sync period.
Should I store a successful purchase flag in shared preferences or
something so I am not constantly reading the DB and the user can use
the device offline?
The syncing process and the login would solve this problem.
I think you might be reluctant to implement a login system for such a small thing and think it would make fewer users buy your product. But by implementing Google authentication it would be fast and users would be less frustrated by it.
Implementing this approach involves a lot of server-side logic.
I have an app with dozens of Products for purchase. I am locally storing (SQLite) a list of ProductIDs which match live ProductIDs on google play, and allowing the user to purchase them from a list. I am using this plugin in Xamarin: https://github.com/jamesmontemagno/InAppBillingPlugin
What is a typical (any really) approach / model for ensuring I correctly inform the user of the cost before any interaction assuming that the prices may change?
I could store the prices locally in the database with the products, but that seems highly misleading to the user if these prices change later. I can (and will) of course release new versions of the app and can ensure I sync up the DB prices. But, I can see prices changing much more frequently and not necessarily coinciding with app releases at all. Also, I see the problem of old versions and I don't want to force a user to update their version if they don't want to.
I could always retrieve them from the store and/or refresh them every time the app loads but that has its own drawbacks and potential annoyances for the user, not to mention seems unnecessary if they aren't planning to purchase anything during that app session and/or are using the app offline (will be a common occurrence given the type of app)
A common model is refresh them from the store, but do this in a best effort fashion in the background. If this succeeds, great.
If this fails, do it again just before displaying the list. The user will have to be online anyway to purchase.
For an even better user experience, in the event of failure warn the user prices may be out of date and have a UX affordance to refresh them.
The Google Play Games Services guidelines state the following: "After signing in, the player must always have the option to sign out."
Imagine the following scenario:
I download a mobile game and play it for a few weeks whilst authenticated
During this time, I unlock levels and accumulate in-game currency (which is saved to the cloud)
I decide to sign out of Google Play Games Services, but continue playing the game
I see two options for managing the player's data:
1. Copy all of their cloud-saved data to local device storage
2. Start the user over again, saving data to local storage (if they log back in, they'll get access to their cloud save data again)
The first option sounds the most logical, but it also means if the user logs back in again that I'd sync the local data back to the cloud. Therefore, a user could sign out, alter the locally-stored preferences on their device directly (e.g. add 1000000 coins), then sign back in and have that data synced.
My question is, is synchronising the data both ways the "correct" way to go about this, despite the risk of (some) players being able to tamper with their data? I've been able to find plenty of info about signing out, but not what to do afterwards.
Thanks!
My question is, is synchronising the data both ways the "correct" way
to go about this, despite the risk of (some) players being able to
tamper with their data?
Nope. Separate the score system into two:
Offline and online score.
When user sign-out, take the online score and save it to the offline score. User's offline score will continue from where user left from online score.
If you decide to sign in again, use the online score. Also update their offline score with the online score.
By doing this, you are only making it harder for players modify score. If the game is running on the player's side, the player can always change the score if they understand basic APK reverse-engineering. The data does not have to be saved in other to be altered. It can be changed in the memory. It can also be changed by decompiling, altering your code,compiling and signing the APK.
Now, if you make the game to run on the server but read input from the user then it cannot be altered unless your server is hacked.
This depends on the game if it is a story based game you could solve this issue by differentiating between authentic cloud saves and offline saves with a save menu as you are not limited to one save by the API. If it is a premium currency based game such 1.00$ for 100 Gems you should keep all transaction records on the server as it is not wise to allow the user any chance to alter these values.
"A game can write an arbitrary number of Saved Games for a single player, subject to user quota, so there is no hard requirement to restrict players to a single save file. ... All Saved Games are stored in your players' Google Drive Application Data Folder. This folder can only be read and written by your game - it cannot be viewed or modified by other developers’ games, so there is additional protection against data corruption. ... Saved Games are insulated from direct tampering by players so they cannot modify individual Saved Games. ... In general, the best way to avoid data conflicts is to always load the latest data from the service when your application starts up or resumes, and save data to the service with reasonable frequency. ... Your application should make every effort to handle conflicts such that your users' data is preserved and that they have a good experience."
here is a link with more information.
I have a question regarding in-app purchases in Android. But first off, a little bit of information about what I am trying to do...
My app has a collection of "modules" that are arranged in a SQLite database arranged like this. These modules are differentiated simply by a column that designates what module that particular entry belongs to. What I want to do, is create an in-app purchase system where the user can download additional "modules" of content.
What is the best way to arrange and handle this data? Is it a good idea to keep the database setup and somehow implement a system where the in-app purchase adds to the database? Is it possible to keep track of this in the case that the user deletes the app or app data? I want to make this system as dynamic as possible, so that the user is not shown a message saying there is additional content available if they have already purchased and installed it.
The development on my app has not begun yet, so any other arrangement of data can easily be explored. For reference purposes, each "module" will have about 50-60 entries, and the plan is to have anywhere between 5-20 "modules" so there will be a good chunk of data.
Sorry for the plethora of questions all at once. If you need any screenshots to get a better idea of the data, or if I didn't do a good enough job in explaining what I am trying to do, please let me know!
For me it sounds like you need user accounts serverside. There you keep track of the necessary things about the user, like what he/she has bought, etc. In other words, the database is in a remote place, not in the app, so you can delete and reinstall as you wish and the data is still available.
In order to identify the users, this will help: http://developer.android.com/training/id-auth/identify.html
I want to store a small amount of data in a way where it persists between application installs. I obviously can't use SharedPreferences as they are removes upon uninstallation. Is there any way to store data so it survives a reinstall of the app?
The data I want to store is a unique ID, to allow blocking of users of the app if they misbehave. If I cannot store an ID, can I access the Google account(s) email addresses to use them as an indicator?
This blog post makes it clear none of the IDs the OS produces are any good, especially when considering tablets
Android: Identifying app installations
You can store the data in shared preferences and use a backup manager to have them backed up automatically. They should be restored once the app is reinstalled.
There is no real way of blocking the app for certain persons. You could fore all your users to create an account to use the app and block the accounts but they always can recreate an account. You could store something on the SD-Card and check for it but malicious users can find that and delete it. You could try to get the user to authenticate themselves with their google account against your app (andlytics is using an authentication method like that) but the user can factory reset his phone and create a new google account.
You have to choose how important the blocking of the users is and how much you want to annoy your other users because of some users that are not using your app as intended.
yes. you can store some data in the internal memory or the sd card.this can be done by creating(.somename)folder which is invisible to user and create a file.txt to store the data.
If the app is removed, the data is removed. You could put something on the SD card, but there's no reason to believe it would stay there. You might be able to work something through the application licensing mechanism. Details here