Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Not so long ago I found out about NSUserDefaults and thought: If I can just keep the information my application needs as NSUserDefaults, why bother creating a database? These are the variables my application needs:
Username (of type String)
Coins earned (of type Int16)
Bucks bought (of type Int16)
Items bought (of type [String])
How suitable are NSUserDefaults as an alternative to using a database? If I do use NSUserDefaults instead of a database, would it be reasonable to list all the "buyable" items as an Enum?
The NSUserDefaults documentation clearly states it's primary function is to store user preferences:
The defaults system allows an application to customize its behavior to match a user’s preferences.
Of course there's nothing to stop you from using it otherwise, it's a very cheap and reliable way of reading and writing data, but it's worth knowing that it isn't designed to store application constants and variables.
Furthermore everything you write to it will be available to read in plain text if the user looks into his application container (and therefore easily editable). Therefore you probably don't want to be using it for anything that the user can change to get an advantage in your game.
You might want to look into NSKeyedArchiver for storing custom objects that could contain your data. This will allow far greater flexibility, and you can encode your data in a non-plain text format.
NSUserDefaults is used mostly for preferences not for sensitive data.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 months ago.
Improve this question
As a newbie on iOS, I am devoloping a small app. There are 5 different pages and 4 of them has an imageView for user's profile photo, I am storing and downloading profile photo in Firebase.
Is it a bad practice to store the profile photo on userdefaults to not the download for each page that has imageView? I also have to store user's name as a string an a date (date of the user opened my app for the first time)
I know I got options like NSCache or Core data but UserDefault looks 10x time easier than them. I read on the internet that UserDefaults is only good for small amount of data, otherwise it will slow down my app performance, but they never mention how small.
So an image that has max 500kb size and a string with a date would be a performance problem? Is UserDefaults only for saving things like settings or a boolean for onboarding etc.?
Yes it is bad practice (and inefficient), UserDefaults is for small stuff like settings and preferences, small unimportant and low vulnerability stuff.
https://developer.apple.com/documentation/foundation/userdefaults
KeyChain is for small stuff that needs to be secure such as user data, tokens, etc.
https://developer.apple.com/documentation/security/keychain_services
Apple has provided other locations such as for "caching"
cachesDirectory
https://developer.apple.com/documentation/foundation/filemanager/searchpathdirectory
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 months ago.
Improve this question
I am brand new to ios development and am looking for some advice on the best way to structure my user data and access it throughout my app.
Data is retrieved via HTTPS requests that query a database for the desired information. There are separate calls for the different tables containing information of interest. The returned data is formatted as nested dictionaries where the outermost key is the column and the subsequent dictionary is key-value pairs of the index and the table value. Example:
{"column1":{"0":"value1-1", "1":"value1-2", "2":"value1-3"},"column2":{"0":"value2-1", "1":"value2-2", "2":"value2-3"}...}
My primary requirement is that I will need to be able to filter this data by the innermost values (some will be dates, some will be numbers, etc). I would like to have the data in a format that will make this simple to do and will not cause delays as there is no limit on the number of possible rows.
I have looked into reconstructing a user-specific SQLite database with the information and querying that throughout the app as necessary. I have also explored dataframes as this app was originally developed in python - don't ask - and relied on pandas dataframes.
I know this decision will impact me heavily and am trying to do my best to make an informed decision. I appreciate any feedback and am happy to give more useful context that might be missing.
TIA
You can use SQLite database for persistent storage. This is ideal for your main requirement of filtering the data. You should also create a structure or a class modelled on your data to store and use during runtime. You can refer this for deciding between a class or structure.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I make an application which receives data via bluetooth. I would like to store this data received at regular intervals to make a history and store it in the application.
I would like to know what to use (Core Data, UserDefaults, ...) ?
Thanks
It depends on amount of data but mostly what you want to do with that data.
Core data will take most of time to implement but you can do a whole lot of things with that data. You can search and filter items for instance by date and even put them into sections. NSFetchedResultsController can be very helpful here.
User defaults are probably not very appropriate as they are designed to hold small (or at least finite) amount of data variables like some settings, flags...
The other that comes to mind is simply saving them into file. Probably the easiest would be using JSON. JSONSerialization should be able to encode or decode your data from concrete objects to Data and back. Also there are some nice tools now that can greatly speed up the process. Check into Codable. Data in the end can be saved directly into files which may then be created in documents directory of your application.
You should evaluate how will these data be accessed. If you are targeting for instance showing charts on monthly, daily and hourly basics, have ability to remove entries and such then I would go with Core Data. If you just need to open some old logs and look into them then saving to disk is probably a more fitting solution.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I developed an iPhone game in Swift using Xcode. It needs to store settings as well as user data. How do I get the app's settings and data to save when it is restarted or quit?
As mentioned in comments, use NSUserDefaults for settings. For "large files" it's more likely you mean "user data". In that case, you can use Core Data or store your own NSCoding-compliant data model via NSKeyedArchiver (and unarchived via NSKeyedUnarchiver) or their ...Secure... alternatives to write to your app's documents.
Rather than save only when the application's state changes, you should probably persist small changes as they're made (this is basically what NSUserDefaults does) or as some logical group of changes are made (what constitutes a "logical group" depends entirely on the nature of the data and your app and is therefore up to you).
So: Identify the "settings" and store them the right way (in NSUserDefaults). Then identify your user's game data and store that the right way (in some sort of data file).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm writing an application which uses core data, and I use it to store a reasonable amount of user generated data.
However, the app also has a few settings ... such as the users name, age.
I'm wondering if it is better practice to store setting information in CoreData, or to simply store this information in UserDefaults?
answer acording to title: no
(added: especially not large amounts of binary data)
This is really more a question for Programmers Stack Exchange, but I give it a quick go over.
Core Data is powerful, but that power comes at a cost. It adds complexity and indirection.
I think it good to think of all your model objects separately. Figure out what makes the most sense for that object. This is not to say let chaos rule, patterns make code easier to understand. I think it's not good to shoehorn something into an existing pattern, because you want everything in your app to fit the pattern.
All that said. Unless your app is storing a list of users, I think it's better to use the simpler approach of NSUserDefaults.
Core Data is a big thing, not really simple. I would rather you to think about your data model first. If its "big" enough and you think about to expand it maybe in the future i would recommend you to use core data.
Now to my personal opinion:
I'm not really a fan of Core Data. I use mostly a SQlite-Database. If you need alot more and you are a starter checkout parse.com. Its a complete backend-service in verious languages. Check it out..
If you are saving credentials or some other protected data then this is the best practice:
iOS: How to store username/password within an app?
For temp data and most of other flat data use UserDefaults...
Use CoreData as more structural data storage, when you have lots of records or linked records, for more complex data structures in general...