ITAP: Inca Trail edition

Somewhere in Andes

FRCoreDataExportOperation

Core Data is possibly one of the most useful frameworks in iOS. People have different feelings towards it, but i'm a solid fan. One issue that i'm sure everyone has had with core data at one point or another is getting data in and out of Core Data. This ultimately led to creation of the FRCoreDataOperation project.

A few months ago I started using FRCoreDataOperation to serialize Core Data objects to disk. Sure you could do this with plists, but thats a little too restrictive especially if you want the serialized data to be compatible with other applications and platforms. Usually my format of choice is CSV, as you can import it into excel/ google docs easily, also python has a great module for loading CSV data.

For another project I found myself needing to do the same thing again, the classic sign that it was time to do make something reusable and adaptable. So FRCoreDataExportOperation was born. FRCoreDataExportOperation is a concrete subclass of FRCoreDataOperation and can be used without subclassing. Below is an example of how you use the class.

There are a series of initializers that you can use in tandem with the class, but the one you'll probably most interested in is below.

As you can see by using a predicate and sort descriptors along with the entity name you can select the objects you want to export. The export operation also supports relationships, it's not completely recursive, and will only explore entities that have a direct relationship with the entity you specified.

The next step is to select a formatter, the actual serialization format is completely abstracted from the class and is performed by the object assigned to FRCoreDataExportOperation's entityFormatter property. Thus far i've only created the FRCoreDataEntityFormatter, FRCSVEntityFormatter, but you can create your own by implementing the FRCoreDataEntityFormatter protocol.

The FRCSVEntityFormatter is somewhat customizable, and allows you to specify a NSArray with the  keypaths that you want to be serialized to disk. The columns will be written in the order they appear in the array. If you choose to use the formatter without a whitelist, all of the properties will be written in the alphabetical order of the property name.

Best of all you can get this for yourself via Cocoapods, pod is aptly called FRCoreDataOperation

Happy exporting

Stars!

During a chat with some of my colleagues I remembered one of my favourite games, Stars!

The concept was simple, you start with a single planet, and then expand across the universe, encountering new technologies and races as the years pass. In many ways it's a fantastically engineered game. It's UI works just as effectively at 640x480 as it does at 2560x1600, It never crashes, it uses a small amount of memory and turns are quick, even with a 33Mhz CPU.

Despite it's basic appearance, it's extremely addictive. If you want to play it yourself you can find serial numbers and download links here.

Building Git on OSX

Getting this error message when running make with a fresh clone of the git source code?

GIT_VERSION = 1.8.2.rc1.19.g443d803
    * new build flags
    CC credential-store.o
In file included from credential-store.c:1:
In file included from ./cache.h:8:
./gettext.h:17:11: fatal error: 'libintl.h' file not found
#       include <libintl.h>
                ^
1 error generated.
make: *** [credential-store.o] Error 1


The solution is to disable this the component, which can be done by creating a config.mak file in the same directory with the following contents:

NO_GETTEXT = 1;

Your  welcome

When Magical Record stops being magical

Some time ago i discovered Magical Record. It offers some fantastic categories to help you setup your Core Data stack with a single line of code. But it's much more than a Core Data boilerplate thingy. It also offers a range of Active Record pattern like shorthand methods. For example you can find all the instances of a particular type of object without having to write your own NSPredicate and NSFetchRequest using MR_findAll.

Somewhat recently they moved to version 2.0, along with lots of others features they added support for Nested object contexts. If you haven't read about nested/ parent-child managed object context your missing out, especially if you've ever tried to use Core Data with multiple threads.

So when did it stop becoming magical?

Usually i use Magical Record to setup my core data stack, and take advantage of its singleton default context, for those times when i'm too lazy to pass it around like a good engineer. I've also been known to dabble a little with it's Active Record implementation.

However with 2.0, the developer(s) have chosen to change the internal structure slightly. A "Root" context is created at the top of the tree, this has a child context that is returned when you call the MR_defaultContext method. The root context controls the writing of data to disk. This means that if you attempt to save the MR_defaultContext your changes are not persisted to disk, but instead pushed up to the root context.

Well that awesome, right ...

Well it is, if it was obvious. Instead I was left no errors, an empty sqlite db, and no data. Personally I really think they should have just made the MR_defaultContext the root context, and allowed users to nest contexts themselves if they wish. In case your interested you can reach the 'Root' context by calling MR_rootSavingContext.

Anyways after digging around the source code, and a little RTFM I discovered that in order to actually persist your data to disk you have to call MR_saveNestedContexts. This method will recursively call up the tree and save each context. Neat, but not obvious, especially when the API convention is to simply call the native save:

So really this post exists to say, if your a fan of Magical Record and your pulling your hair wondering why save: has stopped working the answer is use MR_saveNestedContexts.

Drawing UIImage's with blocks

I have a slight love affair with Quartz's drawing routines. I don't know what it is about them, but there is something I love about stroking rects and filling paths. It's like OpenGL for stupid people.

Anyways, during my love affair I got bit annoyed at having to subclass UIView every time i wanted to make a quick sprite, or overlay a one image on top of another.

CALayer's a are awesome and everything, but i still need to subclass UIView unless i want a bunch of layout mess every where.

So I thought wouldn't it be cool to be able to create UIImage's quickly and then just throw them into a CALayers or UIImageView's and worry about the rest later.
The above does just that, you give it a canvas size or more informally the size of the UIImage that you wish to generate.

It will create the CGBitmapContext with a RGB colorspace, and then you can draw to your hearts content.

You can treat the block almost like a you would drawRect. I say almost because it's not inserted into the graphics context stack, so some of the helper methods like [[UIColor blackColor] setFill] will not work, and you'll have to learn how to do it the 'proper way' (CGColorSetFillColor()). Just consider it a general rule, that if it renders something and doesn't take a CGContextRef you need an alternative method to use it inside this block.

The evolution of lazy initialization

Lazy initialization is tent pole of Objective C. Apple placed a lot of emphasis on using the pattern in the early iPhone days. That was justified especially considering that the original iPhone shipped with 128MB of RAM, compared to the latest iPhone 5 with 1024MB of RAM.

In the beginning

The ARC evolution

The ARC evolution was fairly tame, allowing us to move the ivar into the implementation files. While the original method was great, and served me well until ARC. With no need to dealloc, and the ability to have iVars that aren't declared in the public interfac.

Clang takes it up a notch

With the most recent versions of Clang you no longer have to use the @synthesize & @dynamic keywords when making @property declarations.

This is all well and good, but I don't want to write my own ivars if I don't have to. So I've set about exploring ways that I can do away with having to create my own ivars.

Option 1.

This approach is comprised of three steps

1. Public readonly property declaration
2. Private readwrite property (re)declaration in a class extension
3. Assign our instance to the ivar

The problem with this is that there is still the ability to overwrite the ivar. Granted it's only from within the class, but still not ideal. This could be an advantage as if you decide to move away from the pattern all you need to do is set the ivar via the mutator.

Option 2.

Another alternative, is to take advantage of another clang feature, where we use the @synthesize directive, to generate a backing ivar on request, without having to explicitly declare the ivar, or at least declare it in a conventional way.

Along with being the smallest version, we can specify the format of our private ivars, so if you want to suffix your underscore rather than prefix it, you have that option.

Whats the solution?

Quite frankly, i don't know. I'm leaning towards Option 2 as it doesn't provide an mutator for the ivar, and so there is almost no suggestion that the ivar should be mutated by anything thing other than the lazy accessor. However I'm interested to hear the opinions of others.