Monday, February 7, 2011

When to create Interface Builder plug-in for custom view?

When do you recommend integrating a custom view into Interface Builder with a plug-in? When skimming through Apple's Interface Builder Plug-In Programming Guide I found:

  • Are your custom objects going to be used by only one application?
  • Do your custom objects rely on state information found only in your application?
  • Would it be problematic to encapsulate your custom views in a standalone library or framework?

If you answered yes to any of the preceding questions, your objects may not be good candidates for a plug-in.

That answers some of my questions, but I would still like your thoughts on when it's a good idea. What are the benefits and how big of a time investment is it?

  • I think the Apple guidelines sum it up nicely.

    If you're writing a control that will be used in multiple applications and is completely generic, then creating a custom object is a good idea. You'll be able to visualize the look and set properties directly from Interface Builder.

    If your control is limited to one application, or is tightly coupled with your data, then moving it into a custom object really won't buy you much.

    It's not difficult to create a custom view, there are a lot of easy to follow guides out there.

  • It's perfectly reasonable to push the view and controller classes that your application uses out into a separate framework — embedded in your application wrapper — for which you also produce an Interface Builder plug-in.

    Among other reasons, classes that are commonly used in your application can then be configured at their point of use in Interface Builder, rather than in scattered -awakeFromNib implementations. It's also the only way you can have your objects expose bindings that can be set up in Interface Builder.

    It's a bit of coding, but for view and controller classes that are used in more than one place, and which require additional set-up before they're actually used, you'll probably save a bunch of time overall. And your experience developing with your own controller and view classes will be like developing with Cocoa's.

    Sven : I agree. But I would add the view classes directly to the target app instead to a separate framework, even if it’s embedded in the application bundle.

0 comments:

Post a Comment