I have a coreData model where I have an Event table and video, text, audio, image tables that have a many to one relationship with the event table.
In my app I have a rootTableViewController class that displays all the events. selecting an Event cell brings up a detailTableViewController that would display all the associated text, video, audio and image objects in the UItable. Objects should be sorted chronologically so there might be a mix of all the different object types in the table.
my question is: Is this possible to do this with a UItableView?
Is it better to fetch all the objects in a NSMutableArray, then sort the array and use it as an input for CellForRowAtIndexPath.
I was able to do this with a UIScrollView (without coredata). Inserting different views based on the object type; but i thought using a UITableView is better suited for data management.
Thanks a bunch for any help provided.
You generally only want to bother with fetches when you don’t know which managed objects you are looking for. If you have a managed object but need other related objects, you just walk the relationship graph instead of fetching.
In this case the rootTableViewController had the
Eventobject selected by the user. When it loads the detailTVC, it can pass it theEventobject. The detailTVC can then ask theEventobject for all its associated media objects. You can then sort them into an array anyway you wish.To display each media type, create a custom tableview cell for each type and load that cell when the index points a managed object of that type.
An additional word of advice. This is wrong when you say:
Core Data is not SQL. It does not have tables, rows, columns etc. Instead it has entities (abstract) and managed objects (concrete). Relationships connect entities in the model and managed objects in the actual live data. This is called an object graph and the main point of Core Data is to managed that graph. Unlike SQL, it really doesn’t care how or even if the graph is ever persisted to disk.
Thinking of Core Data in terms of SQL always leads to grief.