to Three20, mga...@brushthedog.com

Some people prefer to avoid working with NIB files, but others (like
me) see great value in being able to lay things out in the interface
builder, and to very quickly try out the various properties. NIB's
don't always work well, sometimes you just have to do things
programatically, but in many cases they are useful for developers like
me.

Up to now, three 20 did not allow users to work with NIBs, which made
three20 slightly less appealing to fans of interface builder, but I am
hoping that we can all coexist now. I have had Three20 working with
NIB's for a while now (see Goodreads app), but I haven't had time to
resubmit to the head. I have attempted to do that today, so please let
me know if you can merge from my fork.

http://github.com/skotchvail/three20

The changes are pretty simple.

1) In TTViewController, three20 for some reason is overriding
awakeFromNib, which causes the view to get overwritten. If I am using
a NIB, I want to use the NIB's view and three20 should not overwrite
it. I don't believe that awakeFromNib is ever called unless you are
using NIB's, so this change should be safe.

2) In TTViewController, load view was always overwriting the view.
This is incorrect. If you are loading from a NIB, then loadView should
always call super and leave the view alone, since it has the NIB's
views in it. If you are not loading from a NIB, then there is no
reason to call super, unless you want to pick up the view from there
without allocating your own. Three20 was calling super and then
overwriting the view that super alloc'ed, which is very slightly
wasteful. I changed the code so that super is not called at all, and
the view is created explicitly by three20.

Caveats: I am know almost nothing about GIT, so hopefully I did
everything right. If I didn't, let me know.

I have made a lot of changes to three20, but I only posted the few
changes related to working with NIB's. I can paste more later if this
merge is succesful. Just in case I didn't post everything, anyone
trying to work with NIB's can give me feedback if it doesn't work for
you and I can go back to my code and see what else I didn't merge in
correctly - but I am pretty confident that I got it.

to Three20

I also recently pushed a change set to fix this problem:

http://github.com/chapados/three20/tree/ttviewcontroller-nib

My approach was slightly different:

1. I made initWithNibName:bundle: the designated initializer, and call
that from -init

2. In -loadView, I always call [super loadView], but bail immediately
if self.nibName != nil

Upon re-reading the docs, I guess this is wrong, and it should
probably be the way you do it: only call [super loadView] if
self.nibName is set.

I'm not sure whether the call to [super loadView] is always made, but
since it was there, I left it in.

Brian

Skotch

unread,

to thr...@googlegroups.com

I'm stealthily watching this thread, so once the nib support stabilizes a bit I'll take a look at integrating it into the master branch. Before I fully integrate it, however, it would really help to see a working demo app built with nibs, ideally placed in the samples directory and committed along with the modifications.

to Three20

In this issue thread: http://github.com/facebook/three20/issues/issue/116/#comment_176629

it appears that making initWithNibName: the base initializer that all
other initializers call would possibly be a better approach than my
fork. This is also the approach that Brian has come up with.

My only concern is the very edge case where you have a NIB named the
same as a class, but you actually don't want to load that NIB. If we
could agree that this is never a concern, and the Apple documentation
seems to imply that, then I could change my fork to work more like
what Brian has come up with.

> http://groups.google.com/group/three20/browse_thread/thread/6bb718a67...

to thr...@googlegroups.com

I have the case where I have a controller that I use with different nibs. However, the really simple solution is to just make empty subclasses and I have no problem with that so this seems fine. It is what I was probably going to do in my branch anyhow - have init call initWithNibNamed: [self className] bundle: nil

The only concern I have is that the base TTViewController initializes some appearance values that are generally set in the nib. If we can get it to prefer the nib values (overwrite the local ones in awakeFromNib for instance, then I think it will all be good.

-Todd Blanchard

to Three20

I updated my branch with changes for all classes that inherit from
TTViewController. I changed the code so that initWithNibName: is
always the designated initializer, i.e. it always gets called from the
other initializers.

Developers have complete controller over how to mix and match a
ViewController with a NIB file, or have no NIB file at all.

I created "NibDemo" per Jeff Verkoeyen's request, which shows how to
use three20 with NIBs (or without). I cover a handful of
ViewControllers. The other ones probably work fine, but I didn't want
to spend more of my weekend on this.

I believe that we will want to do more to further expand NIB support
(such as putting IBOutlet on three20 members, letting NIB override
various members) but I think that this is sufficient as a first pass.
I am pretty confident that I didn't break normal three20 without NIBs,
but only testing will be able to prove it.

It would be nice if others would pull my patch and verify that their
existing code works. Also, people interested in using NIBs should look
at my demo and see if they can get this fork to work in their app.

to Three20

I pulled in Brian Chapados' changes and NIB's work great for both of
us. It has been posted to http://github.com/skotchvail/three20

If anyone else is interested in trying this code out on their project
I would appreciate it.

to thr...@googlegroups.com

I grabbed it - it looks strikingly similar to my own solution to this problem but given that there are two of you and one of me, I'll abandon my version and adopt yours. :-)