views:

1300

answers:

3

I am just wondering is there a way to convert nib/xib file to ojbective C code? I just want to find the equivalent code to the nib/xib file (I've tried nib2objc, seems the result is not what I am after).

Actually I want to compile this example

http://developer.apple.com/iphone/library/samplecode/TableSearch/index.html

without nib/xib file (I want it exactly the same with original), any idea about doing this?

+6  A: 

Check out nib2objc:

nib2objc converts NIB files (or XIB ones) into Objective-C code, including all the properties of each instance, the documented constructor calls, and also the view hierarchy.

nib2objc yourfile.xib > code.m
meeselet
thank you, but I am new to iPhone dev. How do I use these code?
Mickey Shine
the code converted by nib2objc did not contain the scope buttons (for search bar).
Mickey Shine
If you're new to iPhone development then you probably shouldn't be trying to re-invent the proverbial wheel.
Azeem.Butt
+5  A: 

In the general case, I think the answer is no. Nibs are not code; they're archives of serialized objects. So what you're asking is, "Given a graph of arbitrary serialized objects, can I generate some source code that might create such a graph without using serialization?" Without special support for such a process in all classes involved, I don't see how you could.

It would probably be more beneficial to ask about what you actually need to accomplish rather than this specific way of doing whatever it is.

Chuck
I agree. There shouldn't be any reason not to use a nib. Granted, if you're starting a new project, you may choose to write all your views in code instead of using IB, but if you already have XIBs, there's no reason to transform them into code and throw them away...
Jasarien
If you are creating localized apps then nibs have limited use. You can use them for layout, but much of the rest of the set up has to be done in code. Also, if you have particularly complex nibs with a lot of overlaying views, they become impossible to manage because there is no way to hide parts in IB.In these situations it is very useful to do some of the work in IB and then abandon it. Being able to convert nibs to code saves a lot of work.
Steve Weller
A: 

To all the 'There shouldn't be any reason to not use a nib/xib' type responses here, let me provide a concrete example as a counterpoint.

[iPhone OS 3.1.3, 3.2]

  1. iPhone OS apps have a limited amount of memory to work with. If you use too much your app is automatically terminated by the OS.
  2. Interface builder loads images referenced in a nib/xib into a cache using [UIImage imageNamed...], which uses up memory and does not automatically release that memory. There is also no way for you to request those images in that shared cache be released.
  3. Lay out some large images in nib/xib files (i.e. - backgrounds), in an app with multiple nib/xib files, and you will very quickly have an app which gobbles up memory quickly (3mbs per full size png background on iPad), that you have no control over releasing. Any doubts about this, check the documentation for [UIImage imageNamed] and do some googling to verify that is what is used.

That's a case for not using a xib/nib.

mpstx
Rebuttal:1. Newer iPhone OS / iOS devices have more memory than the 3G and the 1st gen iPhone, so this problem is solving itself;2. The [UIImage imageNamed:] bug you mention has been corrected in iPhone OS 3.0, it only concerns iPhone OS 2.x versions. Which is not supported anymore by Apple, and apps supporting iPhone OS 2.x are not allowed anymore in the App Store.3. This is a problem regarding the obvious memory requirements of large images, not about NIB files per se.Disclaimer: I'm the creator of nib2objc, so my views are biased, and I use XIB/NIBs whenever possible and appropriate.
Adrian Kosmaczewski