Most efficient way to save object references in iOS?

Question

In the application I am working on, I have a note object. This note object can have one super note and many sub-notes; essentially, I am creating a note hierarchy. The way in which it functions is actually very similar to UIView.

Anyhow, I need to be able to save this data. I've worked with Core Data and understand that you can create relationships between particular objects and each of these managed objects can have primitive properties (excepting transformable types). However, I am unsure whether creating a relationship between a note, its superview, and its subviews is the most practical-or even possible- way to do this.

That being said, I wanted to get some perspective. If I have to save an array of notes, and many of these notes have references to each other (in the same way that views do), what is the best way to do this?

Answer 1

Here's how I would do it:

1) Use Core Data and (optionally) Mogenerator. Especially as your app's functionality continues to grow, you'll be glad you did.

2) Create a Note entity in the data model.

3) On the Note entity, create a to-many relationship, called notes, that points to Note (to itself) with an inverse to-one relationship, called parentNote. So, you would have a two way relationship like this:

parentNote <<---> notes (meaning: one parentNote and one or more notes)

Point of interest

As you mentioned, UIView does something quite similar to this. Basically, each UIView has an array of subviews and each subview references its parent view, superview. So you have this two-way relationship on each UIView:

superview <<---> subviews

Screenshots per request:

Note entity showing the relationships only:

The notes relationship:

The parentNote relationship:

Also of interest are the delete rules - I'd recommend you set cascade on notes and nullify on parentNote relationship (this would imply that a parentNote owns its children notes, so when it is deleted, they are too). However, make sure this is the behavior you want.

Answer 2

You need to distinguish between the Core Data Note entity and the views. So typically you don't create a relationship between the Note (and I am assuming this is the Core Data Note object or record) and its super and subviews.

Your MODEL represents the relationship between the Notes(containing text and/or images) and if it's a hierarchy then a Note can have children and a parent. If it's something more complex, because you want to link Notes on different branches of the hierarchy, then you need another linkedNotes relationship.

I have an couple of App's that do the former (maintain hierarchies of rich text notes plus some data fields) - see screen shot showing the hierarchy of Folders and Documents (using the same Core Data entity for persistence with a single flag indicating if it's a folder or not, if it's not a folder it can't have children but this is not enforced by the database, it is enforced in the application logic). The hierarchy below is infinite and Core Data maintains these references, nil parent means its a root node.

With regard to the views for actually displaying each Note, that depends on what you are trying to do. In the app below there are two views, one shows the hierarchy of documents and the other shows the detail of the selected document. The hierarchy allows the user can drag and drop items or a whole branch (of items) or copy and paste them into another document or section, the detail view allows editing of the item.

The app logic associated with the UI manages maintaining the state of the relationships between the Core Data objects as a result of these user actions. However Core Data is used to save the state, including if a folder is expanded or not.

There is another iOS app that uses this exact same document (Core Data store) to present the same information on the iPad or iPhone (using different views depending on the device and orientation of the device). Navigating the hierarchy is done using different UI Controls (UITableView) on iOS but again objects can be moved around in the hierarchy and the associated changes in the relationships are maintained and persisted by Core Data. With iCloud synchronisation any such changes get replicated across to other devices running the same app and these changes get reflected by the UI on the receiving device once they have been imported by Core Data.

So is this the most efficient way to save object references and maintain relationships, my guess would be yes, because a lot of the integration with UI Controls is already done for you, you get cross platform support and you get iCloud integration.

EDIT: Happy to post some code examples if you think this is what you are trying to do. The Core Data model and the NSManagedObject subclasses might help you get your head around the Model.