This may seem like a typical google question but after spending an hour reading various stuff, I am way more confused than I hoped to be.
I am in the middle of developing a game and I have a bunch of data, which is better off being stored inside a database (information regarding monsters such as level sprites ect). Now I also want to have in app purchases later and from what I read firebase is a good way to store inapp purchase information (which user has acquired what, highscore ect.).
Please correct me if I am wrong: All the informations regarding monsters ect. should also be stored inside a database, best case inbuilt app database. For that I planned to use sqllite or core data. I assume that since firebase is cloud based, it is not smart to load data from there just to start a game as a user would always have to be connected to it. (again please correct if wrong)
Anyways I plan to use sqllite or core data to store game information inside the app so that no user can modify it. For data such as high score in app purchases ect. I plan to use firebase.
So my question would be am I on the right track or is everything I said rubbish and there is a better way...
Help is appreciated thank you very much.
For the In app purchase I recommend using this library: https://github.com/kishikawakatsumi/KeychainAccess
The data will not get lost even if a user deletes your app and then downloads it again. It is handy to store buying info in keychain access, since a user won´t need to click the restore purchase button to get what he has bought before (if he deletes the app at some point).
import KeychainAccess
let keychain = Keychain(service: "com.myservice.myapp")
//when a user buys call this:
self.keychain["hasBoughtAcceess"] = "yes"
//to check if user has bought:
if(self.keychain["hasBoughtAccess"] == "yes") {
print("user has bought")
}
else {
print("user has not bought")
}
Related
I'm building a simple iOS app that will be the first I'll have put on Apple's App Store. At one point, the app accesses the user's contact list and lets them select any number of contacts they want to save as favorites.
For ease of building version one, I am currently using UserDefaults to save these favorites. While it has worked well in my limited testing, I know that Core Data and CloudKit are stable options for larger solutions.
For an app like mine, where I'm only using UserDefaults to save a select number of contacts as favorites, is UserDefaults an adequate solution? Or should I transition to something more robust like Core Data or CloudKit? There is no limit on the number of contacts a user could select as a favorite, so there is the edge-case possibility of a user selecting all of their contacts one by one and attempting to save them all as favorites.
If the user gets a new phone and loses all existing data due to UserDefaults being local on the device, it would not take long to get this app back to where they previously had it.
You can use CoreData to store favorite contact locally for large data as per your concern. Now when user switch device or delete app then all data will removed. So for that you can sync with cloudKit or other option is backend server. When user add any contact as favourite same time that contact will add to Core data as well as in backend server. You can sync this backend server data when user login first time in the app, then you no need to sync again. other all thing are as per requirement.
I am creating a fairly simple game in Swift and I am unsure of which data persistence method would be best suited for the project. This is my first "real" project so please excuse my ignorance.
I have to be able to store the following data for users:
- On/Off states for game sound
- The users' high-score
- A game currency unit that users may purchase In-App
- An indicator of whether Ads are enabled or disabled in the game
Also the user has to be able to restore all data from iCloud (I know that's a whole separate issue). Can I accomplish this with just NSUserDefaults/plists or is this more up the alley of Core Data?
NSUserDefaults is great for storing very small amounts of data. In your case this may be a good choice.
There is NSUserDefaults. Yes you can save those small settings.
There is also iOS keychain to store the sensitive data like amount of currency but I don't think it is that important to keep it in the keychain.
If you are interested in the keychain check out this repository.
Locksmith
Finally if you try to save the settings in the iCloud you can use the iCloud key value storage.
iCloud Preference storage
I want to use Apples Game Center for players to log in to my game, but I also want to store additional gameplay related data from the players as well. I want to use the Parse.com service, so I was thinking about having the players signup/login to Game Center when the game loads, and then if it's not already been done, store the players, "player identifier" in a PFUser object on parse. That way I'll be able to store data for the player on parse.
So my question (finally) is, is that a good way to do it? I'm new to iOS so I was wondering if there are any obvious issues with that way of doing things that I'm missing?
Thanks for any advice.
It's not a bad way to do it. That way you use a unique ID for each parse user, then storing additional data in Parse is easy. The steps would be:
authenticate the user with GameCenter
login to Parse with an auto ID or username/password combination
set a new 'gameCenter ID' property for your PFUser in Parse
You'll face some data redundancy, though it's worth noting that the PFUser uniqueID is created on the server side and can't be seeded or modified on the device (not even after creation, I believe). Adding a separate field to your user database to store the GKID data will allow you to find & allocate data to a specific user in the future.
Here's the relevant page from Apple's GameCenter Documentation
Also worth noting: you can generate a PFUser with an auto ID (assuming your user has internet connectivity), which will be as useful for you when saving additional data, so you may not even need to use the GameCenter userID. This auto ID will likely persist within the app until the user a) updates the app, b) deletes and reinstalls the app, or c) follows any other login/signup process you have in the app (Parse is your friend). The primary reason for using the GameCenter ID is that it will be the same for a user across devices/app installs/updates, etc.
I am almost ready to submit my app to Apple but I have a question re: private data storage.
The app is similar to 100's that are out there where you can rate a restaurant, add photo etc. At some point there will be a 'web' component to this where you can view all of them but for now it is not ready. However I would like to 'save' the info so when the web is ready, there will be data to populate.
I am only saving the photos and the data points that users are entering PLUS a unique id for each device that I can later match up to the users device. Do I need an OPT OUT in my app for this?
I don't think so.
But if the user from the app get information about storing the UDID of the device on your space could be a risky move. It's not that bad, but there are enough paranoid people in the Internet ;)
What I would like to know is whether there is anything wrong (in terms of the law, and App Store guidelines) with storing information about your application, and broadcasting it to an online location for gathering.
Specifically, an application which would normally not connect to the internet, connecting when it starts up and storing usage information like time of day, the device ID, and how long the person uses it for.
I'm guessing this sort of behavior is fine so long as you get the users consent first?
It’s fine if you ask the user first and give him an option to turn this feature off. We were once spanked out of the App Store simply for uploading a new game high-score record without a cancel button. It’s quite a long time and the rules might have changed, but better safe then sorry and your users will like the confirmation screen, too.