I have my first iOS app with Core Data, and there is an Entry entity. Entry has the attribute called "Tag" and it's NSString.
So now when user created a new Entry he can put any string into Tag field and it will be stored in Core Data as NSString, which can be used later for search by tag.
The thing is I want to implement multiple tags feature in my app and I can't figure out how to do it, what's the correct design for cases like this in iOS, considering using Core Data.
For example, if someone wants to create an Entry and give it tags like "food", "groceries", "apples". How should I assign all of them to my property of Entry entity? How should I store them in Core Data? As a separate entity Tags with unique ids? How should I retrieve them and how can user edit multiple tags for an Entry?
Thank you in advance for answers.
There are 2 common ways to do that.
the simplest one is to store comma separated tags in your NString. (but you won't be able do filtering and other operations involving tags)
Create another entity - Tag with name and id. And have many-to-many relationship (assuming one tag can be used by several entries)
a good explanation on how to do that is given here cdrelationships
you can do it in multiple way. You could just separate your tags with the character of you choice and just split the NSString in you code to retrieve your tags.
Or, if you want to make things right, just use another entity to store your tag's IDs.
Use that tutorial
This will help you to understand core data.
Related
I want to be able to look through all the attributes of an Entity and find the most popular one. I know it has something to do with NSPredicate, but I can't quite wrap my mind around to achieve it.
One possible solution:
Fetch all the entities and loop through it and sort the attributes into different arrays, from there count the items in the arrays to determine the most popular/common one.
Although this might work I'm just wondering if there's an easier or 'cleaner' way of doing it.
Update:
Thanks #Caleb. Let me clarify, I'm looking for a single attribute value that's most often used by instances of a given entity.
That is really a dirty descision.
I would suggest you to make a new entity, say, AttributeCounter, with two attributes - name and count, and every time you add an attribute to a person, change this entity.
But that would only be good descision if you have a few different attributes and lots of persons. If not, here is another approach, that is quite simple:
Get all the enteties with first attribute not nil,count,add to array
Sort it
Here you are
I need to store an activity feed in an iOS application. Activity feed items will have a payload field which can be one of many (and I really mean many) types of entities in the system.
What is a good way to implement this payload relationship field on the Activity entity in my CoreData model?
Is it possible to use the id data type, or maybe use an NSManagedObject type?
One way to workaround this maybe to just store CoreData's entityId as a string in a special field, but I'd rather avoid that if there is a better way.
Example:
For simplicity let's say we have a not-so-standard blogging model: User, Blog, BlogPost, Comment and the following activities may happen:
User may create a new blog.
User may publish a new blog post.
A blog can be commented on.
A comment maybe liked.
etc.
Each of these generate a new Activity item on the website which in turns have a related payload relation to the item that was modified or being acted on.
Now I need to download, translate and store these activity feed items from the website in my iPhone application... so how do I mimic this payload field since it maybe pointing to any possible entity?
In my real code, though, there are about 10+ types of entities that could be put into this payload field so I'm looking for a good approach here.
If you don't need to search / query the fields of your objects of variable type, then I suggest to use NSCoder to convert them into a binary representation and store them in a BLOB field of your managed object. You might want to store some type information as well in an other field of the same managed object. On the other side if you need to search between these variable objects then you have to create a new managed object type (entity) for each object. See my answer also here: NSCoding VS Core data
Only thing that you can use is NSManagedObject. So you have to create your model and your relation and create new file for Activity and payload that will be subclasses of NSManagedObject.
Take a look at Core Data Programing Guide .
You will find your answers in there.
I'm trying to get the hang of MVC architecture. Say I have a plist in which there are a list of persons and each person has a few attributes like name, address and photograph. Suppose
I want to display these details in a table view. The cell title would be the name, description would be the address and the image towards the left would be the photograph of the person.
One approach I could take is to load the plist in an array-of-dictionaries in my viewDidLoad: and then display them.
However, I want to adopt an Object Oriented method by creating 'Person' class. How do I go about doing the same in this case? I believe I could start by creating a 'Person' class with three attributes:Name, Address, Photograph. What next? I would need many instances of this 'Person' class right? How would I 'load' each instance with a corresponding Person entry from the plist? Should I create another class that does this 'loading'? Do people use Singleton class to achieve his?
Could someone share some sample sample code to illustrate this? Or maybe guide me to blogs/resources that talk about this?
Hmmm, I think you are over thinking this a bit. I would just create a class that would handle my person, in this case your 'Person' class.
I would simply store each person using Core Data. Then, when it's time to display them, I would just make a fetch request and store all person managed objects into an NSMutableArray (which simply handles arrays of objects). Then you can simply use the index value to display the numerous persons in your array in a tableView.
In summary I would:
1. For every person, create instance of Person.
2. Verify if person exists in my Core Data Person Entity.
3. If not, then insert into Core Data (the object will become an
NSManagedObject).
4. For displaying, simply do a fetch request to pull all persons in your
entity. Here I prefer to store the
results into an NSMutableArray, but
that is completely up to you. Make
sure you release your fetch request
after the results are store in the
array.
5. Reference them to your table view using the index value for each
person NSManagedObject in the array.
For something that doesn't involve storing simply:
1. Create instance of Person for every entry.
2. Add Person object to array.
3. Reference each Person to table view using index value.
In the end the approach that you take will be dictated by what you want to do with the information.
As for reading the plist, I would opt for reading an XML for which all you need is an XML Parser class (there are several options for parsers). Since I don't do anything but parse the XML, I use NSXMLParser, but that choice is also up to you. Just create an NSXMLParser class (make sure that the different actions for when the parser finds a given element are in play inside that parser). So yes, you would need to make additions to the NSXMLParser for handling each element. It's really easier than it sounds.
Also, by storing in Core Data, you can always fetch the info without you using a Singleton.
I believe you are not looking for a design solution to the above mentioned question. If that is the case #A Salcedo 's version looks fine.
if you are looking for general guide lines for MVC and modeling , Martin Fowler's site offers some of the best (agile) design/modeling guidelines.
http://www.martinfowler.com/eaaDev/uiArchs.html (on MVC) and
http://martinfowler.com/design.html (many interesting design related posts).
Happy reading.
I am new to Core Data and trying to think of the simplest and / or most performant way to implement a tags feature for items in Core Data. I am still wrapping my head around the fundamental differences between core data and the sql server I am used to.
Has anyone done this? Or have any suggestions of a solid implementation for this?
I would assume I have 2 options:
A separate entity for Tags, each
containing a tagName and a
relationship to the items that that
tagName applies to.
Store tags in a attribute on the item itself and search those.
Seems like option 1 above would be the best for solution.
Yes, you want to do 1, I guess with a many-to-many relation since an item could have many tags and a tag could belong to many items. It would otherwise be great to store it in attributes, but Core Data does not support composite attributes (e.g NSDictionary, NSArray), it only supports primitive attributes (integer, text etc).
I'm working on my first app using Core Data and I need to assign a type (with an associated name attribute) to a couple of entities.
Below is my object model so far.
The room and item types will be updated from time to time over the network.
Is this the best way to implement this using Core Data? Thanks :)
Edit: To try to explain better: for example, rooms may be Bedrooms, Kitchens etc. Items can be Aircon, Security Camera etc. The only difference between the different room and item types is the name text. The list of valid name texts will be updated so I don't want to hard code it in the app. Also, the user can create multiple rooms and items of the same type, which is why they are numbered (roomNumber,itemNumber)
improved Core Data Model Image http://img42.imageshack.us/img42/8458/picture6c.png
Nick, try and avoid the temptation of thinking of Core Data as a database. Design your model from the point of view looking at using the objects in your code.
i.e. your relationship properties are collections (or singluars) of the related thing.. you should rename the relationship JobLocation.JobLocationToRoom as just JobLocation.rooms
And yes, using Core Data will be quite straight forward, but it's hard to give you a definitive answer with such a vague question.
Perhaps my question wasn't clear, but I found the answer in the Apple iPhoneCoreDataRecipes demo code
The relationship I wanted to model is similar to Recipe -> RecipeType.
In addition to the other answers, you don't need to model separate ID attributes. Core Data managed objects automatically have managed object IDs that are handled for you entirely behind-the-scenes by the framework.