Thoughts on MagicalRecord Wrapper Library for CoreData

I’ve spent the last few weeks in the “basement” of my house developing my next project – Slync app. While the process was very interesting and challenging at the same time, it is always worth it. I should probably write about that experience in my next post.

During that time, I started diving into Core Data in greater detail. Specifically, keeping local store and the remote database in sync (which can be a bit tricky).

Let me start by saying that Core Data evolved greatly over the past few years. This year, at WWDC Apple engineers talked about great improvements to the Core Data and iCloud integration worth learning about (WWDC videos) and some other great improvements. Nevertheless, the whole boilerplate code to insert objects into the store or fetching them from the store into the memory is still a bit tedious. This makes me think of an episode from Friends where Joey took part in commercials advertising milk cartons openers. “There’s got to be a better way…” – he said after spilling milk by trying so to open a milk carton. That’s exactly what I thought when I started integrating Core Data into my project.

The boring repetitiveness of Core Data boiler code led me to search for available wrapper libraries that would simplify creation and fetching of entities. There are a couple of those written by awesome developers such as Objective-Record, SSDataKit, MagicalRecord and others.

After reading up on available options and going through the example code, I decided to dive into MagicalRecord. Why? Well, besides obvious, there was something about how it was written that made sense to me. That’s not to say you’ll like it, it simply means it works for me. Saul Mora, the author of MagicalRecord, talks about what made him write this library in greater detail here.

Let’s talk a couple of simple examples now.

When you check the “Use Core Data” checkbox when creating a new project, Xcode will add Core Data stack to your AppDelegate. It looks something like this:

You need the stack initialized in order to use Core Data. There is no way around that. Now think about a project you created without checking “Use Core Data” checkbox. You get the point.

Here is how you would initialize Core Data stack using MagicalRecord:

That assumes your Model is named with the same name as your project. If not, you can use a method to specify the model name. Really, really simple.

Let’s talk about creating entities. Here is how you would add a new entity using MagicalRecord:

The above code assumes your entity has two attributes, the name of the person (string) and age (int16).

Let’s assume you want to fetch all objects from the store. MagicalRecord makes it super simple:

Instantiating NSFetchedResultsController is even more awesome. The conventional way of instantiating an instance looks something like this:

Here is how you would accomplish exactly the same thing using MagicalRecord:

How awesome is that? This alone made me fall in love with MagicalRecord from the beginning.

I know I only brought up a couple of examples, but they should be enough to show you how MagicalRecord simplifies developing with Core Data. You can find the official documentation on website and follow @magicalrecord on twitter for the latest news and updates.

Thoughts on MagicalRecord Wrapper Library for CoreData

3 thoughts on “Thoughts on MagicalRecord Wrapper Library for CoreData

  1. Natan Rolnik says:

    Indeed, Magical Record is fantastic for using CoreData. Although, I think that a good knowledge on CD is needed in order to start using it, you should have coded before in pure CD to understand what MR is doing behind the scenes. For example, I get bugs using MR that I only know why they happened because something similar happened with CD.

    1. Michael Babiy says:

      I agree completely. Understanding of Core Data is required to appreciate MagicalRecord as well as being able to debug your code if something goes wrong.

Leave a Reply

Your email address will not be published. Required fields are marked *