I am writing a custom UI control, and am curious as to the standard practices around initialisation (particularly dependance on the control's delegate). Like most controls, my control relies on the delegate to provide important information about how to render itself.
When the control is used from within a NIB, the initWithCoder:
and awakeFromNib
methods are correctly called and the delegate is nicely set up through the IBOutlet
. awakeFromNib
calls a secondary method called setupControl
which interacts with the delegate to set up my control. Life's good!
However, when I create the control manually using initWithFrame:
, obviously awakeFromNib
is never called. I am curious how other developers deal with supporting both IB and programmatic control creation. I can see a couple of techniques for supporting the programmatic case:
- Force the developer to call
initWithFrame:
, followed bysetDelegate:
, followed bysetupControl
. Not too onerous, but does expose the internal workings of my control (ie. they have to know aboutsetupControl
) - Modify the
initWithFrame:
method to take the delegate as well. This does encapsulate the inner workings a bit more, however, I am not sure that this is a particularly commonly used idiom (and it seems that manipulating subviews based on delegate responses is something that is normally deferred until a bit later in the view's lifecycle, rather than in the initialiser) - Override the
setDelegate:
accessor to call thesetupControl
method. Not a big fan of this, as it smacks of programming by side-effect.
Just thought I'd throw it out there to see what techniques I have overlooked. Thoughts?
Thanks. Craig