I have an application that tracks a user and shows where they've been using MKOverlay. How can I save this information into Core Data so that when the user wants to see where they went yesterday they can load the map/overlay from Core Data?
I have a similar project. Mine is for cycle paths. Here is how I structure my core data model:
I use an order parameter so I can work out how the points connect up. But i think you can just check the 'ordered' property of the relationship now although im not entirely sure how it works. The min / max attributes are for more efficient searches. I store the lat long values as integers to save space after a suggestion to one of my posts. You might find this useful too.
You probably want to add some attributes to the Way such as Date.
You can save any object in a core data model, but if they are not the default type like string, int, etc. you won't be able to query on them.
So you have to construct your entity with property that you will be able to query.
So I see 2 options, you save every information in an entity, but this way you will need to alloc again all objects.
Or you only save the property you will need to query and archive your object in a transformable or in a Binary Data property.
I don't know what would be best.
Related
I have an entity, and I want to fetch a certain attribute.
For example,
Let's say I have an entity called Food, with multiple attributes. I want to select all categories, which is an attribute on each food item. What's the best way to accomplish this in Core Data?
Just run your fetch request and then use valueForKey: to extract all of the attribute values. If your model contains lots of objects, you can set the fetch limit and offset (and sort descriptor) to page through the items. When doing this you should also set the fetch request to not return objects as faults.
Just remembered there is an alternative. You can set the properties to fetch and then set the result type to NSDictionaryResultType. You still need to do the iteration but this will return the minimum data possible.
EDIT: I think I misunderstood your question. It seems that you only want to fetch a property of an object, not the object itself (e.g. the attribute but not the entity)? I don't believe core data is going to work that way...it's an object graph rather than a database, as the person above mentioned. Research how Core Data "faults", automatically retrieving dependent objects as they are needed. I left the advice below in case it still applies, though I'm not sure it will.
You can add a predicate to your search in order to fetch only objects which meet certain criteria; it works like an "if" statement for fetching. Here's Apple's documentation:
https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSPredicate_Class/Reference/NSPredicate.html
And a tutorial:
http://www.peterfriese.de/using-nspredicate-to-filter-data/
All that said, the necessity really depends on how many objects you're fetching. If it's not causing any performance hit, there's not necessarily anything wrong with fetching a few un-needed objects. Solve problems, in other words--don't "optimize" things that were working fine. If your model contains a ton of objects, though, it could be expensive to fetch them all and you would want to use a predicate.
You can only fetch whole objects, but you can only fetch objects that have a perticlar attribute using nspredicate in your fetch request. See the code snippet in Xcode in the snippet section. Look for fetch request in the find field and drag out the snippet with the nspredicate code. You can set the predicate to only find the objects that satisfy this predicate. Hope this helps!
I am at a real loss.. For the past two weeks I have been working on fine tuning the way data is parsed, displayed and held in my app.
I have two view controllers, the first has four tables that when selected load a uitableview full of data that is parsed from an xml file. each xml file is different but have key fields that relate to each other. I need to speed up the way I display this data in the uitableview as when I do my second search when I check my ManufactureID against every single modle avalible to all manufactures.. it take a considrible amount of time to load.
I would like to do this behind the scenes before the view is even about to load and I have heard the best way to achieve this will be to use core data.. but I am not sure how to get this to work with the way I am doing things now.
If you have any examples, suggestions or anything that might help me I could seriously use someones input right about now as I am just abit stuck. For instance how do I get the data that are in my .xml files into the coredata? how to I create the relation ship ID's? etc.
First off, is there any reason to keep the information in XML files? Everything will be a lot easier (and faster!) if you just move it all to a CoreData datastore from the start instead of parsing/preloading everything to an in-memory store at launch (or whatever).
As to how to model your relationships, you could always set your CoreData model to exactly match your XML data. So, say, one Entity per file and one Attribute per record in said file. There's no reason you have to use CoreData Relationships to model the relationships in your XML. If you have IDs in the files already, just make an Attribute called xmlId or something and fetch based on that just like you were doing a SQL query. You'd miss out on a lot of automatic ORM-ness of CoreData, but if you've been dealing with XML this whole time, I doubt you'll notice.
If you really want to set up the relationships between your CoreData-managed objects, you'll have to somehow match up objects by their IDs in the XML either by importing the IDs into CoreData and then doing the math, or by somehow taking care of this when you parse. Hard to give any specific advice here without knowing more about how your data are modeled.
There's some sample code that does half of what you want (it reads XML into a in-memory CoreData store, but doesn't model any relationships). Check out TopSongs (http://developer.apple.com/library/ios/#samplecode/TopSongs)
I am searching 350 dictionary objects. Would it be more efficient to store the data in Core Data or a plist for searching?
Basically, each object is a dictionary with 8 key-values. The 350 objects are stored online in a JSON feed. I would like to download the feed when the app first launches, and then store the data into either core data or plist. In the app, there is a table with several object as default. A user is then able to add/delete these items. When a user clicks add, I want to display to the user all of the 350 objects, as well as provide a search mechanism.
In that case, should I store the JSON feed into a Plist or using Core Data?
It depends. If you aren't running into an actual performance issue, do whichever is more readable and appropriate for your application. For example, if you are saving data for which the user can add records of some sort, core data handles common situations for that and can be used with a fetched data controller to manage a table quite smoothly. It can also easily bind to your object model so you don't have to do key lookups.
If you have a reasonable amount of static data or editable values to a static list of keys and you always need to load all of it, go ahead and load a plist for convenience. Post more information about your specific situation and I can update my answer.
UPDATE:
I think you'll probably want to use Core Data for a few reasons. First, if each of these objects have the same 8 keys, you'll want to represent each one with a bound object instead of a dictionary. Second, Core Data is meant to be searched, sorted, and filtered. Third, with NSFetchedResultsController it isn't much harder to bind it to a table (with right indexes) or scroller selector. If you name the properties of your NSManagedObject the same as your 8 keys, it'll be pretty easy to load from JSON as well using KVC.
You could use a plist, but will have to do more leg-work.
As with many things in life, it depends. I would say a plist would probably be fine as long as the data is not too large to keep in memory. Also, if the data is static, I would lean toward plist. CoreData is better if you have a lot of data or a lot of related data objects and that data changes over time.
Based on your edits. I agree that Core Data is the way to go. Whenever you are adding/updating/deleting/sorting/searching/filtering data on a frequent basis, I prefer Core Data and that is Apple's recommended method as well.
I am working on an iPhone app and have an entity set up in coredata that has two attributes
text
order
The user can take a photo for each object in the entity. As a proof of concept, I am saving the photo using the entites 'text' attribute in the documents folder.
I tried getting the object ID using: [object objectID], but that gives me a string full of guff, eg:
<x-coredata://791282FC-9A08-451F-9348-1B972E8A144D/Articulation/p5>
My idea was to add another attribute 'id' to the entity that autoincrements and use that id as the filename of the photo (there will only ever be one photo per entity).
Is that considered bad practice? And if so, what should I be doing?
Thanks,
James.
I would create an attribute imageFileName in the entity, and store the file name of the image there.
That way, you can implement what you want to do now (by autogenerating imageFileName by incrementing an internal counter),
or you can let the user name the image, if you later change your mind.
It is non-trivial to change the CoreData schema once you ship your app. So I prefer to keep a bit of room in the schema so that I can change the behavior of the program without changing the schema.
This is a good question. I'd consider creating some sort of uniqueId property that you can use to identify the object as well as generate filenames etc.
Here's a link with a previous question that can point you in the right diretion: https://stackoverflow.com/questions/3005688/how-to-auto-increment-reference-number-persistently-when-nsmanagedobjects-created
I have a one to many relationship between two objects, lets call them Gallery and Images.
Each Image belongs to a Gallery and each Gallery has many Images.
I would like to add a fetched property to my Gallery model which would return one and only one Image object.
Is there a way to do this with fetched properties?
For a fetched property, a predicate is your only option.
See the Predicate Programming Guide - Aggregate Operations section. You'll want to use array[FIRST].
Note, you'll likely get a different image each time, since there is no support for ordered sets in Core Data. You'd normally get around this by maintaining your Images' sort order in a "sortOrder" key and setting sort descriptors on your fetch, but I don't think it's possible to give sort descriptors on a fetched property.
Update for Lion: Support for ordered sets has been added to Core Data in 10.7 and above, making an extra "sortOrder" attribute unnecessary for apps targeting 10.7 and up.
A fetched property is represented by the NSFetchedPropertyDescription class. You can modify properties in code up until the point when the managed object model is actually used. So, in the code that loads up your managed object model, you can find your fetched property description and replace the fetch request with something that better matches what you're trying to do. You should be able to set a fetch limit on it in this way.