i'm struggling a bit with this subject since I come from the world of PHP where you don't have anything like "Core Data" (as far as i know).
Until today, when i needed a data model for saving data from the server , lets say i got some users from an API, i would create an NSObject class called "MyAppUser" , and on the .h file would have the properties for that data and synthesize it in the .m , and then just use that class for arranging my server-data in nice neat objects.
I read a bit about Core Data , and it seems its mainly for actually storing the data in some sort of database, which isn't what i want. What i want is actually just have organized objects with data from my server returned to me. Could i do this with Core Data? just have objects but without actually managing them and storing them ?
Thank you and sorry if my question is a bit "scattered" :)
Shai.
Your interpretation is correct - core data is a persistence framework. It is designed to help you store and retrieve data between sessions. It's not worth the overhead (IMO) for transient data. Use a custom object for storage, or even just an NSDictionary.
Related
i am new to this Core data. When i search for tutorials, I'm seeing this sentence Core Data is not a database everywhere on the internet.
If it is not a database, why are we using it as a database?
For what purpose Core Data is initially created?
Is there any other way Core Data was used before/will be used in
future (Other than as a DB)?
Sorry for my English.
Thanks for the time.. (:
Actually Core Data is a bridge between the code and the underlying database (like SQLite or XML...). Core Data is not a database, but uses SQLite (or XML...) for persistence. The main purpose of Core Data is to manage memory objects and object graphs easily without having to do it manually through a SQLite library for instance. It is possible to use Core Data without persistence is you want (using In-Memory stores).
Here is the documentation : https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CoreData/index.html#//apple_ref/doc/uid/TP40001075-CH2-SW1
Bye!
If it is not a database, why are we using it as a database?
"We" are not necessarily doing so, depending on who you mean by "we". Core Data can be used in a database-like manner, keeping in mind the Core Data vs. SQL differences others have noted. But that's not the only possible use.
Statements that Core Data isn't a database are mostly intended to prevent people from thinking of Core Data in the same sense as SQL. That sort of thinking leads to badly designed data models, since the approach is different. It can be used as a database in the generic sense of the storing structured data but it's important to not assume that it works like other databases you may have used.
For what purpose Core Data is initially created?
Is there any other way Core Data was used before/will be used in future (Other than as a DB)?
Core Data was created to fill what might have been perceived as a missing piece in Apple's frameworks. They generally take the MVC approach. There were classes to help in designing and implementing views (in these pre-iOS days that meant AppKit) and with controller classes (for example NSArrayController, also an OS X class). But model support was limited to NSCoding, which required a lot of repetitive code. Custom solutions also had trouble scaling to large amounts of data-- for example NSCoding doesn't help you load only part of a large document graph, because it recursively works its way through the entire object hierarchy.
Core Data was added with the purpose of making it easier to design and implement the model layer of an app. It's no accident that the document you edit to design the data is called a data model and not a schema.
The idea was (and is) that you could
Design your data model visually in Xcode
Create and use instances of your model objects
Read and save those objects in a file
...all without ever needing to write your own code to figure out how to convert your model objects to and from something that could be written into a file, or with the mechanics of opening a file, reading/writing it, and saving it. You'd just create objects as needed and then call save on NSManagedObjectContext. The small bit of code that was concerned with locating and opening the file was all pretty much the same in any app, so while it was still required it was mostly no longer the app developer's concern (and in iOS 10, NSPersistentContainer eliminates even this). You'd also get the benefit of only needing to load the parts of your object graph that you currently needed instead of loading everything every time.
As you've noticed, in practice Core Data is commonly used more or less like a database, and it works for that. But it's not designed to be limited to such uses.
Yes it is true , Core data is not a Database, though internally it saves data using sqlite. We use Coredata for persistent data which means we should be able to save the data and use it even after closing and reopening the app. There are various ways to store data like Sqlite,Plist,UserDefaults and CoreData. Coredata does not maintain any relations like SQlite. It means there are no keys like primary and foreign etc. Coredata allows you to deal with data in Object Oriented Approach. You can easily work with data operations even you don't have knowledge about DB queries.
Typically I use Core Data in my applications, but for my current project I don't need data to persist launch to launch.
Because of that, I'm wondering how I should store my data. It's not going to be tens of thousands of items or anything, hundreds at the high end most likely.
I'm still going to create an NSObject subclass to represent each "entry" in the database, but what should I store that in? A simple NSMutableArray that's a property? Should I have a distinct model class? Should I still be using Core Data somehow?
What's the accepted/best practice for a situation like this?
The persistence aspect is only one part of core data. The fetch requests, object graph maintenance and entity modeller are arguably just as important.
If you don't want to persist your data, use the in-memory store type when creating your core data stack.
I would say that if you are familiar with Core Data why dont use it?
But alternatively of course you can stick with NSUserDefault. Atm i'm using the NSCache class.
Good explanation of NSCache and how to use it
Apple's Doc
I would give it a shot if you dont like to use CD for your current Project..
Since you're not worried about persistence, it seems simplest to just use a wrapper around an NSMutableArray (or NSMutableDictionary if indexing is more important that ordering) Since you can apply NSPredicates to arrays you've still got the ability to do very dynamic database style sorting and searching without some of the drawbacks of core data.
Use a wrapper instead of just using an array because that gives you a convenient place to put sorting and searching options, as well as possibly giving you better access to KVO operations.
I have developed an app that downloads the whole dataset into an array of objects. Should I be using core data to store the data? Aside from having some off-line data at hand for the user, are there any other advantages?
Thanks,
Steve
It's difficult to say with so little information. But if you need to store and access a bunch of data in iOS, Core Data is usually a good option.
It's obviously more complex than just storing the data in files (an array/dictionary can write its contents to disk) but you get a lot of other stuff for "free." Nice things include NSFetchResultController which means you can push your data into a table view with very little code. It makes things like undo and transactions easier.
Another option is using SQLite directly. If you know SQL and your data structure doesn't easily fit into an object graph (for whatever reason) or you want more control than Core Data can give you, it can be a good option.
I've been searching for an article that explains NSCoding (NSKeyedArchiver...) advantages and disadvantages over use of CoreData (SQLite....).
There's a lot of options, I can implement my own custom binary reader/writer, or use plists/xml/json... or use SQLite or NSCoding.
I'm kind of lost right now.
Can any body explain what's the difference between the MAIN features?
It depends which kind of data you want to save and whether you will use it only internally or you have to exchange the data with an external service.
NSCoding is generally speaking a data serializer. A lot of built-in objects implements the NSCoder protocol that allows you to save them as a binary stream (file, in a BLOB of an sqlite, etc.) The NSKeyedArchiver gives you the plus of searching in such streams based on a string label, a bit like a dictionary but you can use only strings as keys. This approach is good if you occasionally have to persist some objects of different classes.
However if you have many objects of the same class, you'll better go for a database-approach, SQLite or CoreData. CoreData is practically a wrapper around SQLite that eases a lot designing your data model, and does the queries to the DB behind the curtains, without the need of writing SQL statements. In CoreData you define your classes, and each instance of the class can be persisted i.e. you can get back the values of the members of the object without having them always in the memory. This is a very convenient way to store a lot of structured data. For example if you'd write a web browser, you could store the bookmarks of the user with the name, URL, and maybe last visited time.
For XML and JSON there're no particular advantage if you use the data only locally to the device. If you have to communicate with some external service, you might consider to cache/save the XML / JSON objects as they are for later use. Other approach would be to regenerate this data from your internal data structures (see above) every time you need it.
If you design your data model yourself, I see even less point to use plists, but maybe somebody will correct me.
EDIT: I add here a short link reference for tutorials on how to use NSCoding, Core Data, and as a bonus, SQLite.
UPDATE 12.01.2016: If you are looking for persistence solutions I suggest you to also check out Realm.
Mattt Thompson provides a digestible breakdown of various differences among NSCoding, Core Data, and NSKeyedArchiver on NSHipster: http://nshipster.com/nscoding/
There's always an impedance between objects and relational structures. I always prefer objects since data access is typically a fraction of functionality in your app. With NSCoding, you get simplicity, ease of debugging, and control with very little code to write anyways. You also have the flexibility to incorporate NSCoding into your database structures.
NSCoding is a persistence mechanism for saving objects. If you add indexes to your relational structures for search optimization and maintain object structures, then I think you get the best of all worlds at a very low cost and ease of maintenance.
To add to already great answers, NSCoding along with NSKeyedArchiver is a great way to store data which is too big (or incompatible data type) for for NSUserDefaults but too small and non-numerous for CoreData.
I think this is a common scenario.
I'm defining class models of my app, I will use Core Data for caching so I would like to take advantage of the NSManagedObject generated subclass to "reuse" it as a model to pass to different classes.
Is that advisable?
Let's say I get some data from the network I want to build an object model with same instance variables as the Core Data model generated, use it when needed and maybe cache it on the DB.
What is the common approach there?
Can I use a category on Core Data model?
Core Data subclass? Encapsulation? New class ?
Thanks for any tips on that.
Core Data is not, at its heart, a database, but rather an object graph manager.
In many scenarios, it is a very good idea to handle your objects with Core Data, and you can use a fast in-memory store.
In a way, I think that by attempting NOT to use Core Data to handle your objects, you are destined to re-implement a lot of its functionality. Just use it.
You say that you are downloading a JSON that represents a given item; and you're using this item in your views, and then persisting it in a database. Core Data excels at this; take advantage of its full set of features instead of trying to avoid it.
(And, again, using mogenerator will be very helpful, although it is certainly not required).
Matt Gallagher has a nice blog article about the differences between Core Data and a database - I suggest that you read it, it's valuable information.
Cocoa With Love: The differences between Core Data and a Database