Incredibly Useful Way to Print Your Core Data Model

So, I love a good bit of old fashioned Pen and Paper to get my thoughts out.  Maybe it’s that I enjoy just using a pen, the flow of the ink on the page.  (I’m, accordingly, a total pen snob).

Sometimes when I want to analyze a data model, I’d love to have it on paper, just so I can scribble, cross things out, etc, etc.

Until now, I found it difficult to have to deal with the CoreData model editor in Xcode because I couldn’t easily print it out, then I found this gem on

Which can be copy-pasted here:

I defined a 1m by 1m paper size, used it to create a PDF, cropped and then printed it:

  • Go to “File”->”Page Setup…”
  • Go to “Paper Size”->”Manage Custom Sizes…”
  • Define a new paper size with 1000×1000 mm and no borders
  • Go to “File”->”Print…”
  • Choose “PDF”->”Open PDF in Preview”
  • Go to “Tools”->”Rectangular Selection”, select the area to crop
  • Do “Tools”->”Crop”
  • Go to “File”->”Print…”, print

Sounds complicated, but works. Instead of cropping, you could use the scale factor in the Preview print dialog.

Updated some info about Mantle

I haven’t been blogging too much recently. My bad. In the meantime I’ve been working on my own App, a Songbook App that allows MIDI control so that if you want to change pages and your hands are busy playing instruments, you can use something like a footswitch controller to change the page.

Check out my Portfolio page for that.

If you’re not a music person, here’s a quick post to tell you that I updated my post about the Mantle Framework. It discusses some findings about working with primitives in your data models, something that wasn’t quite clear to me. In short, Mantle is awesome and does that all for you.

Adding Documentation – appledoc

Yes, there have been thousands of posts on this topic. I guess this is more a reference for me, but perhaps it will be useful to you too. That said, this is for Xcode 4.x and Xcode 5 is coming out soon… <sigh>

  • Clone the appledoc repo at:
  • Build the project.  After it completes, in the project navigator, open the Products folder and right-click on appledoc, and Show In Finder.  Copy that file to your /usr/bin folder. (There is some discussion over which folder, read here.  Ultimately it ‘just works’ in /usr/bin)  Do this every time you update the appledoc project.

Documentation is generated in your project by creating a target designed to do this task.

  • Click on your project name at the top of the Project Navigator in Xcode, and you should see the settings screen in the main panel.  Add a Target, of type Aggregate.  Call it Documentation.
  • This target basically needs to do one thing: Run a Script.  So, add a build Phase of type Run Script.  We will come back to this later.

Appledoc can be run completely from a script with command line args, but let’s use a .plist to specify our parameters.  Create a file called AppledocSettings.plist, put it in a folder (relative to your project root) called ‘appledoc’ and copy-paste this into it:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "">
<plist version="1.0">
  • So now that you’ve created that, import it into your Xcode project for easy editing. Don’t add it to any target because it’s just to be visible to us in Xcode, not packaged in any bundle.

You should read up on what the different parameters do, and you can add further parameters that you need by running appledoc –help from the terminal.  Hopefully you should see how these command line args translate to this .plist file.

Go back to the Documentation Target Settings, and now we will provide the script for it to run:

appledoc \
"${PROJECT_DIR}/appledoc/AppledocSettings.plist" \

NOTE: “PathToSourceFiles” is really the path to where you have the source with the documentation you want to have generated.  So this will be specific to your Codebase.

What just happened?  We told appledoc to run with the settings provided in the .plist, and generate documentation for any source located in PathToSourceFiles.  Note in the .plist file above I have the argument “ignore .m” set to YES, since this is private.  If you’ve done your job right (see my posts on the importance of Encapsulation!!) you won’t need to document this source – your comments should hopefully be enough.

  • Build the Documentation target, you’ll see in the Xcode Organizer that your source has been added to the Xcode documentation library.  Awesome!

Actually Writing Documentation

There are two things that will help you writing Documentation formatted correctly for appledoc.  Oliver Drobnik over at Cocoanetics provides an excellent tutorial on this.  (Search for Commenting Correctly).

Using those examples, I would also recommend you create some Code Snippets for Xcode so that you can easily just drop in a template to document a method or a property or whatever.  Here is a link for setting up documentation Code Snippets in Xcode.  With the examples at Cocoanetics, you could create a few snippets for different situations (Method, Property, Class Description, etc) in no time!

I also suggest looking at the AFNetworking Docset in Xcode, and if you want your documentation to look like theirs, just go to that relevant source file to see how they formatted it. AFNetworking is really well documented!

Deleting Docsets

If you look in the appledoc folder where I asked you to place your AppledocSettings.plist, whenever your Documentation is generated, appledoc places a file there telling you where it placed the docset.  You can navigate there and delete any docsets you don’t want to appear in Xcode anymore.  Restart Xcode and this will be up-to-date!

Happy Coding!

UPDATE: Just added some code you can copy-paste to make your own Code Snippets in Xcode. See my github page for that

Compound Predicates – “get me objects with these specific ID’s!”

So, I’m hoping you know about Predicates and how they make finding or filtering objects really easy. If not, head over to NSHipster and read up on that.

I had a particular use case, where I had an array of objectID’s (NSNumber objects) that I needed to fetch from my CoreData context.

So the question of “how do I get an array of objects with specific, known, object id’s?” The Answer? Compound Predicates.

The Recipe:

// I use MagicalRecord for CoreData.  Get your object context how you normally would then...
NSManagedObjectContext *context = [NSManagedObjectContext MR_contextForCurrentThread];  
NSMutableArray *predicates = [NSMutableArray array];
for (NSNumber *knownId in knownObjectIds) {
  // assuming your object has the property myObjectId
  NSPredicate *predicate = [NSPredicate predicateWithFormat:@"myObjectId == %@", knownId]; 
  [predicates addObject: predicate];  
NSPredicate *compoundPredicate = [NSCompoundPredicate orPredicateWithSubpredicates:predicates];
// like I say, I'm thrilled with MagicalRecord.  
//  This is where you would use this for your fetch request in CoreData
NSArray *fetchedResults = [HSCoreDataObject MR_findAllWithPredicate:compoundPredicate inContext:context]; 

Chipmunk Physics Library

Of course this post isn’t for everyone, but if you ever are in need of a physics engine in your game (or app for that matter), I can’t be more thrilled with the Chipmunk Physics Library, written by Scott Lembcke, over at Howling Moon Software.

It’s a 2D Physics Simulator, which I originally used years ago on BocceBeers, and with this latest upgrade, am using again.  The most important thing I find with 3rd party libraries (beyond doing what they say they can do), is documentation, examples (there are PLENTY), and support.

I have no idea how the author of this lib has the time to develop, market, and support his library, but whenever I post anything to the forums, he’s got it answered within 24 hours.  Every time.  It’s so amazing to not have to get stuck on a problem and wait for the developer to get back to you.   (Ever had a problem with Twitter on iOS… man…)

Anyway, go check it out for yourself.  There are some pretty videos.  🙂