Convert NIB Files to Objective-C Code | Hacker News Reader

Convert NIB Files to Objective-C Code

github.com

34 pointsoscardelben18 comments

Why would you want to do that?

This makes sense if you want to design UIView based list cells (i.e. UITableView Cells) that have to be high performant because you can do some - (id) init magic that is slower in awakeFromNib and you save some allocation calls. I had to do something similar for a Mac app where i effectively rewrote a finished NSView completely in code and gained at least a 30% speed gain afterwards.

because some people don't like having boxes in the middle that they can't look inside of. I started hacking iphone stuff before there was an sdk, and as a result every time I start a new ios project I rip out all the interface builder stuff... the whole thing just doesn't make sense to me.

I'm sure it's a great tool though, clearly with so many apps out there, people are using it.

As little as I like IB, it being a black box is not one of my complaints. A xib is just an xml file. You can open it up in a text editor and see what happened. You can copy the xib, set an option and diff the two files and clearly see what it did. Dragging lines around is just a different way of setting a target/action pair. Dragging views just sets the frame for you rather than you setting it, etc etc.

Now, if you wanted to argue that IB is bad because XIBs don't merge easily, I might agree with you[1]. Or even that nib loading is slow iOS 3.x[2]. It does make it slightly harder to use custom views, I suppose. But, a lot of the views I make are just existing views combined, not so much custom drawing[3]. And IB excels at that.

1. I'd actually say this is a failing of almost every VCS out there because it doesn't let you lock files. CVS is the only VCS that I know of that lets you do this.

// edit: As masklinn and shaggyfrog point out below, this isn't quite true. Centralized vcs's let you lock files, dvcs's don't. The point is that merge conflicts suck — and with xibs, can't be fixed..

2. UINib on iOS 4 makes nib loading much faster and much less of an issue.

3. Unless I need it to be very, very, very fast. But, I try to avoid this as it makes it harder to change the look around a month from now.

> 1. I'd actually say this is a failing of almost every VCS out there because it doesn't let you lock files. CVS is the only VCS that I know of that lets you do this.

Most (if not all) centralized VCS have no issue with letting you lock files (for those where locking is not default or mandatory à la Perforce of course). SVN for instance lets you not only lock files [0] but mandate that files be locked before edition based on their filetype [1] which is usually set for binary and other non-mergeable files. DVCS do not allow for locking because the concept hardly makes sense in a distributed context, so you have to rely on a centralized third-party to manage locks in that context.

[0] http://svnbook.red-bean.com/en/1.5/svn.ref.svn.c.lock.html

[1] http://svnbook.red-bean.com/en/1.5/svn.advanced.locking.html...

"I'd actually say this is a failing of almost every VCS out there because it doesn't let you lock files. CVS is the only VCS that I know of that lets you do this."

I know that both Perforce and Subversion allow file locking.

And ClearCase and Visual Source Safe.

File locking is typically popular in version control systems that have limited merge abilities. Perforce is a little better at resolving merge conflicts than the others mentioned here; locking tends to be limited to files that can't be merged, such as binaries.

I never said it was bad, I just said I didn't like it. Given that i'm used to building up my views myself, doing it through a gui perplexes me.

You'll note I said it's a great tool in my first post.

Perhaps I misread the tone of "I'm sure it's a great tool though". Apologies, in that case.

Totally agree. IB doesn't make any sense to me either. You end up with some presentation code in one place, and some in another.

Also, what happens if you set all your background colours to white in IB, and then the branding/design people come along and ask you to change to off-white?

Also, what happens if you set all your background colours to white in IB

In that case, its easy for marketing to do it themselves. IB is a UI, after all. You click on a field and select the new color from the wheel a bunch of times.

The alternative is that you go through code and manually paste it in yourself. And you can't `sed` it because not all backgroundColor properties belong to views that need changing (labels might be clear, some other view opaque, etc)

the part that really threw me off was the IBOutlet syntax. Relating the gui tool to the code itself seems bizarre, but I understand I'm in the minority. I just happened to have learned objective C under somewhat less common circumstances.

The tool exists though, so that Apple can bring more developers on board. Providing usable tools is not something I intend to complain about with respect to Apple.

People whine and moan about Xcode, but some of us started out writing this code in cygwin with an arm cross-compiler and deployed binaries via ssh... debugging tools included printf or forcing crashes. Fun times trying to guess at data structures and naked pointers, but I'm quite content with Xcode and gdb and graphical debuggers and whatever else Apple wants to provide for me :)

I felt the same way, but then I took the time to understand exactly what the XIB was doing and now I'm comfortable with it.

I tried to understand NIB mechanism and it was opaque.

I like having everything represented in code, rather than spread across two different tools.

This NIB-to-code utility seems worthwhile.

I used to think "everything should be in code" as well, when I started iOS development. But after I used IB for a while, I could see how it was saving me time on certain tasks, like setting up the ol' MainWindow.xib (especially if you have nested view controllers). That said, it's not as good working with complex, custom views. There, I go all-code. I think this is the pragmatic approach.

Using this tool, how would a developer properly support localization?

if (english) { // 100 LOC } else if (german ) { // 100 LOC } else if (french) { // 100 LOC }

seriously? Might as well use the tools that Apple supports/uses instead of spending time and energy reinventing the wheel

NSLocalizedString ?

You often have to rearrange your UI due to varying lengths of words/phrases across languages, so just swapping out strings isn't enough.

Reply on news.ycombinator.com