In previous years I took orders and then delivered them to you at WWDC. I discovered something from that it. It was a huge pita for everyone involved. Therefore, this year I am going to do it differently.

I have created a storefront on SpreadShirt where you can order one of several different T-shirts (and a jacket) for this year’s WWDC. The new shirts include the new CIMGF logo which will soon adorn this beloved site.

I hope to see many of you wearing the T-Shirts this year in San Francisco!

The specs are:

• 2.53 Ghz Intel Core Duo
• 4GB RAM
• 320 GB Harddrive
• 512 Nvidia Video cards (9400 and 9600)
• 2 USB
• 1 FW/800

All of the original hardware and equipment are included.

The asking price is $1,800.00 plus shipping.

The machine is in perfect condition as shown in these photos on flickr (http://tr.im/kQ11).

If you are interested in this machine please contact me at marcus at cimgf dot com.

In this example we are going to build a basic application with the following requirements:

• A plug-in framework
• Plug-ins can extend the managed object model of the application
• Removal of a plug-in should not corrupt the persistent store.

The Concept

Core Data allows a NSManagedObjectModel to be constructed from multiple “sub” models. Therefore we can load up all of our plug-ins and ask them for their NSManagedObjectModel references. Using those plus the models included with the application we can build a composite model.

However this would still save into a single file which would then become fragile if a plug-in disappeared. Instead we will use Core Data Configurations. By declaring a configuration for each model, we can specify a different file on disk for each configuration and thereby be able to split the persistent store by model on disk. If a plug-in disappears, the configuration is not loaded and its corresponding persistent store is not loaded and therefore the integrity of the persistent store stays intact.

The Plug-in Framework

In this example we are not going to explore Plug-in design in too much depth. That subject has been covered elsewhere. Our plug-in for this design is going to use a framework to host the shared code and both the application and the bundles will link to it and import from it.

Our framework is going to consist of a header file that defines the protocol that the plug-ins must implement to be loaded. The header is as follows:

@protocol ZSPlugin <NSObject>
 
- (NSString*)name;
- (NSString*)modelConfigurationName;
- (NSManagedObjectModel*)managedObjectModel;
 
@end

The Example Plug-in

To test this we need to include at least one plug-in. That plug-in will consist of a principal class along with a data model. The plug-in does not need to stand up a Core Data stack because its model will be included in the primary application’s Core Data stack. Therefore we just need to implement the methods in the protocol.

-name

The name method in this example just returns a string.

- (NSString*)name;
{
  return @"Example Plugin v1.0";
}

-modelConfigurationName

Like the name method above, the -modelConfigurationName method only returns a string. In a more robust solution we would check in the plug-in manager to confirm that this name is unique and does not conflict with the configuration of the base application.

- (NSString*)modelConfigurationName;
{
  return @"ExamplePlugin";
}

-managedObjectModel

The final method that we declare in the protocol returns the NSManagedObjectModel for the plug-in. This method does a simple load from the plug-ins bundle.

- (NSManagedObjectModel*)managedObjectModel;
{
  if (managedObjectModel) return managedObjectModel;
 
  NSBundle *myBundle = [NSBundle bundleForClass:[self class]];
  NSArray *bundles = [NSArray arrayWithObject:myBundle];
  managedObjectModel = [[NSManagedObjectModel mergedModelFromBundles:bundles] retain];
  return managedObjectModel;
}

The one interesting part of this code is that we need to get a reference to the NSBundle for the plug-in from its principal class. This is because the call [NSBundle mainBundle] will return the application’s bundle instead.

The Plug-in Manager

The plug-in manager loads all of the available plug-ins on launch. In this example we do not allow dynamic plug-in loading.

#import <ZSPlugin/ZSPlugin.h>
 
@interface ZSPluginManager : NSObject 
{
  NSArray *loadedPlugins;
}
 
@property (retain) NSArray *loadedPlugins;
 
+ (id)shared;
 
- (NSArray*)pluginModels;
- (NSArray*)modelConfigurations;
- (NSString*)applicationSupportFolder;
 
@end

-init

The plug-in manager is a singleton that initializes itself and loads all of the existing plug-ins upon first request.

- (id)init
{
  if (!(self = [super init])) return nil;
 
  //Find the plugins
  NSFileManager *fileManager = [NSFileManager defaultManager];
  NSArray *plugins = [fileManager directoryContentsAtPath:[self applicationSupportFolder]];
 
  if (![plugins count]) {
    NSLog(@"%@:%s No plugins found", [self class], _cmd);
    return self;
  }
 
  //Load all of the plugins
  NSMutableArray *loadArray = [NSMutableArray array];
  for (NSString *pluginPath in plugins) {
    if (![pluginPath hasSuffix:@".bundle"]) continue;
    NSBundle *pluginBundle = [NSBundle bundleWithPath:pluginPath];
    Class principalClass = [pluginBundle principalClass];
    if (![principalClass conformsToProtocol:@protocol(ZSPlugin)]) {
      NSLog(@"Invalid plug-in, does not conform to the ZSPlugin Protocol: %@", pluginPath);
      continue;
    }
    id<ZSPlugin> plugin = [[principalClass alloc] init];
    [loadArray addObject:plugin];
    NSLog(@"Plug-in Loaded: %@", [plugin name]);
    [plugin release], plugin = nil;
  }
  [self setLoadedPlugins:loadArray];
 
  return self;
}

In the -init method we first find all of the files in the Application Support directory. If there are no files then we quickly return self. If there are files then we start looping over them. On each iteration we check to see if the file is a plug-in and if it is not we skip to the next loop. If it is then we look-up its principal class and confirm that it conforms to the ZSPlugin protocol. If it does not we warn the developer and skip to the next loop.

Once we pass all of the integrity checks we then call alloc and init on the plug-in and add it to the array of loaded plug-ins.

-pluginModels

To help the main application initialize we have a couple of helper methods in the plug-in manager. The first is a method that returns all of the plug-in models.

- (NSArray*)pluginModels;
{
  NSMutableArray *array = [NSMutableArray array];
  for (id<ZSPlugin> plugin in [self loadedPlugins]) {
    [array addObject:[plugin managedObjectModel]];
  }
  return array;
}

-modelConfigurations

The second helper method returns an NSArray of the configuration names used by the plug-ins. These names will be used both to load the configurations and to decide on the persistent store’s file name.

- (NSArray*)modelConfigurations;
{
  NSMutableArray *array = [NSMutableArray array];
  for (id<ZSPlugin> plugin in [self loadedPlugins]) {
    [array addObject:[plugin modelConfigurationName]];
  }
  return array;
}

The Primary Application

With our quick walkthrough of the plug-in structure complete we need to review the changes to the application itself. All of the changes are limited to the Core Data methods.

-managedObjectModel

The first change we need to make is how we load the NSManagedObjectModel. Normally we would just call [NSManagedObjectModel mergedModelFromBundles:nil] and be done. However we want to load not only the models within the application itself but also merge with all of the models in the plug-ins. Therefore a couple of extra steps are required.

- (NSManagedObjectModel*)managedObjectModel 
{
  if (managedObjectModel) return managedObjectModel;
 
  NSMutableArray *models = [NSMutableArray array];
  [models addObject:[NSManagedObjectModel mergedModelFromBundles:nil]];
  [models addObjectsFromArray:[[ZSPluginManager shared] pluginModels]];
 
  managedObjectModel = [[NSManagedObjectModel modelByMergingModels:models] retain];
  return managedObjectModel;
}

In this method we start with the NSManagedObjectModel from the Application itself and add it to a NSMutableArray. We then request an array of all the models from the plug-ins via the ZSPluginManager and add those models to the NSMutableArray. Once we have all of the models together we call +modelByMergingModels: and merge all of the models into one super model. We retain that model and return it to the caller.

-persistentStoreCoordinator

The second and last change we need to make to the Core Data stack is the way that we handle the NSPersistentStoreCoordinator.

- (NSPersistentStoreCoordinator*)persistentStoreCoordinator 
{
  if (persistentStoreCoordinator) return persistentStoreCoordinator;
 
  NSFileManager *fileManager;
  NSString *applicationSupportFolder = nil;
  NSURL *url = nil;
  NSError *error = nil;
  NSString *filePath = nil;
 
  fileManager = [NSFileManager defaultManager];
  applicationSupportFolder = [[ZSPluginManager shared] applicationSupportFolder];
  if (![fileManager fileExistsAtPath:applicationSupportFolder isDirectory:NULL] ) {
    if (![fileManager createDirectoryAtPath:applicationSupportFolder attributes:nil]) {
      NSLog(@"%@:%s Failed to create app support directory", [self class], _cmd);
      return nil;
    }
  }
 
  NSManagedObjectModel *mom = [self managedObjectModel];
  if (!mom) return nil;
  NSPersistentStoreCoordinator *psc = nil;
  psc = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel:mom];
 
  NSMutableArray *configArray = [NSMutableArray array];
  [configArray addObject:@"Core"];
  [configArray addObjectsFromArray:[[ZSPluginManager shared] modelConfigurations]];
 
  for (NSString*configName in [[ZSPluginManager shared] loadedPlugins]) {
    filePath = [configName stringByAppendingPathExtension:@"sqlite"];
    filePath = [applicationSupportFolder stringByAppendingPathComponent:filePath];
    url = [NSURL fileURLWithPath:filePath];
    if (![psc addPersistentStoreWithType:NSSQLiteStoreType 
                           configuration:configName 
                                     URL:url 
                                 options:nil 
                                   error:&error]) {
 
      [[NSApplication sharedApplication] presentError:error];
      [psc release], psc = nil;
      return nil;
    }
  }
 
  persistentStoreCoordinator = psc;
  return persistentStoreCoordinator;
}

The first half of the method is almost straight out of the template. However once we have the application support directory created and the raw NSPersistentStoreCoordinator initialized it is time to deviate.

The first then we do is construct a NSMutableArray and add our application model’s configuration name to it. In this example I called it “Core”. With the array initialized we then grab all of the configuration names from the plug-ins via the ZSPluginManager and add them to the array.

With the array fully populated it is time to iterate over it. Within each iteration we do the following:

1. We construct a file path for the configuration using the application support folder and the configuration name. We add a “sqlite” extension to it although in a production system you should use an application specific extension.

2. We then add the newly constructed file path to the NSPersistentStoreCoordinator re-using the configuration name and checking for failure. If we fail we present an error and abort.

Conclusion

That is all there is to it! Core Data takes over from there and automatically saves the correct objects into the correct store files for us. If a plug-in goes away we don’t load its model and we don’t reference it’s store so integrity remains.

In the included example application I have also built a UI which lists the entities that are available in the model. If you run it straight from the zip file you will see the following UI:

However, if after building the application, you copy the example plugin into your ~/Library/Application Support/CDPlugins directory and run the application again you will see the following.

Which shows that not only is the plug-in loaded but that it’s entity (Widget) has been included in the Core Data stack. This can even be extended to create widgets and then remove the plug-in to confirm that integrity is maintained.

Plug-in Demo Project

The Definition Of D.E.B.B.

In the original version of this article my use of the term “documentation” was not interpreted in the way I had intended. That original article offended a great number of people and for that I am truly sorry. It was not my intention in any way, shape or form. The goal of this blog is not to kick sand on anyone else’s shoes but to share information and to help educate. That does not mean I will suddenly become politically correct (that would be bad for my health) but it does mean that I am not setting out to piss on anybody.

Within this article we are going to use a new acronym; DEBB. DEBB is not just class documentation but encompasses all of the normal sources we use when trying to understand an API. DEBB stands for Documentation, Examples, Blogs and Books. There is no one word that properly encompasses all of those sources. Therefore I am using a new acronym. Feel free to share it.

I Am A Moron

I think that this declaration requires some explanation before we continue with the primary focus of this article. Just like most of the people who read this blog, I write code for a living. Even when I am writing code by myself, there are actually three people working with that code.

First, there is me. I am a clever and talented programmer. I know to keep my code clean and easy to read. I try to do things the right way and I know that if old code is wrong that I am better off fixing it now then trying to code around it.

Second, there is past me. This guy is a fracking moron. He pisses me off on a daily basis as I am having to constant re-write his code. He is generally clueless and causes me more headaches than anyone else.

Finally there is the future me. This guy is smarter than I am, has seen more than I have and has done more. My goal, in addition to making sure my code works, is to make sure that my intentions are clear for him so that I don’t piss him off too badly.

When I claim to be a moron, it is a matter of perspective. Compared to my 8 year old self, I am brilliant. Compared to myself in 10 years; not so much. Therefore, it is safe to say that anything I wrote in the past was written by someone dumber than I am.

DEBB Was Written By Morons

All DEBB is written by humans who are by definition dumber than their current counterparts. Until we develop and implement technology that automatically reads a developer’s mind and updates DEBB in real time, DEBB is written by morons.

I write this with such a strong word intentionally to shock you. DEBB is a great resource to start with. But, unfortunately, far too many people stop there too. That is the mistake. Imagine if DEBB was so accurate that we could write our code without compiling it and just trust that what DEBB says will happen actually does happen. Would you release code that has not been compiled but is only compared with DEBB? I wouldn’t.

Most DEBB Was Not Written By People With Access To The Source

The DEBB that we use is not necessarily written by developers who have had access to the source code for the APIs that we are using. When we read an example or how-to article about writing code there is a very good chance that the person who wrote that has never seen the source code nor has any insider information.

Sit back and let that sink in a bit.

The person who wrote that example or snippet of code probably (hopefully) has more experience with that particular problem that you are reviewing but there is no guarantee. He may very well have never released a piece of software nor even compiled the example!

Consider this as well: I have written hundreds of pages on Core Data and I have never seen the source code. I would love to, but that is unlikely to ever happen. Should you assume that every line of code I write about Core Data is 100% accurate? No; I don’t even do that. I constantly test my assumptions.

Myths Are Born Out Of Lack Of Testing

Every programming language has its own share of myths. Objective-C is no exception to that. I have run across many of them in my career and it is amazing how people will defend them to the very end. Even in the face of absolute proof they will still close their eyes and ears while pretending that it just isn’t so. Ever hear anyone tell you that a method should have only a single return at the end of the method? That one has been around for ages.

There are many myths surrounding our favorite languages and each one of them deserves to be tested and challenged. That testing cannot be conducted by someone else. When you run across one of these myths and it sounds wrong to you test it. Maybe its not a myth, maybe it is real. But the only way you are going to know is by testing it yourself.

If a trusted resource ever tells you that something needs to be done a certain way, look for a reason behind it. If the reason boils down to “because” or “its always been that way” that should be a red flag. If it sounds fishy then test it. Find out for yourself. If you find out its a myth then share that knowledge. Myths grow in the dark. Shed light upon them.

We Are Lazy

Developers are by nature a lazy bunch. We love solving problems but we generally hate doing something twice. Therefore it is easy for us to just accept the word of a trusted source when they say that something just is and let it go at that. However, your users, clients, customers, suffer from that form of laziness.

If we don’t understand why we are doing something it is our responsibility to research it and grok it. If we don’t are we really any better than monkeys?

Read The Docs But Test

The DEBB on any class is a valuable resource. It lets us know what the intention of the class was and the intention of the developer who wrote it. It teaches us one way to use the classes that are available to solve a problem. But don’t take it as the final authority on the subject. That is a quick way to failure and generation of myths.

We should be able to explain every single line of code that we write. We should be able to look at each line and know why its there. If we don’t, remove it and see what happens.

When an error in DEBB is found we should point it out, politely, to those responsible for it. Let them correct it so that the information can be up to date. It is quite possible that the response will be an explanation of why it is the way it is and we can then go back and review it again. The end result is that DEBB will get corrected or we will learn why something has an unusual structure.

Conclusion

I am sure many will object to my tone in this article. Some may find it offensive. It should be. It was intended to shock. But the message is the same.

If you treat DEBB as the final authority then you are elevating it to the same position as the Bible or other holy text.

That is a mistake because I helped write it and I am a moron.

One such occasion happened today and I needed to mail out a new signed contract to THe Pragmatic Programmers. As luck would have it, I lost my aging copy of Mail Factory, an app that prints nice mailing labels, since the last time I needed to print a label. No big deal, I went to their website and tried to download a new copy. Since the last time I used it, about a year ago, they have cancelled that product and rebranded it Labels & Addresses. Still no big deal, I downloaded the new application and recreated my label.

When I went to print the label I saw in the preview window that they printed “trial version” on the label. Ok, now this is starting to get annoying. If you are going to let me demo the software, let me demo it! Don’t put trial version on the very first label I try to print!

I took a deep breath, remembered that I have been using their software for many years now and decided to just buy a license. They even took my old license in and gave me a discount. Blood pressure dropped, things were fine. Then I ran into their payment processor — Digital River.

I am stunned, stunned, that anyone is still using these thieves! Immediately they try to charge me a “license backup” fee which is an Opt-Out. Annoyed, I opt out of that. On the payment page I have a choice for PayPal. Surprise, there is a $3.50 “manual processing fee” for PayPal. This is NOT 1998! Still, I wanted to print a pretty label so I back out, add a credit card and hit process. I am then presented with this:

Uploaded with plasq‘s Skitch!

Did my order go through or not? Who knows? I check my credit card provider, no charge. But are they slow or did it fail?

I contact the software vendor but they are only open until noon EST. Guess I will find out tomorrow or the next day since their site claims they strive to respond within 1-2 days. A happy customer this does not make.

Advice

Do not do this to your customers. Stop using these payment processing services that charge you insane amounts of money and screw your customers over. Spend a day (yes it only takes ONE day) and write your own that links to Google or PayPal. Or just use E-Junkie like I do. This is a customer facing system. When you bend your customers over with additional fees, cryptic error messages and other junk, they are not going to come back to you and say “please sir I would like some more”.

Also, respond to customer email within 24 hours. Don’t let it sit. Don’t give your customers a 7 hour window per day that you handle email. This is just bad.

My Solution

I deleted their software, will be asking for a refund (IF they ever charge me) and I wrote the label by hand. I will not be going back to them any time in the future for any of their software unless they stop using Digital River.

Sign up for MacDev2009 before the 24th of December and get FREE copies of both Code Collector Pro and Changes App together worth over £40.

There are going to be some great speakers at this event and I am looking forward to it.

If you have not heard, O’Reilly is hosting a conference on November 18, 2008 to discuss all things iPhone. I have been invited to attend the conference as a Panelist.

Please come and join the conference, if nothing else, to heckle me :)

iPhone Live

The list of speakers (as opposed to panelists), is quite impressive and definitely worth the trip.

Speakers

Here is my contribution to move that from the prompt to the right side of the screen.

1
2
3
4
5

function parse_git_branch {
  git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/(\1)/'
}
function precmd() { RPS1="%~$(parse_git_branch)" }
export PS1='> '

Note that the last line just gives me a very short left hand prompt which I prefer.

Uploaded with plasq‘s Skitch!

Take a look at the following lines of code:

- (void)doSomethingSpecial
{
	myVar.itsAttribute = 10;
	myOtherVar.itsAttribute = 20;
}

Now tell me, what is myVar and myOtherVar. Is it an object or a struct? Can’t tell from that piece of code can you. That is half of my argument against dot syntax in Objective-C. It makes the meaning of your code unclear. Objective-C is known for its self documenting nature. Dot Syntax removes that.

Next, lets take a look at another piece of example code:

-(BOOL)myCompliatedMethod
{
	MyObject *object = [[MyObject alloc] init];
	object.attribute1 = 10;
	object.attribute2 = 20;
	OtherObject *nextObject = [[OtherObject alloc] init];
	[nextObject doSomethingAmazingWith:object];
	if (nextObject.result > 10) {
		[object doSomethingElse];
		return NO;
	}
	return YES;
}

Yes, this is clearly contrived code. However, hopefully, its meaning is clear. dot syntax breaks up the flow of the code. Code should be elegant. It should be graceful and beautiful to look at. This is ugly, nasty code that you want to fold as fast as possible so that you can stop looking at it. The message passing lines are completely at odds with the dot syntax lines. The difference is striking and distracting.

When we write code, we care about its formatting. We care that the code is properly indented and that the indentation is consistent. We should care equally as much about its consistency of style and design. Switching from message passing over to dot syntax and back is not consistent.

Now lets compare this against keeping the entire method within message passing:

-(BOOL)myCompliatedMethod
{
	MyObject *object = [[MyObject alloc] init];
	[object setAttribute1:10];
	[object setAttribute2:20];
	OtherObject *nextObject = [[OtherObject alloc] init];
	[nextObject doSomethingAmazingWith:object];
	if ([nextObject result] > 10) {
		[object doSomethingElse];
		return NO;
	}
	return YES;
}

There is now a consistency of form and style. The code flows more smoothly and is not as jarring.

Dispelling some myths

I want to dispel a couple of myths about dot syntax in Objective-C while I am on the subject.

1. Dot syntax is not faster than message passing. It is syntactic sugar that is translated to normal message passing.
2. Using dot syntax to set an attribute to nil is not a more efficient way to release an object. It is less lines of code but just as heavy as [object setAttribute:nil].
3. Using dot syntax will not directly access the attribute on an object. While this is true in some languages, the actual call path for an Objective-C dot syntax accessor is:¹
   • Resolve the accessor selector from the call
   • The accessor method, if that does not exist
   • The attribute itself, if that does not exist
   • The unknownValueForKey: method is called last.

Why did Apple add it?

I have my own theories on why this nastiness was added to the language. It could be due to all of the windows hacks coming over to OS X and a desire to make them feel a little more comfortable.

It could be that a battle rages between the Carbon developer and the Cocoa developers and this was a concession to the Carbon developers since Carbon is going away.

It could be that while adding properties (a most useful feature of Objective-C 2.0), the developers decided “why not” and threw them in there.

We may never know the real reason behind adding these to the language. However it is clear that they are here to stay and I mourn their coming. They are a confusing addition to the language and cause developers new to our platform to bring bad habits with them.

Unfortunately they have made their way into Apple’s sample code as well as the language. This is truly unfortunate. As I have mentioned in the past, the sample code that Apple provides is not the best case solution; however many developers will think so. By adding dot syntax into these examples, it exacerbates the problem. New/young developers coming to the platform will see this dot syntax as the “right way” to do things and they will become a maintenance nightmare.

Maintainability

The last thoughts on this subject are with regard to maintainability. We often forget about this aspect when we are working by ourselves. However, maintainability is not just a factor when we hand off code to another developer, it is also a factor when we have to come back to our own code 6 months from now! I don’t know about you but when I look at code I wrote a year ago all I can think is: “That moron! What the HELL was he thinking!”

Since dot syntax is not as clear with regard to intent as message passing is, then we should avoid it for maintainability as well. Who wants to have to constant flip back to the header file while reviewing a piece of code to remember if we are talking to an object or a struct. Keep the intention clear, keep the code clear, and maintainability will follow.

Conclusion

In the end, it is a matter of preference. I hope that these topics have helped to show the negative effects of using dot syntax in Objective-C. It is purely syntactic sugar and adds nothing to the language. However, there are so many cons that I cannot suggest that anyone use it in any situation.

However, here is a hint.

What does a deadline look like?

And my desk to go along with that link:

Uploaded with plasq‘s Skitch!