Question

I am developing an app with a master-detail interface which displays a list of products that the user can drill down into. On initialisation, the app loads summary information for (1000+) products from a web service and displays it in a table view. When the user selects a particular product, the app calls the web service to get detailed info for that product and displays it in a detail view.

I want to persist this data between sessions using the Core Data framework.

I can think of two approaches for modelling this data.

1. Use a single Core Data entity Product containing all attributes for this object. When the table view is initialised these entities are populated with summary data. When a particular product is selected, the remaining fields are populated for that product only.
2. Use two Core Data entities, ProductSummary and ProductDetail with a summary/detail relationship between them. ProductSummary contains the attributes that are loaded by the table view. ProductDetail contains the attributes loaded by the detail view.

What are the pros and cons of each option? Option 1 certainly looks easier to code, but am I storing up memory usage problems for later? Would performance be equivalent?

Answer 1

With as many objects as you are going to have, go with option 2. Keep the data coming in and the attributes of the entity down to only what you need to display in the TV. Set up the relationship to detail and load that when the detail VC comes in.

I am doing something similar except with ~4500 rows. I only store what I need and then turn to the other entity for detail relating to the object.