Data models using structs (value types in general) - How to keep everything in sync? - swift

I hope this question is not too generalized or broad. But I've been trying to grasp this concept for the past week and I don't make any progress. I've read dozens of articles and answers on StackOverflow but nobody seems to address this properly. Everyone is always using the most basic models that don't intertwine at all (see example). It might just be me being stupid.
I'm really struggling with understanding how a good data model works and how to implement it into an app. I want a method that is consistent and convenient throughout the app. I have an example.
Let's say I want to create a data model like this:
struct Person {
var name: String
}
struct Car {
var name: String
var owner: Person // Link to a car struct
}
struct Garage {
cars: [Car] // Array of car structs. Usage: Maybe a list view that shows all cars
}
This covers some of my big problems using structs as data models:
References between models - Structs are value types, referencing another model simply creates a copy of that model. Thus, I end up with multiple copies of the same data. What if that data changes? Or what if the reference itself changes (i.e. the owner of a car)? Observing a Car struct using, for instance, Apple's Combine framework doesn't really work because of this owner reference and the fact that it just is a copy of the original Person.
Arrays of models - This seems to be even more tricky. I have to decide whether I want to use the array as a whole (i.e. for a list view) or if I need to use individual elements (i.e. passing a car to a detail view). When trying to keep everything synced it seems like I have to choose one of the two. Doing both at the same time looks impossible. I could create two separate models, each for its own use case but again, I end up having multiple copies of the same data. It just doesn't work.
(To make it more clear: What I mean is I always have to decide between Observe([cars]) and [Observe(car)]. Doing both doesn't seem to work.)
How would I use this data model inside a project with multiple views like a "CarListView", "CarDetailView", "PersonDetailView", etc. without ending up with dozens different copies of my data that are all different?
I really want to use structs because the code becomes so simple and beautiful. But it just seems to be really annoying and partially impossible. However, wherever I go people advice using structs over classes in most cases. The example looks like a fairly basic and normal use case. Is it not suitable for struct usage? Am I just stupid?
I'd be extremely grateful for any insight on this topic. This is driving me crazy.

Related

NSManagedObjectID vs custom UUID identifier attribute - fetch performance

I would really like to avoid using NSManagedObjectID as a way to connect my model structs to their CoreData objects. I mean something like this:
Say I have a Book entity in CoreData and then I have a model struct like this representing it for my model layer:
struct BookModel {
let name: String
...
let objectID: NSManagedObjectID // I need this to refer back to the entry in the database
}
I don't like this approach. It makes working with the structs tedious and, for instance, testing is annoying because I always have to generate dummy objectIds or make BookModel.objectID optional.
What I would love to have is an id property of type UUID inside the Book entity. This would be so easy to connect to structs and also allows the structs to properly exist without a database:
struct BookModel {
let name: String
...
let id: UUID
...
func object() -> Book {
// Retrieve managed object using a fetch request with a predicate.
}
}
I've noticed that you can actually have UUID properties in an entity. However, the performance difference seems to be enormous. I've created an example that tries to fetch individual objects 10000 times.
First, I fetched them using the contexts object(with: NSManagedObjectID). I hard-coded all the possible objectIds in an array and passed a random one each time.
Then, I used a simple fetch request with a NSPredicate that got passed a random UUID.
The difference in execution time is significant:
With ObjectID: 0.015282376s
With UUID: 1.093346287s
However, the strange thing is that the first method didn't actually produce any SQL queries (I logged them using the launch argument -com.apple.CoreData.SQLDebug 4). This would explain the speed but not why it doesn't need to communicate with the database at all.
I researched a bit but can't really figure out what object(with: NSManagedObjectID) actually does behind the scenes.
Does this mean, using a "custom" UUID property is not a good idea? I would really appreciate any insights on this!
I would not rely on the NSManagedObjectID in your code. It makes your code dependent on Apple's database implementation, which may change at any time, and it would not make your app resilient against future changes.
By way of example, you would not be able to use the new NSPersistentCloudKitContainer. It does not support NSManagedObjectID: see https://developer.apple.com/documentation/coredata/mirroring_a_core_data_store_with_cloudkit/creating_a_core_data_model_for_cloudkit
Instead of hardcoding NSManagedObjectID you are better off giving your entities unique UUIDs, as you have suggested. This may or may not affect performance, but you are better off in the long run, as the underlying core database technologies will shift.
You should just use a String to represent the NSManagedObjectID. To convert from NSManagedObjectID to string is easy:
objectID.uriRepresentation().absoluteString
To convert from String to NSManagedObjectID is slightly more complicated:
if let url = URL(string: viewModel.id),
let objectID = context.persistentStoreCoordinator?.managedObjectID(forURIRepresentation: url)
This will make your model objects cleaner.
NSManagedObjectID is good to be used within one application on one device, but it should never be stored and referenced across different applications on different device. I think it is not true that NSManagedObjectID is not supported for CloudKit.
As per why object(with: NSManagedObjectID) is fast. The document says it returns:
The identified object, if its known to the context; otherwise, a fault
with its objectID property set to objectID.
This means that if the object has been loaded before, it will return it immediately, if it has not been loaded before, it will return a fault. If you want to trigger a SQL to happen for a good comparison, you need to access one of the attributes after you call object(with: NSManagedObjectID). I would assume the performance should be very similar to the one using UUID.

How do I manage models & views in an iPhone app?

I have a bunch of model objects that inherit from NSObject (Result). And I have a bunch of view objects that inherit from UIView (ResultView). They exist in a 1:1 relationship (one model for one view). In my controller I have an two arrays: one for Result objects and one for ResultView objects. The controller displays many of these result views and they can be added/deleted/reordered. Trying to keep 2 arrays in sync (results & resultViews) isn't working out. How should I approach this problem?
I'm considering initializing a view object with a model object (eg: an initWithResult: in my ResultView class and then retain a pointer to the Result object in the ResultView). Then I could do something like ResultView.result to access model data. Is there a better solution? This would break MVC, wouldn't it?
Unless you're trying to persist these model objects in a DB or something similar, I would put a view property on the model objects. If you don't have to create the view for any reason, then just nil it out to save on memory.
Does it break MVC? I guess. But if your model objects will always have a view associated with them, it starts to go into the blurry line area. No programming god will send you to hell for breaking the standard a little bit.
Do what's clean, optimal, and easiest for another programmer to understand when looking at your code.
Ok, if I understand your question correctly, the model objects are persistent while the views are dynamically created/deleted. You are relying implicitly on the index of the two arrays to achieve the mapping of two parts. One simple way is to add a "model object id" in your view class. Then you can easily reference to the correct model object in the view.

Sample code illustrating MVC architecture in iOS

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.

Core Data: Inheritance, STI or otherwise?

I can't seem to find any information in the documentation or via Google on this, but if there is something, a pointer to it would be great.
In my app, I have a Thing as a core data class. I intend to have that Thing contain many Items which has a bunch of fields in it, like order and created_date and so forth. However, there are a variety of Item types, each with their own set of fields. Ideally, I'd like to create several subclasses of Item, so that I can access all the items together in a single array or something.
In Rails, I'd use STI for this. Does Core Data support similar behaviour?
Thanks!
You can create an Item abstract entity and then have each of your unique items extend from it. Keep the relationship in the abstract so that your Thing can see all of them.
Be warned, however, that under the hood, all of those children will actually be put into a single wide table so you will need to test for performance considerations.

Modelling entity types using Core Data

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.