Core Data in Motion

July 9, 2013

Updated June 5, 2015.

Recently I was starting a RubyMotion project, mostly as a learning experience and discovered, right from the get-go, that I had a problem. My chosen project, to convert my WIMBY (Wells In My Back Yard) web app to a native application seemed like a straight-forward idea, but I had not taken into account some challenges.

Like the fact that 244k abandoned wells (just the abandoned ones, the entire dataset is over 750K) is a very large dataset for an iOS app. So large, in fact, that Core Data was just about my only option.

After searching and reading, and reading and searching, I came to the following conclusions:

  • There are lots of RubyMotion DSL’s and gems for modelling data, but none really gave me all that I needed

  • I didn’t really understand enough about Core Data to be confident about attempting changes/enhancements to said gems and DSL’s.

At that point I just decided to take inspiration from @kellabyte, suck it up, dig in and learn Core Data, and figure it out for myself.

It’s been an interesting couple of months (this is a project I am doing on the side). I’ve learned a lot about Core Data, and I still have a few more things to figure out. But I have successfully:

  • Created non-trivial Core Data models in code, with RubyMotion

  • Implemented relationships between models, in code

  • Pre-loaded my huge dataset

  • Learned multiple different techniques for optimization, so that I could efficiently display my wells on maps, and show them in lists

I’ll be posting about once a week on each of these topics and reviewing what I learned. I hope you will find it interesting.

If you, too, need to use Core Data with RubyMotion, you will find that the ebook I wrote on these topics (and more) will save you hours, if not days, of research and frustration.