On 8 Dec 2009, at 20:49, Aldo Armiento wrote: > Il giorno 08/dic/2009, alle ore 21.37, Alex Kac ha scritto: > >> At least on the iPhone I can say that using NIBs can add a short delay or >> slow some UI operations down. Normally we prefer to use IB everywhere we >> can. On the iPhone we balance it more. Places where pure code is not >> difficult, we'll go that route because its noticeably faster. While its >> gotten better in iPhone OS 3.0+, I can say that there have been a few places >> where using a NIB creates a non-smooth experience whereas using pure code is >> smooth as butter. And this is borne out in tech talks and WWDC >> recommendations. >> > > But it seems that in this case I can't use my UINavigationBar subclass if I > instantiate a Navigation Controller programmatically, so the only way to use > my UINavigationBar subclass is to instantiate a Navigation Controller in IB > otherwise I can't change UINavigationBar class/instance, this makes sense? > I'm forced to use IB?
If something can be done in IB, it can almost certainly be done programmatically. Whether it will be easy is another matter. Nibs are loaded by unarchiving the objects within using the NSKeyedUnarchiving protocol. Therefore, one can get the same effect in code by unarchiving a UINavigationController while customising the archiver to substitute your custom class for UINavigationBar. Tedious, but doable. Other alternatives: - Subclass UINavigationController to return a custom view from -navigationBar. - Add a custom subview to the nav bar to do your drawing._______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
