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.
Related
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.
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 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.
I am making a few apps that all require pre-set data to be loaded into the app. This data does not need to be changed or altered in any way as the app progresses - it is simply the data that the app runs on (to give more detail, it is questions for a quiz app). I have elected to use .txt files to store this data, but I wanted to know if this is the best way to do this? Text files allow me to easily change the data without coding. I can also copy and paste from normal documents. Is storing data in this way a good practice, or should I try to hard-code the data/ use a p-list?
The answer to this question depends a lot on how you want to implement your code.
.TXT files might work well, but what happens to the memory requirements when you pass a certain number of questions (e.g. more than 100, or even 10?). Also, what kind of structure are you using in memory to hold the question? If it's a NSDictionary or NSArray, perhaps a .plist file might work better for you.
Raw NSData, or some proprietary format, might work best if you have a lot of non-modifiable questions and you want to try to compress the data down as much as possible (which is a consideration on the low memory / low disk space iPhones).
CoreData might come in handy if you want to store a lot of questions and answers, especially those that users are manually entering in or managing.
For something like this, I will typically use JSON files, and then use Apple's JSON parsing framework.
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 have an app that showcases paintings, the number of paintings is about 600 ( so thats 600 png's ). The client wants me to include those images in the app build, so that they are always available to view even if the user if not online. Of course with every image comes some fields like description, painter, and price estimate, so this app will not stream anything and will have all of its data locally.
Anyway I am thinking of the best way to build this app, I thought of core data, and even encoding decoding, but since These images wil never change, I can put them in an images folder and on viewdidload just loop over contents of the folder and build my tableviewcells.
my question is :
1 : Is this a good architecture?
2 : I need to associate those images with the relevant description of them? whats the best way of doing this? If I jump into core data and create models I feel this would be an overkill.
Keep in mind that these images will never change, nor will the data be updated.
Thanks.
A couple of thoughts:
As discussed in your other question, I think that loading all of these images in the app has its disadvantages, given that you say that the app ends up being 300mb. If it is, indeed, going to be larger than 50mb, then I think you might want try to dissuade your customer from insisting that all of the images be included in the app, itself. I understand that you might not be able to convince them, but at least make sure they understand the implication of including all of these images (that it makes it harder to install the app and therefore, they may experience a lower adoption rate of their new app).
Storing the relevant description of the images in Core Data is a good approach. You could also use SQLite (e.g., via the FMDB wrapper), but I'd really encourage you to just use Core Data unless you have some other considerations you haven't shared with us. But a lot of other traditional solutions for simplified persistent data (plists, NSUserDefaults, etc.) might not be appropriate for this many records. Core Data is great and really isn't that complicated. Sure, the first time you use Core Data, it takes a little getting used to, but it seems well suited for this amount of data.
You talk about "encoding and decoding" of the images, and you haven't described anything that would lead us to suggest that sort of process. What encoding/decoding are you contemplating? It's probably easier to just store the images in the local file system (in the bundle if included in the app, elsewhere in the file system if you're downloading the images on the fly).
You mention that you might have "viewDidLoad just loop over contents of the folder and build my tableviewcells". Perhaps I'm reading too much into this (in conjunction with your other question's comments about receiving memory warnings), but given that you are talking about keeping the images descriptions in Core Data, you don't need to be iterating through anything in viewDidLoad. Your UITableViewDataSource methods will simply query the Core Data database and present the appropriate information. I don't see any need to be iterating through anything in viewDidLoad.
I did a similar kind of application some time ago. I used unique code names for the images and created a Core Data DB that would have one column associating the according line of data (description, author, ...) with the "code" name of the image (i.e., 2347.png).
My model was something simple like this:
NSNumber *imageCode // the number that you would use to associate to your images
NSString *name
NSString *author
NSString *description
I'm assuming that you know how to use Core Data.. if you don't, you can refer to this website: Core Data on iOS 5 Tutorial: Getting Started .. it is really helpful!