I have several big plists in my app. I use them to get necessary input data to my app. While app is running, this data used in various random visual representations. Also, I have favorites feature, where I save some favorite pieces of data. For favorites feature I use CoreData. I transfer some object from my "runtime" data to CoreData and save it.
But should I transfer all data from plists to CoreData, when I launch app for the first time? Or is it ok, to use plists to get data from them every launch?
For example, if we'd talking about reading app. We have some text file on disk. Should I transfer all file to CoreData, when launch first time? Or is it ok, just to save user bookmarks to CoreData?
Core data and plist both are used for store the data. so, if you get data from plist or core data at every launch, there is no problem at all. But if you want to manage complex relational database then you should use core data or sqlite. so, choose storing system as per your requirement like if you want to store user's default credential then you can use nsuserdefault and if you use it to store complex data then also it will work fine but you will possible to face trouble to face some kind of functional operation. So, main concern and your answer there is no difference you get in performance whatever database system you used.
Hoe this will help :)
If you have to only read the data or update all data from plist allmost all the time plist may be ok, also it will be more easy to access then Core Data
Both plist and Core data can be used as persistant storage, but Core Data will have some addtional benifit like i have listed below:
Data stored in the Core Data is pretty secure, so if you can store some sesitive information in the Core Data, data store in plist can be seen directly in some ways.
If you have to perform some insert,update,delete or search on the data it will be better on the Core Data instead of plist.
If you want something like relation or mapping between data it will be possible with Core Data only
So based on the requirement you can choose your storage options
Related
I am going to use Core Data and SQLite together for managing big amount of data on iOS devices. Is that good solution? Are there other ways?
Sqlite can handle very large ammount of data. and core data also use sqlite in backend. SO your approach is right. You should go for this.
for more detail see this:
http://www.sqlite.org/limits.html
There are two ways in which you can write data to file in iOS.
One is NSUserDefaults and the other is Core Data.
NSUserDefaults is not the proper way for storing large amounts of data. It's used to store application settings and temporary data.
Core Data is the proper way for storing and managing large ammounts of data.
Background:
I have an app that retrieves a list of restaurants from a database, each have an individual array of basic information about them (hours, name, address, etc). I would like to retrieve that information from the server on the apps first load, but then have it stored within the app itself, with either NSUserDefaults or Core Data, since the information is unlikely to change. The max number of restaurants I would be storing is about 25, is that a small enough data collection to use NSUserDefaults?
I have looked at similar questions with storing data with over 1,000 records, but I am only storing a small array.
Question:
NSUserDefaults is much easier to use than Core Data, so if possible I would like to avoid using Core Data. In my case, will there be a performance problem if I am storing my list of restaurants in NSUserDefaults instead of Core Data?
Depends on the
size
structure of data
requirements re integrity of the data
Just an Array of 10 or 20 "restaruants" I would certainly store in NSUserDefaults. But only when I am sure that this will never become more complex. Because when you later extend your model but started off with NSUserData then you may remain with NSUserDefaults just because you avoid migrating it to Core Data during the upgrade of an installed app.
So for more complex structures including references and when you have further plans with your app towards more functionality that may require more entities, then you should go for Core Data from start.
BTW, it is not that complicated as you may think.
However, instead of abusing NSUserDefaults, you could simply write an NSArray to file using -writeToFile:atomically: and -initWithContentsOfFile: to read them in.
NSUserDefaults is not intended for data, it's for storing simple key-value pairs like user settings and flags. Core Data is a bit hard to learn at first, but definitely worth it, even for simple applications.
If it really is a small, simple data set that won't change very often, you can also store some data in a local plist (i.e. save NSArray or NSDictionary to plist using writeToFile method). This isn't very different from using NSUserDefaults in terms of performance, although I think it's cleaner and easier to manage. If it never changes you can also include the plist with your app resources in XCode by creating a plist file and filling it in with your data.
Considering the amount of the data, user default or a specific plist/json file are all good. CoreData is definitely overkilling.
I am new in core data please help me in some confusions...
If core data use sqlite in back end then why we use core data not sqlite??
How it is faster then sqlite.
I read a difference that In core data when we want to edit anything it loads all data in memory..but if it loads then why app. not getting slow or crash.
How to show data of a (.sqlite) file that store in Document Directory.
core data is use for persistence storage but it's not a data base(Explain me)???.
Please define all things to me...
Thanks in advance.
If core data use sqlite in back end then why we use core data not sqlite??
Core data doesn't always use SQLite , SQLite is one type of store option( most widely used ), there are two other types available as well
Check this coredata store types
How it is faster then sqlite.
Core data is not an replacement to SQLite , it is like an ORM for SQLite , it handle all heavy work and provide easier interface to work with SQLite , it handles store connection , querying storing , managing and tracking in memory changes etc
I read a difference that In core data when we want to edit anything it loads all data in memory..but if it loads then why app. not getting slow or crash.
This is wrong , core data does not load everything in memory unless you query it yay ways , in general when you fetch an entity it
returns NSManagedObject instance to work with that entity
How to show data of a (.sqlite) file that store in Document Directory.
What do you mean by show data in SQLite file , u will query what data you want using NSPredicate and get an array of objects as response
The .sqlite database will be stored within app sandbox folder
Check this sqlite storage
core data is use for persistence storage but it's not a data base(Explain me)???.
Coredata is not an persistence storage it's persistence store manager, as I said above it handles all heavy lifting work like creating connection , executing query , converting result to NSManagedObject , tracking object changes , persisting it to SQLite and managing entire object graph you loaded into memory
It's hard to compare core-data with sqlite because these are two different technologies.
However here are few things you won't get from sqlite out of the box.
Built-in change tracking and undo support. Core Data provides built-in management of undo and redo beyond basic text editing.
Easy iCloud storage integration (with NSManagedDocument)
Optional integration with the application’s controller layer to support user interface synchronization.
Eg:- Core Data provides the NSFetchedResultsController object on iOS
Full, automatic, support for key-value coding and key-value observing.
Instead of writing SQL, you can create complex queries by associating an NSPredicate object with a fetch request. NSPredicate provides support for basic functions, correlated subqueries, and other advanced SQL. With Core Data, it also supports proper Unicode, locale-aware searching, sorting, and regular expressions.
Merge policies.
Core Data provides built in version tracking and optimistic locking to support automatic multi-writer conflict resolution.
Core Data can reduce the memory overhead of your program by lazily loading objects. It also supports partially materialized futures, and copy-on-write data sharing.
Core Data is the best option to use but if somehow you want to port the application to android or windows and want to keep the code similar then you can go for SQLITE as SQLite is supported by all major platforms. Whereas core data is only part of iOS. Regarding various doubts you can refer this link
Use Core Data or not?
I have a basic question regarding populating Core Data with data. I am building an application, which will show ATMs on a map. I would like to ship the application with a preloaded database, but to give users the option to receive updates when they launch the app. I am thinking about using a property list for the update. Basically send a plist of all the ATMs, parse that plist and populate the sqlite. I will have around 7000 entries in the property list file, each entry containing 5-6 keys with short string values. But according to the Apple iOS Developer Library:
You can create a property list—or some other file-based
representation—of the data, and store it as an application resource.
When you want to use it, you must open the file and parse the
representation to create managed objects. You should not use this
technique on iOS, and only if absolutely necessary on Mac OS X.
Parsing a file to create a store incurs unnecessary overhead. It is
much better to create a Core Data store yourself offline and use it
directly in your application.
Should I still be sending a property list or rather think for an alternative solution to update the application's database?
P.S. I am thinking about using a Rails app for providing updates - basically sending a plist file.
I had nearly the same question a few months back, did quite a bit of searching to find a nice easy answer, failed to find it and eventually settled on a roll-your-own solution that took a bit more time than I would have hoped, but was at least very helpful in learning to understand Core Data.
Basically the solution was to write a little utility that parsed my source data (which for me is a comma-separated text file, parsed using the quite handy 'cCSVParse' library - http://michael.stapelberg.de/cCSVParse ) and inserted it into Core Data Managed Objects and then saved that off as a sqlite persistent store. Then the sqlite store(s) can be shipped with the app, and uploaded by the user when they buy more data.
You could write a conversion from plist (or whatever) into the core data representation within the app itself, but if the data is just going live out the rest of its days in some core data form, why not let your beefy dev box do the heavy lifting before you send the data to the user, instead of shipping the data to the phone and making it do the work?
There are various ways for iPhone applications to save data (for example: NSUserDefault, XML, document, SQLite, etc.).
Our company always uses NSUserDefault to save data. However, I don't think NSUserDefault is very good because in my experience, it has been slow.
I am curious how you store data for your applications and when you recommend using each of the different methods. Please share your experiences that will help me to understand the advantages and disadvantages of these different storage types and develop a more efficient application for my users.
You can store small data in NSUserDefaults but when you have large database then you need sqlite or coredata for storing the database. use of coredatabase is good for big database this is provided by apple and it is to efficient in accessing database.
NSUserDefaults or document directory is used for small database(suppose need to store user name for single user or some other info).
You just need to know about sql queries to store data in a SQLite3 Database or You can use Core Data for back end storage. Core Data is one of the best options to use for storing data.
NSUserDefault should be used for storing small information.
You can use NSUserDefaults for storing any small data which you want to persist when your application closes. This you can use to store login details but yes if it is be secured, use keychain. You can definely use NSUserDefaults for storing setting options.
SQLite database is any easy way to store large data. Core Data is best option. but you can use SQLite if your application data is not too large.
SQlite Database can also be used to store BLOB data e.g. to store pdf file bytes downloaded from server and whenever you want to use it, just write those bytes to pdf file. This will also keep data security since BLOB data in SQLite cannot be viewed.
Its good to use coreData for large data storage in the IPhone Memory space. ITs a wrapper on top of the database which helps us to store in the form of objects.....
U can find many examples on this...