0
votes

i'm refactoring my app. Currently, I store objects in a .plist for further processing. It works fine, but I thought it was about time to dive into CoreData.

My app fetches data from a web service. This data I parse into individual objects. I use the properties of these objects to fill Tableviews.

While refactoring, I could just bluntly store the whole object as a transformable with CoreData, as far as I understand.

I could also define an entity with attributes similar to the properties of my object.

Is there any Best Practice here? I think the first approach makes it easier to do the refactoring, but I somehow think I'm missing out on advantages of CoraData in that case. Like maybe performance?

3
From performance perspective the best practice is as few data processing as possible while displaying data. - vadian

3 Answers

1
votes

Do not store objects as transformable. You will get just DB where it is not possible to fetch some separated objects based on some criteria. You will need to fetch all DB in memory and than work with it. So it will be the same as plist file and you will waste the effort. Just use entities with proper attributes. CoreData is fast, you don't need to worry about performance.

0
votes

Transformables are generally a good idea only for attributes that Core Data doesn't know how to represent. They let you use a binary data blob as a fallback, but they're never ideal. They can also be used if you absolutely, definitely, will never ever need to filter or sort a fetch request based on the attribute value. In that case they're still not great, because there's extra unnecessary work.

If you need to (or might possibly someday need to) filter or sort a fetch request based on attribute values, don't use a transformable. They can't be used for either purpose beyond extremely basic stuff like checking to see if the value is nil.

0
votes

OK, I owe you. I asked a question without investigating things properly. The real answer is to understand NSManagedObjects. Sorry for bothering you