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 2 years ago.
Improve this question
From my understanding, following are the data storing mechanisms:
UserDefaults - store small amount of data
Keychain - store sensitive data
Coredata - Framework built on top of SQLite for convenience
SQLite - preferred for complex querying mechanisms
plist serialization - saving plist file
Data.write(to: ) - saving data to the specified file
A. Is the above information true?
B. Also, does all these mechanisms store data in the Document Directory(or sub directories) path by default?
C. Does it use the local storage of the phone and is deleted once the app is uninstalled?
Please correct me if I am wrong. Sorry if its too basic, I have been reading hundreds of articles and it is confusing
Yes. You are right with your understanding of data storing mechanisms.
But, apart from these 6 methods, another 2 methods which help to store data locally are:
i) Codable (protocol): used to save custom objects into a .plist file. It overcomes the drawback of the UserDefaults method that stores only built-in types data such as Int, String, Array, etc.
ii) Realm: It is a foster and easier database solution. You should also check its official documentation for more details.
All methods stores data into the Documents Directory. You can even print the path of document directory and open it in file manager to view 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 years ago.
Improve this question
I understand Keychain is designed for saving Passwords, InternetPasswords, cryptographic keys, etc. However, why not just save small encodable models as well?
For example, an encodable and decodable structure that holds about 100 properties of user sensitive preferences.
I tried this and it worked pretty well. Although, there is not much concrete information available and I want to understand if there are any downsides to doing this.
Nothing actually prevents you from doing it, as the encoded data model will be in the form of Data/NSData. There may be a pair of points to keep in mind before going in that direction:
there’s an actual size limit per
single keychain item ( which I personally could not find officially stated, but I remember that writing a keychain item which data size was greater than about 2 MB, led to a keychain write error ). That means you should be careful on how big the data model is ( for example using short CodingKeys instead of the actual property names, would use less bytes in the resulting data block to be written )
keychain data does not get deleted when the user deletes the app. Whether this will stay like this forever or not I can’t tell, but is a fact as per now, and this means you may need to put a logic in your app to make sure that another installation on top of the previous one may not use the old/dirty data as unnecessary
I don’t discourage you from using the keychain for that, but in case, there are alternative approaches, like storing an encryption key on the keychain and using it to encrypt/decrypt your actual data models and write them securely in your app document folder. You can combine this with extra steps like NSFileProtectionComplete setting, make the encryption key in the keychain accessible only if the device is actually protected by passcode, and maybe, if you plan to store quite a lot of data, combine encryption and CoreData together.
Hope it helps
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 5 years ago.
Improve this question
I know what plist does but what is the general purpose of plist?
Is it good idea to use it to write/read data with it?
Sorry for broad question.
Thank you
Suppose your app has a big constant that it uses, like the names of all the countries in the world in alphabetical order. That's an array of strings. How will you create that constant?
One way might be to type the whole array in code, a really big array.
It might be easier to configure this as a .plist file and read the file into an array as your app launches.
So, that is one use of a .plist file: it's a text rendering in a canonical format for data that you will need to use during the app's lifetime.
And of course the same thing works in reverse; you could save an array of strings as a .plist file while the app runs, in order to read it again the next time the app runs. (That in fact is how UserDefaults works.)
Think of a plist as a file-based implementation of a Dictionary (or NSDictionary). What you have inside are key-value pairs which you can parse and use as part of your logic.
If you might have observed, there would be a Info.plist file in every project. It stores values for different configurations you might want to add. An example would be NSAppTransportSecurity
Once you have the values in the file, you can use it as:
var configDict: NSDictionary?
if let path = NSBundle.mainBundle().pathForResource("Config", ofType: "plist") {
configDict = NSDictionary(contentsOfFile: path)
}
if let dict = myDict {
// Use configDict here
}
Keep in mind that you are not limited just to the default Info.plist that comes bundled with the project. You can create one of your own too. Consider the scenario where your are fetching a number of configurations at launch. You can save it as a plist and reference later.
Answering the second part of your question, reading and writing to a file, if performed at very short intervals, seems like a unnecessary overhead. Its better to use local Dictionary variables and then write at longer time intervals or when you are sure that changes are done. Plist is more of a kind of persistent storage. So you can opt to write to the file when the app enters background or user kills the app.
Note: Keep in mind that plist is essentially a plain file in your file system. There is nothing to prevent someone from reading it (and I know about sandboxing). That is why its wise to never store any passwords etc in a plist (nor in UserDefaults).
Plists are convenient for when you need to store small amounts of persistent data. The API is simple. Large plist files are not recommended. Apple suggests less than a few hundred kilobytes. You would not use a plist for storing user generated data, since over time they might exceed that limit, only use it for data whose size you control.
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
First I should confess that I am completely new to iOS programming and would like to get an answer for a question which I was googling all the day.
I would be having an app which will contain nearly about 500 images of png format with less size. How to store these images by categories inside the app? From what I learnt,
I can create a plist and map the images with strings (but not recommended by many if the data becomes huge)
creating a manual folder and storing the images (not sure how to do this..)
I have seen lots of codes on how to download and save the image from web or even from camera, but not sure what is the best way to store the in-app images which I have in hand in the app itself. Any sugggestions with sample code would be greatly helpful.
Are you downloading the images? Will these images ever change? Do you have a lot of metadata for each image (you mentioned storing them by categories).
While this is not the only way to implement it, I've had luck implementing things like this using a CoreData model that has an Image entity with category and filename as properties. You can store the images in the NSBundle or anywhere you like as long as they are in the same directory to make it easier on you. Then make sure each filename is unique and maps correctly to the CoreData entity.
This allows you to also at any time, allow more images to be sent down or even replace them. Once you download new images, you add new entities to your CoreData without you needing to update any plist or mapping. You also gain access to NSPredicates with the CoreData fetchRequest, which will allow you to query the CoreData for images that fall under 1 category or even several categories.
The downside is that it requires additional set-up, namely learning CoreData and implementing it into your project.
Edit:
For doing something right now and very basic, the answer is easy to implement. Add the folders into your directory and make sure they have the target/are getting in the bundle. From there, add a pList that for each category lists the filenames of every image you're interested in.
Then when in the app they click on a category, you pull the plist and get the list of names as either a dictionary/array. Then you load all the images.
The downside to this is that you have to manually update the plist for any new changes and send it down to the phone from a server.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I am wondering if iOS has any build-in database, and if so - maybe you can direct me to some tutorials and/or API-description online ( similare to the JavaDocs ).
I am new to iOS and Objective-C programming. I have experience with Java and Android-development, and I am currently developing an Android-application for containing what CD's I have in my possession / collection - and want to re-produce it to iOS.
I have gotten stuck at the point at where I'm not sure how to save the information for the iOS-application. In Android you have an built-in database that you can use, and I stumbled upon an input ( here on StackOverflow ) a while back that someone wrote something about an SQLite-database and I would like to create an database first-time the application is run.
The alternative would be to save an file ( XML or JSON ) containing the information. But as the application is meant to handle large sums of information I want to use an database of some sort.
Thanks for all the possible help and directions to where I can find more information.
iOS has Core Data that works great in most of the cases. If you are used to Android's SQLite you can also use SQLite in iOS. Although, in general, people use Core Data.
XCode provides you a set of tools to work with Core Data. You can create a model inside XCode and see the relationship between Entities. Core data is not a relational database. It can be persisted in a relational database (SQLite) but the concept that supports Core Data is different. Core data is "an object graph manager with lifecycle" and you shouldn't fight against that concept. Try to understand the differences before dive into Core Data.
Dylan touched an important part. You also have wrappers and tools to help you with SQLite. One of them is FMDB.
For CoreData you also have a framework that can help you called MagicalRecord.
Yes, iOS come with built in core data feature. Here is the tutorial you can start with.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I am wondering if it is possible to make a completely new format. Mac use a .text file for text and .mov for movies so is it possible to make a new format that i can put into a iOS application that it will use off and export off, for example the application pages exports a .pages file, and if so what is a good tutorial site or script that u can use.
A few thoughts:
File extensions
If this is just a file that your app uses internally, it doesn't matter too much what extension you use. Use whatever you want.
If you're going to be sharing files, however, you should ensure that you pick an extension that you're confident is unique. For example, it looks like RCB extension is used by Easy Resume Creator Pro (I don't know it, but that's what a quick google of that extension reports).
How to do it.
I'd simply advise you refer to How to Import and Export App Data on Ray Wenderlich's site, which describes how you can define a UTI for your app's data files. Also refer to this Stack Overflow answer.
How to store the information.
In terms of how to store the data in the file, you can obviously do whatever you want, but I'd encourage you to consider, if dealing with text data, using an established format (even if you're using your own custom extension). For example, if dealing with simple Cocoa objects like arrays or dictionaries of strings, numbers, dates, etc., I might suggest using a property lists (see Apple's Property List Programming Guide which writes data in an XML format.
Alternatively, if using your own NSObject subclasses, you can use a binary property list format as enabled by NSKeyedArchiver and NSKeyedUnarchiver which are discussed in Apple's Archives and Serializations Programming Guide.
There are lots of other formats that are open to you, but these two approaches take advantage of well established interfaces for reading and writing data and can be done with a minimum of effort
Alternatives to new file format.
Depending upon precisely what you're trying to do, if you're exchanging trivial amounts of information, a custom URL scheme might be sufficient. This bypasses the issue of dealing with custom file formats and enables a few other workflows.
Hopefully this is enough to let you start researching the different alternatives.