From the community of InnerBand developers, I’ve heard nothing but compliments and happiness about what it does for them. They love the macros and functions that keep their code concise, the category methods that are so useful they can’t imagine living without them, the Core Data Store which brings them sanity, and then classes like IBAlertView which demonstrate why blocks are so darn awesome. I love that they love InnerBand, but there’s one piece of it that they never seem to mention: Message Center.

I can’t blame them. For one thing, it’s never been documented. Second, if any enterprising developer did read analyze the code, they would likely be left with no motivation to use it. Is that assessment fair? NO.

So, what does it do then?

What Is the Message Center?

On the face of it, the Message Center is very similar to the NSNotificationCenter provided by Apple. It allows objects to listen for notifications (dispatch messages) from other objects, send them, include message-specific information by way of an NSDictionary, and stop listening as well. The familiarity is intentional so that other iOS developers would pick up on it quickly.

Let’s see how the basics work. As an example, let’s presume we have two objects, myWeatherWidget and myWeatherReporter. When myWeatherReporter updates the weather forecast, it notifies its listeners. When myWetherWidget gets the notification, it updates its UI to reflect the new information. Got it?

Here’s the most basic way myWeatherReporter can notify its listeners:

[MessageCenter sendGlobalMessageNamed:MSG_FORECAST_UPDATED];

The MessageCenter is used in static form; no need to access a singleton or defaultCenter. This particular code dispatches a global message so that you only need to provide the name, but you can provide the source object so listeners can be more discriminating. Everything else is done for you. If you were using the NSNotificationCenter, you’d of had to specify the source object as nil to get the “global” behavior. Note, also, that MSG_FORECAST_UPDATE is any arbitrary, unique string (Personally, I tender to define it as the same name as the constant).

If we want to pass along the weather information along with the message, we’d do it like this:

[MessageCenter sendGlobalMessageNamed:MSG_FORECAST_UPDATED withObjectsAndKeys:weatherInfo, @"info", nil];

There are actually several versions of the above you could use depending on your style preference, such as with sendGlobalMessageNamed:withUserInfoKey:andValue:, but they all do the same thing which is to package data in the message’s userInfo property.

For an object to receive the message, it must register itself as a listener and provide a method:

- (void)viewDidLoad {
    [super viewDidLoad];
    [MessageCenter addGlobalMessageListener:MSG_FORECAST_UPDATED target:self action:SEL(forecastUpdated:)];
}

- (void)forecastUpdated:(DispatchMessage *)msg {
    NSDictionary *userInfo = msg.userInfo;
    ...
}

Self-explanatory. Again, you don’t have to make these global messages if you want to be more specific. Also, you don’t have to accept the DispatchMessage argument if you don’t need it. Remember, too, that your objects should remove themselves as a listener before being deallocated. I tend to make the object add itself as a listener in viewDidLoad and unregister accordingly:

- (void)viewDidLoad {
    [super viewDidLoad];
    [MessageCenter addGlobalMessageListener:MSG_FORECAST_UPDATED target:self action:SEL(forecastUpdated:)];
}

- (void)viewDidUnload {
    [MessageCenter removeMessageListenersForTarget:self];
    [super viewDidUnload];
}

- (void)dealloc {
    [MessageCenter removeMessageListenersForTarget:self];
}

In 99% of cases, when you unregister a listener you mean to unregister for everything the object is listening to (i.e., the object is going away). If you want to stop listening to just one type of message, there are plenty of methods for handling that case such as removeMessageListener:target:action:.

This is the basic Observer pattern as Message Center implements it. Minus a little more conciseness, you already have that with NSNotificationCenter. Now, let’s see why you’ll never want to use NSNotificationCenter ever again!

What Makes Message Center Awesome?!

What makes Message Center superior to NSNotificationCenter is that it helps you get your real-world work done much faster. For this example, I’ll be referencing the Movie Poster Fetcher which you can download and use as inspiration. What this little app does is let you enter in the name of your favorite movie and it will display the movie poster and some other information. Seems simple enough, but keep in mind that an app like this has a few components you’d normally have to deal with:

• You need to construct the GET request to get the movie poster information.
• You need to create handlers for receiving the response as well as the streaming data.
• You need to spin a thread that will process the response.
• You need to handle errors.
• You need to notify listeners that you have the new data ready.
• You need to display that information.

Everyone, and I mean everyone, writes this code differently. If you like to use NSNotificationCenter, you might notify once when the data comes in and then that listener will notify a second time when it’s done processing it. You might use an asynchronous NSURLRequest, NSOperationQueue, dispatch queues, ASIHTTP, SVHTTPRequest, or any number of other methods. It really makes for a great interview challenge, eh?

Here’s how you would do it with the Message Center:

- (void)requestMoviePosterForTitle:(NSString *)title {
    NSString *url = @"http://www.imdbapi.com/?i=&t=[TITLE]&r=XML";
    NSDictionary *userInfo = [NSDictionary dictionaryWithObjectsAndKeys:title, @"TITLE", nil];

    __block HTTPGetRequestMessage *get = [HTTPGetRequestMessage messageWithName:MSG_POSTER_RECEIVED userInfo:userInfo url:url processBlock:^(NSData *stream, NSInteger httpResponse) {
        if (httpResponse == 200) {
            RXMLElement *rxml = [RXMLElement elementFromXMLData:stream];

            // process xml and supply it to the listeners
            if ([rxml isValid]) {
                RXMLElement *movieElement = [rxml child:@"movie"];

                [get setUserInfoValue:[movieElement attribute:@"title"] forKey:@"title"];
                [get setUserInfoValue:[movieElement attribute:@"poster"] forKey:@"poster"];
            }
        }
    }];

    // dispatch
    [MessageCenter sendGlobalMessage:get];
}

Wait, wait…WHOA, WHOA. Stop right there! I’ve seen that look before. This is the part of the tutorial where you’re disappointed to see all this unfamiliar, fairly bulky code and you just lose confidence that this is the framework you’ve been looking for all your life. Well, no, no, no, you keep reading! Look at the code again! This code does everything. It’s performing the HTTP GET request, it’s checking the response, it’s even processing the XML! (Thanks to RaptureXML!)

Let’s review it line by line:

• Lines 2 – 3 – We define the URL with parameters that will be substituted automatically. In this case, [TITLE] will be replaced by the title string we provide. In the real world, the URL would be a constant, and this is a cleaner syntax to read than a string formatter. (But you’re free to do it yourself if you like. No biggie.)
• Line 5 – We define the HTTP GET request. This is the magic! The request is a message itself and it’ll process the request before dispatching to the listeners. Essentially, you’re telling this thing to do the request, and when it’s all done let the listeners know. This is remarkably different from what you usually see which is a message simply having a name and no other utility.
• Line 6 – This is the processing block. More magic! The idea here is that we’ll process the response immediately when it comes, and only when that’s been done do we notify the listeners. The reason we do it this way is because if we waited for a listener to process the XML, then we could only let one listener handle it. That, or every listener would have to process the XML itself because the order can’t be guaranteed!
• Lines 7 – 12 – This is RaptureXML doing its thing. It tears apart the XML in a laughably tiny amount of code.
• Lines 13 – 14 – Here’s where we take the two bits of information we care about (movie title and poster URL) and add them to the user info of the message. Every listener will now get this information! Note that while you can add information anytime you like, you shouldn’t really do it in the listeners themselves because the order can’t be guaranteed. However, in a processing block, it’s perfect! (Obviously, you can store the information in Core Data, too.)
• Line 20 – This is where we dispatch the message. All the magic happens only after we dispatch. Remember, the processing block is called before the listeners get notified!

Look at this code and really think about it. There’s no wasted space. Everything does it’s job succinctly, efficiently, and clearly. And in this tiny amount of space, we’ve written all the web service integration code we need.

With Message Center, we can do HTTP POST as well. We can also define our own message subclasses, too, that we can re-use over and over again! Dump your JSONKit processing code in a message and have it automatically decoded for you en route to your listeners. Wrap sound effects in messages. Anywhere you take input and produce output you can create a message that will do it for you while you dispatch!

What Else Does Message Center Do?

If that’s all you got from Message Center, trust me, you’re gonna live a happy life. But there’s more, but I’ll offer it with one caveat: you might not ever need it. The reason is that most of this stuff preceded the process block style you see above. (InnerBand itself preceded blocks.) For example, a SequencedMessage lets you chain together a set of messages in such a way that the output of each message is fed into the input of the following message like a human centipede. How is this valuable? Think if you had a message that handled HTTP GET requests and a message that processed JSON. You could chain these together into one SequencedMessage, dispatch, have the HTTP GET request your data, have the JSON message process your data, and only then would all the listeners receive it without any of them having to handle the processing!

Cool, right? But since that’s the prototypical use case, processing blocks blow it away because there’s no need to subclass and all the code stays in one place. Still, the SequencedMessage lets you take advantage of DispatchMessage subclasses that you create and chain them together like high-tech legos. It’s good to be aware of.

While subclassing is great for chaining, also keep in mind that BlockBasedDispatchMessage alleviates even that. By providing your input and output handlers as blocks, you avoid the hassle and bulk of new classes. Be sure to check those out as well!

Summary

The Message Center is a similar, but more powerful, version of the NSNotificationCenter that fundamentally redefines the role of the message. Instead of just being a named thing, it’s a named thing that performs functionality before it dispatches to its listeners, either synchronously or asynchronously. Processing blocks serve as guaranteed, called-first code that empowers you to have multiple listeners without having to split the flow into two parts, one listener processing the response and the other listeners to update based on that new data.

In its most basic form, Message Center lets you loosely couple message sending between components of your application. In its most useful form, Message Center lets you send HTTP requests, process the responses, and then notify listeners of the data in one short, sweet step!

Again, take a look at the Movie Poster Fetcher and see the magic for yourself!

And now. All you need to do. Is find someone who can build. Your app…………..huh.

Well, how the heck do you go about doing that? The Internet is a horrifying place after all. You start with a quick google “i want to create an app” and find App Cooker. Hey, an app to make an app! This’ll be easy, maybe you can do it yourself, too! You read through it a little bit and then, meh, your excitement dwindles. It’s just another development environment. You’ll still need to hire someone to do it for you.

(It’s also worth noting that you not only still have to write the app, but you’ll be doing it with App Cooker instead of the Apple SDK, thereby giving you only a small fraction of the talent pool to draw upon when hiring.)

Stiff upper lip! Undeterred, you google “iphone app developer”. Better! Hmmm, Apple link, Apple link…ah! Here’s iPhoneAppQuotes.com. Let’s see, you give your contact info and…yadda yadda yadda…a company will contact you. What company? Where are they located? Where can you find some all-important examples of their work? I mean, are you willing to spend an hour or more of your precious time talking to some company you’d never want to work with anyway?

Take a closer look at the site. The top quote from the site (as I read it right now) is for Count Trackula. Sounds like the developer they were paired up with did a good job. Let’s take a look at the app:

Wait, it’s spelled Count Tracula? They didn’t even spell it right? And whoa! Look at that app, it’s horrible looking! Apparently some iPhone novice signed up to get quotes and won the bid! Do you want to be showing an app like that to your boss?

That product isn’t going to change the world. It may not even get downloaded much at all.

Alright, alright, don’t be depressed. Cheer up! You won’t get an app that looks like that unless you make a seriously bad choice in who you entrust your app to. But what choice should you make? Well, you can’t decide on who should create your app until you have an idea of the types of options you have.

So, let’s talk about the three kinds of app makers you’ll find out there: The Big Firm, The Lone Consultant, and the Streamlined Mobile Shop.

The Big Firm

The Big Firm is a very common first destination for most people who’re looking to build an app. Why? Because these companies have huge budgets for marketing and PR and you’ll find a seemingly endless supply of uninteresting press releases flooding the search engines.

You can’t help but find them, but does that make them the best choice?

These big firms mask a dirty little secret. Behind their polished façade, you’ll often find a technical company with a high turnover rate, low-balled proposals that stress their development teams, and a large number of sub-contractors who are the ones working on your app. In other words, they’re publicized middle men.

As a member of one of these Big Firms, I once saw an entire 8-man team filled almost entirely by consultants hired in a matter of 2 days. None of them knew each other or were associated with the Big Firm in any way. In other words, the client could have had the same development team at half the cost if they’d just interviewed and found the team itself!

This probably isn’t what you want. These Big Firms work out better for much larger clients who aren’t always looking for the best team for the job but rather tangible accountability. Someone that they can sue if things don’t go exactly how they want. If your company restricts the use of open source applications because it requires support agreements with its software vendors, then this is the choice for you.

Cost can also be quite prohibitive. Hourly rates for the Big Firms range from $125 to $175. And you’re paying for everybody who works on the app: developers, designers, project managers, testers, and sub-contractors. Just one meeting alone with them can reasonably cost you $5,000. Wow.

It’s not all bad, though. The Big Firms often carry some sway in the industry. It can be beneficial to have your app linked to one of these companies. They’ll help promote your app, too, and since they have so many resources at their disposal you’ll never be abandoned. There’ll always be someone available to work on your app.

It’s a big cost for a big team and a quality result, but if a six-figure iPhone app isn’t your cup of tea, is there a cheaper option to go with?

The Lone Consultant

Affordable, available, and offering the most direct communication possible, the Lone Consultant is the best choice for the truly small budget.

Here’s the truth about the Lone Consultant that the Big Firms don’t want you to know: the Lone Consultant used to work for the Big Firms. Me included. In general, your typical Big Firm will pay an employee approximately 25-35% of the hourly rate they are billing to you, the client. And so one day that employee, realizing that they’re the ones who are creating the apps for the Big Firms’ clients, decides to go independent and leave.

Yes, they’ll have to go out and find their own clients now, but they’ll be paid more handsomely for the same work they were doing before. Remember when I said middle man? The Lone Consultant will charge an hourly rate between $50 and $100. Why can they charge a lot less? Because you’re paying them directly. They’re making more; you’re paying less. Everyone wins!

Additionally, you can talk to the Lone Consultant directly. This saves you time not having to negotiate project details through a Project Manager, whom you’ll be talking to with the Big Firm.

The Lone Consultant is a fine choice, but there are some pitfalls to be mindful of. First, they’re going to be a developer, so you need to make sure you have an understanding of where the design talent will come from — if any. You might be responsible for finding that talent on your own, too, which leads to the biggest problem: you get to play Project Manager!

In some cases, this may be what you want, but most likely you’re looking for someone to create your app because you have no idea how to do it yourself. Managing a technical project isn’t easy, especially if you have hard deadlines. What will you do if the developer quits the contract? Can you find someone willing to take over an abandoned codebase? Is the designer overcharging on their hours? How would you even tell if they were?

If you’re willing to take on the responsibility, the Lone Consultant is the most cost-effective option. But, if the Big Firm is too bloated and the Lone Consultant requires too much micro-management on your part, what is the reasonable alternative?

The Streamlined Mobile Shop

The Streamlined Mobile Shop combines the team effort of the Big Firm with the more efficient communication of the Lone Consultant. Hourly rates range between $75 and $125 and fixed bids are common as well. The Streamlined Mobile Shop is employed by a handful of people, likely all designers and developers, so there’s no expensive overhead you’ll have to pay for. They’ll manage your project for you and give you better quality work per dollar than the Big Firm can.

My favorite aspect of the Streamlined Mobile Shop is that it’s made up of some of the most dedicated people. These groups are already stocked with great talent, but since the group is kept small, there’s great camaraderie. And the good mood will make for a better working relationship for you, too.

Let’s Break It Down, Then

Now that you have a good idea of who to choose, who’s it gonna be? My recommendation, if your budget allows, is to go with the Streamlined Mobile Shop because you’ll get the best service at the most reasonable cost. It’s why I’m a part of one. Yet, if you’re organization is too big or too small, it may not be possible to in this direction.

So, there you go. You still need to make a choice! What will it be? Let’s summarize everything we’ve talked about now.

So there we go. Well, good luck with that app. I hope to see it in the App Store soon!

The Problem

The decision to support ARC in your project is clear cut. Yes or no. Most iOS developers use ARC for all new projects that only require a minimum of 4.0 support. (ARC is not supported by iOS 3.1.3.) However, if you are the author of a framework or library, the decision to support ARC isn’t so easy and there are several choices you can make.

The easiest way to go about it is not to convert to ARC at all. Developers can still use your library source code by specifying the -fno-objc-arc option in their project’s Project Sources section.

An example of the -fno-objc-arc option

A big problem with this approach is requiring that option at all. It has to be specified on a per-file basis and, if your library consists of many files such as Cocos2D, the developer would have to set the option for all of them. The XCode interface for this is pretty convoluted and many developers are unaware of the option or where to specify it. Also, if they later updates the library in their project, XCode removes the option and it has to be entered all over again. Pretty obnoxious, and a poor reflection on your code.

Another way to go is to just convert your library to ARC-only. Anyone who isn’t using ARC for their project will have memory leaks and likely a ton of warnings from their static analyzer. This isn’t a realistic option right now. Once a much larger percentage of iOS developers are using ARC it will be. There’s just too many non-ARC projects still out there, especially if iOS 3.1.3 support is required.

So, many developers have decided to add ARC support. A common way is to add a branch to their project that supports ARC. TouchXML, TouchJSON, XMLDocument, and Nimbus are just a small handful of projects that have taken this approach. SVProgressHUD even tried such a branch and abandoned it completely due to the complexity and undesirability of doing such a silly thing!

I highly dissuade you from this approach. Maintaining two branches is rarely a good idea in the real world, let alone for a simple, open-source iOS library. It adds a little complexity to grabbing your source code and will inevitably lead to some commit issues.

There’s a better way.

The Basic Solution

The solution to the problem is conditional compilation. Yes, it’s not only possible, but rather straightforward, to write your code so that it automatically detect the context it’s running in. You won’t have to maintain a second branch and you’ll be able to support ARC and non-ARC code right out of the box.

There’s two methods for doing this and both use the same basic check:

#if __has_feature(objc_arc)
    ...ARC code here...
#else
    ...non-ARC code here...
#endif

The __has_feature(objc_arc) check will not compile the enclosed code for any compiler that doesn’t support ARC, nor for the LLVM 3.0 compiler if ARC isn’t enabled. You can certainly use this code structure and separate your ARC and non-ARC code without reading any further, but if you do you might quickly discover your code will become a mess very quickly. In addition, XCode has historically done a pretty shitty job of automatically indenting code when you use conditional compilation.

How do we keep the code clean?

The Macro Solution

If you want your code to retain (no pun intended) a level of simple readability, macros are definitely the way to go. The idea is that instead of writing completely separate lines of code for ARC and non-ARC, you write macros that adapt to the environment instead.

This is best described by presenting the set of macros which you’re free to drop in to your own project (ARCMacros.h):

//
//  ARCMacros.h
//
//  Created by John Blanco on 1/28/2011.
//  Rapture In Venice releases all rights to this code.  Feel free use and/or copy it openly and freely!
//

#if !defined(__clang__) || __clang_major__ < 3
    #ifndef __bridge
        #define __bridge
    #endif

    #ifndef __bridge_retain
        #define __bridge_retain
    #endif

    #ifndef __bridge_retained
        #define __bridge_retained
    #endif

    #ifndef __autoreleasing
        #define __autoreleasing
    #endif

    #ifndef __strong
        #define __strong
    #endif

    #ifndef __unsafe_unretained
        #define __unsafe_unretained
    #endif

    #ifndef __weak
        #define __weak
    #endif
#endif

#if __has_feature(objc_arc)
    #define SAFE_ARC_PROP_RETAIN strong
    #define SAFE_ARC_RETAIN(x) (x)
    #define SAFE_ARC_RELEASE(x)
    #define SAFE_ARC_AUTORELEASE(x) (x)
    #define SAFE_ARC_BLOCK_COPY(x) (x)
    #define SAFE_ARC_BLOCK_RELEASE(x)
    #define SAFE_ARC_SUPER_DEALLOC()
    #define SAFE_ARC_AUTORELEASE_POOL_START() @autoreleasepool {
    #define SAFE_ARC_AUTORELEASE_POOL_END() }
#else
    #define SAFE_ARC_PROP_RETAIN retain
    #define SAFE_ARC_RETAIN(x) ([(x) retain])
    #define SAFE_ARC_RELEASE(x) ([(x) release])
    #define SAFE_ARC_AUTORELEASE(x) ([(x) autorelease])
    #define SAFE_ARC_BLOCK_COPY(x) (Block_copy(x))
    #define SAFE_ARC_BLOCK_RELEASE(x) (Block_release(x))
    #define SAFE_ARC_SUPER_DEALLOC() ([super dealloc])
    #define SAFE_ARC_AUTORELEASE_POOL_START() NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
    #define SAFE_ARC_AUTORELEASE_POOL_END() [pool release];
#endif

These macros come packaged with InnerBand. In fact, the InnerBand project supports ARC and non-ARC using these same macros. It serves as an excellent reference of how to use them.

Your mindset should be to use these macros as if you’re programming with old-fashioned manual memory management. When you’re not using ARC, the macros behave as you’d expect with SAFE_ARC_AUTORELEASE calling autorelease and so on. When you’re using ARC, the call is ignored.

The bottom line is you don’t have to worry about it. Just use the macros as if you were coding the old way and everything will be taken care of for you. With just a few caveats, of course.

Notice that __bridge_tranfer isn’t present. It’s not something that can simply be ignored in a non-ARC context. Toll-free bridging is hairy with ARC. If you use it, I recommend sticking with the __has_feature(objc_arc) check and implementing the ARC and non-ARC completely separately.

Also, there may be some edge cases where you need to copy a block in ARC. This is done somewhat differently than using Block_copy. It’s rare, but know that if there is a problem with not calling the copy, you’ll know in the form of crashes.

Demonstration

Now I’ll show you how to use the macros. You can leave your project as non-ARC or convert it to ARC. I prefer leaving it as non-ARC, but that’s just me. You can even create a second target and have both. However you do it, just be sure to test both compiled versions of your code before releasing.

Here’s how you’d perform an autorelease:

- (User *)userWithName:(NSString *)name {
    return SAFE_ARC_AUTORELEASE([[User alloc] initWithName:name]);
}

In non-ARC code, it performs the autorelease. In ARC code, it simply returns the value. Note that with this macro if you call SAFE_ARC_AUTORELEASE on a standalone line, you’ll get a warning that the value is not being used. In almost all cases, an autorelease is coupled with a return or at the end of an allocation, but if you do get the warning you can simply assign the autorelease back itself like this to fix it:

    myName = SAFE_ARC_AUTORELEASE(myName);

Retains and releases are similar to autoreleasing:

- (void)setName:(NSString *)name {
    if (name_ != name) {
        SAFE_ARC_RELEASE(name_);
        name_ = SAFE_ARC_RETAIN(name);
    }

    ...

If you like to perform your setters with the three-step idiom (retain, release, set), you’ll get the same warning you did with SAFE_ARC_AUTORELEASE. The same fix applies. If you do the two-step idiom (release, retain with if conditional) as above then you won’t need to worry.

Blocks don’t generally need to be copied in ARC. Here’s how you’d handle it in your multi-context code:

- (id)initWithBlock:(void (^)(void))block
    if ((self = [super init])) {
        block_ = SAFE_ARC_BLOCK_COPY(block);
    }

    return self;
}

- (void)dealloc {
    SAFE_ARC_BLOCK_RELEASE(block_);
    SAFE_ARC_SUPER_DEALLOC();
}

The above also demonstrates how to call a dealloc on the super class, which is expressly forbidden in ARC. The code is removed by the compiler when using ARC, but calls [super dealloc] when compiled as older code.

Autorelease pools have changed, too. Although not strictly necessary, the two different autorelease pool declarations are supported. When you write code to work within an autorelease pool, wrap it like this:

- (id)complexMethodCall {
    SAFE_ARC_AUTORELEASE_POOL_START();

    ...my code here...

    SAFE_ARC_AUTORELEASE_POOL_END();
}

In ARC, there’s a lot more options for specifying a property. While assign and copy can still be used, there’s a newer specifier called strong. This is essentially retain, so you can write your property like this:

    @property(nonatomic, SAFE_ARC_PROP_RETAIN) User *user;

If you want to use any ARC-specific specifiers other than that, you’ll need to use code compilation with __has_feature(objc_arc) since there are no non-ARC equivalents.

And finally, there’s Toll-Free Bridging. This is one area that got more complex in ARC.
I usually resort to code compilation. See the InnerBand code for examples of this surgical procedure. Luckily, you won’t use it much unless you’re using Core Graphics.

Parting Words

These macros are not being offered as an alternative to knowing ARC. On the contrary, you should know ARC before attempting to convert any older code over. The spirit of these macros is to easily, and cleanly, allow library code to run in either context. If you’re not feeling so hot on your ARC knowledge, my favorite resources for ARC are Apple’s ARC Documentation, Mike Ash, and a hidden gem from the maker of Kobold2D.

So let’s get to it!

I know Core Data already, so why do I need Mogen?

Core Data is a huge beast of a thing. There’s so much to know, and you’re not going to get any new functionality from Mogen either. What you *will* get, however, is a Core Data that will be far, far easier to use. This is what Mogen does for you:

1. Faster and easier generation of concrete classes for your model.
2. A proper two-class treatment in that generation.
3. Alleviates the need to wrap numeric attributes in NSNumber objects.
4. Handy setter methods for manipulating sets easily.
5. Handy wrapper methods for insertion/entity identification.

I can’t wait to get into it all, but first you need to install Mogen and set up your project!

Installation

The first thing you’ll need to do is install Mogen. It’s simple, you install Mogen from a DMG. After this one-time step, we’ll now configure your project to use it:

1. In your project, open your project properties and click “Add Target”.
   
   

2. Add an “Aggregate” target (you’ll find it in the Other grouping). Hit Next.
3. Name the target whatever you’d like. I’ll call mine Mogenerator. Hit Done.
   

4. Now select the new target you just created and click “Add Build Phase” then “Add Run Script”.
5. Open the Run Script group that just appeared and enter in the information as you see it below while adjusting the names to match your own project. Feel free to modify it to fit your own needs, perhaps to create your model files in a subdirectory.
   
   
6. When you create entities in your data model, be sure to populate the “Class” field with the same name as the entity. (You can name it whatever you want, actually, but that would be mighty stupid to do.)
   

Now, we’re all ready to go, but what did we win? I’ll outline that next.

Faster, Improved Class Generation

I’ve been programming iPhone apps for almost 3 years now and, I’ll be honest, I still can’t tell you the exact steps to generate Core Data classes. It seems to involve selecting the right entities in the model, adding a new file, and changing some checkbo — look, I don’t know. I think they made it a little easier recently, but it was crazy and I use Mogen now so I don’t care anymore. All I know is it’s much easier now.

Change your build target to “Mogenerator” (or whatever you called it) and hit ⌘B to build. And you’re done. At this point, since you generated new files, you’ll need to add them to your project. You won’t have to do this on future regenerations, but for new entities, yes.

You’ll notice that there are two sets of files, _Event.* and Event.*. If you’re not familiar with this pattern, it’s amazing. It’s also been used for years and shame on Apple that they don’t do this out of the box. The _Event.* files are generated and you should never touch them. The Event.* files are generated only if they don’t exist and you can feel free to add any methods and properties you like.

Yes, that’s right, gone are the days where you avoided adding methods to your concrete classes knowing that once you did you wouldn’t be able to generate them anymore. Add all you want, now! The clean coding gods will thank you!

From here on out, whenever you change your model, regenerate the classes, rinse and repeat.

Better Setters

Maybe I’m alone, but early on one of the mistakes I made over and over again was to forget that my numeric entity attributes were wrapped in NSNumber. I’d constantly write code like this:

if (user.isAdmin) {
    ...
}

WRONG! The isAdmin attribute is an NSNumber, so this will evaluate to true for all cases where isAdmin isn’t nil! I ran into this so many times I even contemplated scrapping Core Data to erase the emotional pain.

Not anymore with Mogen. You can now write the code as:

if (user.isAdminValue) {
    ...
}

This simple upgrade is a godsend! Setting attributes is equally easy, and you get to keep the original setters and getters to boot. You can use whatever is useful at the moment. With some attributes, I’ll use both versions:

Thank you, thank you Mogen!

Even More Useful Methods

Aside from the setters and getters, you get some useful methods for relationships, too. Now, I believe Apple has learned their lesson and now provide similar methods like these, but too little, too late. So, let’s say for example you have a entities named User and Role with a to-many relationship on User named roles. You can write code like this to add a role to the user:

User *user = [User insertInManagedObjectContext:moc];
user.name = @"John Blanco";

Role *role = [Role insertInManagedObjectContext:moc];
role.type = @"Administrator";

[user addRolesObject:role];

And you’re done. No need to create a mutable set or anything, it’s all handled for you. There’s a handful of other methods like this, one that lets you remove an object and two more that let you add or remove multiples objects in a set.

Validations, Too!

Mind you, this isn’t a Mogen thing. This is a Core Data thing. Validations let you test your data before saving to your persistant store. But, you might not even have known this existed! This is because you have to specify your validations in the concreate class and, if you’re not using Mogen, you’d have to keep rewriting them every time you regenerated your classes. WHAT?!

Now, you can specify validations like this:

- (BOOL)validateEmail:(id *)value error:(NSError **)error {
    if (self.email && ![self.email isValidEmailAddress] && error) {
        *error = [NSError errorWithDomain:@"MyErrorDomain" code:1];
        return NO;
    }

    return YES;
}

This is how you validate individual attributes, but there are other hooks available. Find out more about Core Data Validations to harness even more power.

Conclusion

I hope I’ve made my case for Mogenerator. It’s an invaluable tool! It simplifies anything and since I learned about it I haven’t worked on a project without it. Even better, since it’s a tool and not a library, it interoperates perfectly with other Core Data libraries like InnerBand’s Core Data Store and Magical Record.

Now go forth, young soldier!