On Core Data, JSON, libraries...

After watching a hangout talking about Core Data, JSON an some open source librearies I thought that it will be good to publish a blog post with some personal notes and opinions.

Here I talk about things that were talked in the hangout and about some things that I have in my notebook or in my mind.

You can watch the Hangout (in spanish) Estrategias de sincronización de datos JSON/Core Data

• I've never used Mantle in production. I tried to use it in a couple of occasions but in the end it doesn't fit my needs. It's true that it does a lot, but not exactly the things that I want.
• It's worse when you try to use Mantle and Core Data together. Yes, it's possible, and people are using this approach, but at the end if you want to use Core Data, USE Core Data.
• I keep earing that people use Mantle for mapping JSON to NSObjects and NSManagedObjects. Mantle IS NOT a mapping layer, IS a model layer. Personally, I don't like to introduce this huge dependency in my projects just for the mapping. Besides, if we have a really cool native model layer as is Core Data, why not use it? Well, maybe you don´t like it :P
• So... If you don't like Core Data, of course, use Mantle ;)
• If you are looking to solve your mapping problems use a mapper. I like to write my own arquitecture and use a thin mapping libray to make my job easier. I recomend [KZPropertyMapper][2] because you can use it inside your init methods without adding any hard dependency. You can change easily your mapping without changing the API of your model layer (more). It doesn't matter if your objects are from CoreData or PONSOs, because it's only a mapper! You don´t need anything else.
• I'm surprised to see how the people talks about consuming APIs and syncing with Core Data as if it was something new. I think that this problem comes from the habit to use open source frameworks instead of writing our own code. I'm a really big fan of open source libraries but for thinks like this I prefer writing my own code. I´ve been writing Core Data and sync code since my very first application, so this is not new. Of course there is a lot to learn still, but I highly recommend to write your own code before looking for some third party library. Seriously.
• When I'm dealing with any data processing algorithm I always remember what a university teacher told me: "sometimes it's really good to pre-process data". So think about it (ordering, creating mappings...).
• I think people is afraid of CoreData and they look for answers in other frameworks that has other difficulties. Learn Core Data, is worth it. It's better to know the native technology before some third party library. Yes, it's not easy, but it's a really cool model layer. Once you know it you will be using it everywhere (at least I really like it :P).
• If you aren't interested on the properties of the objects that you are fetching (for example in deletions) you should use setIncludesPropertyValues:NO.
• If you are fetching CoreData just to know if a managed object already exist use ´NSManagedObjectIDResultType´. It's the only think that you need to compare managed objects.
• A good think that I was really happy to see on the hangout is the use of the visual tools that Apple provide us. Not only we can use IB to design interfaces, we can also use some features to make our lives easier. Look at user runtime attributes, they are very cool ;) I use this feature a lot with custom views but you can also use it in the Core Data Editor.
• Core Data allows you to do entity inheritance. At the end what it does is putting all the entities in the same table. Some times this is not good, but you have to remember that "entity inheritance != class inheritance". They are not the same thing. You can have different entities in Core Data that share a common class in your code.
• Transformables may be good for some things but you need to know the drawbacks. It stores the data in binary blobs and executes the transform operation every time you do a fetch. Take that into account.
• It's fine to use Core Data in main thread by default. Of course the are things that you already know they should go on a background queue (parsing, big inserts...), but you can work on main thread until you see some performance issue. Then you can complicate your life, but not before ;) Avoid premature optimization.
• I know some SQL people that prefer to not use relations or joins due to performance issues. I think it's a good thing to look at but if you are using CoreData use all it's power. Embrace relationships, they are powerful.
• Avoid accessing a global NSManagedObjectContext. Give the context to the objects that need to acces the database. Or better, use private contexts when you need it. And remember that you have acces to the context from any managed object, so if you are passing managed objects around, you already have the context.
• It's fine to use the classic stack configuration, it works and has a good performance.
• I prefer a more modern stack: private (with acces to the store) > main (UI) > short lived private context for specific actions.
• Always use tiemstamps for dates, there is no need to use another format, unless you want the server to control the views of your clients.
• If you are doing sync with the server just remember that you can't trust the clients (clock, auth...)