1. Introduction

Core Data

Core Data programming is hard. Apple warn as much in their document Core Data Core Competencies:

Important: Core Data is an advanced technology that is not required for creating simple applications.

That doesn’t sound so severe but it does contrast greatly with the rest of the documentation that seems to suggest that iOS/OSX programming is made easy by all the frameworks and widgets ready for us to customise and use in our applications.

Certainly, at each major release of iOS it seems that we have less to do everywhere, with new APIs being released constantly that do for us what we would have achieved before using the lower-level APIs. A recent example would be TextKit, released as part of iOS 7: having wrestled with typesetting in CoreText before I am certainly grateful that kerning, ligatures, hyphenation, line-breaking, justification and pretty much everything else that goes into making text look good is now considered to be a basic element of the platform. For those of us who are more software developer than designer this is most welcome indeed.

Would that we could say the same for Core Data. It is without doubt a solid and mature solution for persisting and syncing your app data, including between iOS, iCloud and OSX, but it hasn’t (yet) had quite the same user-friendliness refactoring that other parts of the platform have had.

TextKit, for example, which makes life so much easier when dealing with text, is simply built on top of CoreText. In the same way, we have 3rd-party libraries like MagicalRecord and Core Data Query that can make working with CoreData significantly easier. The problem with using these libraries is that you are going to hit problems that are unique to your app and then you will be largely at the mercy of the available documentation and perhaps the support of the developers of the library you are using to abstract away the less aesthetically-pleasing parts of CoreData. Given how new RubyMotion is, that documentation and community knowledge is perhaps going to be somewhat thin on the ground.

A more robust approach would be for us to first learn the raw Core Data API and delve into its inner workings. We will then be well placed to benefit from the use of 3rd party libraries, and perhaps even to extend them or write our own.

RubyMotion

RubyMotion has the potential to greatly increase the speed at which we create software for both iOS and OSX. Not only that but I also contend that the quality of the software you create may well increase too. Thanks to an ingenious implementation you not only have access to every last corner of the latest SDKs, you also have access to the same language constructs in Ruby that make Rails as powerful and pleasing to work with as it is¹.

Core Data & RubyMotion

As you experiment with RubyMotion I think you will find that you are able to iterate more quickly than you could before, creating and customising your view controllers from the console and seeing the results live in the simulator.

You have perhaps already found though that when it comes to building an app that needs to store data that Core Data requires a prohibitive amount of boilerplate just to get the simplest of records saved.

So, you turn to one of the libraries that promises ActiveRecord-style ease of use, the ability to write model schemas just as you would in Rails perhaps, but what happens when you need to do something that isn’t documented? These 3rd-party libraries, which we will cover in this book, will accelerate your development for future apps but we’re also going to do our best to dive deep into Core Data itself and learn it in detail too–once you have completed this book a good way to advance your skills further might be to tackle some of the outstanding issues in their GitHub repositories.

Technical Notes and Bugs

This book has been written and tested with RubyMotion 2.32, with Xcode 5.1.1 installed on a MacBook running OSX 10.9.4.

Despite best efforts some bugs may slip into the text and code. There is nothing worse than code examples that don’t work–they can be a learning opportunity for the extremely positive-minded among us but to the rest of us they’re a source of wasted time. So, if you encounter major stumbling blocks or something just isn’t adding up please assume that it is my fault and not yours, either because there’s a mistake in the code or because I haven’t explained the concept well enough. In either case please drop me a line (stefan@haflidason.com) and I’ll puzzle it out with you.

Structure of this Book

Normally when you create an app using Core Data using Xcode you use the visual data modeller to define your data model. This produces an .xcdatamodeld bundle that contains not just your data model but each version of the data model. With this bundle, Core Data can automatically load the latest version and even perform the majority of schema migrations for you automatically. Then, to set up the Core Data stack itself you might use the boilerplate code which you can optionally have added to your project when you create it.

With RubyMotion though we are not only missing the visual data modeller but we have lost the option to add in that boilerplate Core Data stack-creation code too.

Thanks to some quality open-source libraries though (that we will review in this book) we need not worry though as in the following chapters we will learn how to:

• Model all of our data versions in a schema language much like that of Rails/ActiveRecord
• Set up a Core Data stack in 5 minutes and just two lines of code
• Access our entities as if they were (almost!) Rails models
• Evolve our data model using automatic migrations
• Set up an equivalent stack from scratch
• Set up and perform migrations manually, for when we need finer control.
• And finally, we will understand the limitations of all of the above.

All code from the book will be published here on GitHub. You will generally have a much easier time copying code from there rather than from the book. For the best learning experience however I would recommend typing out the examples to become familiar with each line as you progress. If you find a bug, please feel free to open an issue about it there.

The Principle of Minimal Magic

Those last three points are I think crucially important: there are lots of libraries out there that will help abstract away the complexity of frameworks like Core Data but when writing an app for the store you are bound to run into issues that are not (yet) documented online.

Our approach is going to be to make use of that magic on a regular basis and enjoy all the benefits to our productivity but to know how the underlying libraries work so that when we run into trouble we will be able to troubleshoot and move past it.

So without further ado, let’s dive into writing some RubyMotion-powered Core Data code!