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?
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
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.
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]
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.
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.
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.
I think it makes sense to do this if you just want to create a starting point for a view that is created programmatically in a way that isn't easy or possible to do with Interface Builder. It is also convenient if you want to bundle the view hierarchy in to a static library so that it is fully self-contained. Ideally you want to use nibs if possible though. It will make internationalization easier. However you can still support internationalization with a strings file.
Related
Net Developer planning a new Product.
It will amongs other things generate dynamically its User Interface from a downloaded File.
I read that file and depending on it i create the necesseray buttons, labels, tables etc..
I wish to outsource that similar kind of product for a development for the IPhone..
So my question to Iphone experts is. Is this possible with the Iphone too?
With 'possible' I mean basically if it is technically possible and if it is 'allowed' on MacStore..
Any feedback is much appreciated...
The user interface files on the iOS, the (the XIB files), are nothing more than a files containing archived objects. So when you create a static interface in Interface Builder, what Xcode actually does is to create objects for all the UI elements, setting the object properties according to your wishes, setting up the object graph (which objects has references to which other object) and finally archives the whole graph into a file. When you load a XIB file, the objects are simply unarchived and you get an object graph with all the UI objects in their desired states.
That means whatever can be done by loading an interface from a XIB file can also be done problematically. All you have to do is creating the objects yourself, setting all the properties as desired and chaining them to the desired object graph. And yes, creating UI problematically is absolutely allowed by the App Stores (for Mac and for iOS), since it does the same thing by hand as loading a XIB file does automated.
Yes, it is possible and allowed. There are very little UI related operations that can't be done programatically on Cocoa Touch.
I recently worked in a ipad project. I find no nib files in the entire project. Is there a specific reason for such standards? I find it really difficult to follow that kind of project.
I'm not sure I would consider this a "standard". Some devs just prefer to code all their views as opposed to using Interface Builder. The initial releases of IB were a bit flaky and people avoided it due to this. I don't really see any reason to avoid using IB nowadays unless you are doing a completely custom user interface or a game. In the case of a custom UI, it might be easier to build it up in code compared to trying to bend the IB elements to your will.
a nib, particularly if localized, breaks DRY.
initialization is beyond your control when using a nib.
code and program reuse is more difficult. consider libraries and multiple apps.
it's easier to manage/update an implementation from fewer locations/files/resources. let's say you want to change the app's color theme... very painful if you have to modify all the app's nibs, as opposed to changing the definition of a function. also pretty close to useless if you layout the groundwork at the source level for color themes in addition to using nibs -- at that point, you're already setting up your views programmatically.
improved performance (where that's important).
program security. IB used to support plugins/addons in osx... those were just removed.
frameworks are not an option in iOS. nibs can't be shared via libraries as easily as compiled programs.
for long term and large scale development, it makes a lot of sense to write it programmatically, whereas IB's really handy for prototyping.
Agreed, IB is pretty stable and a lot more featured that it used to be. Although iirc using IB does add more weight to the project than if it was all done via code.
I was wondering if there is a way i can design a nib/xib file and generate code for that?
meaning, instead of writing lines of code to generate an interface, would'nt it be easier to design and nib file using IB and get the source or something?
Thanks
I think that you may misunderstand what a nib file is.
If you mean that you'd rather create your view objects in interface builder and have outlets automatically inserted into your source files then look to XCode beta, it does that.
I don't think its possible in xcode to generate code for a nib file designed.I know you are referring to web designing tools like macromedia dreamweaver.
Secondly why do you require the code?X code provides the facility to integrate the nib in the code itself.
Thanks
You are asking for a code generator, which as jsd noted IB will do if you really want.
However, your life will be a lot easier if you just accept what IB is, an object creation, placement, linking and storage mechanism.
IB is doing all the tedious stuff for you, creating instances and setting initial values for you along with (some) relationships, then compositing them all. It freeze-dries the result so it's ready to go at runtime.
It does sometime make sense to use what IB has done as a template to base other code around instead of using the views it creates directly, but if you generate code then you are potentially out of sync with IB and it makes it hard to use for maintaining the interface going forward.
Are there any good reasons why I should not use XIB / NIB files with an highly customized UI and extensive animations and super low memory footprint needs?
As a beginner I started with XIB. Then I figured out I couldn't do just about everything in them. It started to get really hard to customize things the way I wanted them to be. So at the end, I threw all my XIBs away and did it all programmatically.
So when someone asks me if XIB is good, I generally say: Yeah, if you want to make crappy boring interfaces and don't care too much about performance, go ahead. But what else could be a reason not to use XIB?
Am I the only iPhone developer who prefers doing everything programmatically for this reasons?
I think that Interface Builder is one of the biggest assets of Mac (and by extension, iPhone) software development. GUIs are visual; why not create them using a visual interface? IB is flexible enough that you can lay out an interface using its "generic" components, and then subclass them where necessary. Sure, if you have a unique interface you're going to have to subclass a view class and perform custom drawing, but you can also lay out your interface in IB and then easily use the inspector to switch the class to your custom subclass.
Honestly I think it's a spectrum of convenience. If you are comfortable writing everything in code then go for it. If you design your project well then it should be about the same amount of work creating new windows, etc. But I know that a lot of people aren't as comfortable with the GUI world so nib/xibs work well there.
I honestly find myself using XIBs as a base quite often and editing them with code to get the specific look I want. Personal preference.
For a specific con on that point, views can be difficult to configure after loading them from a xib. When you have conflicting settings between IB and code that can be nasty to troubleshoot.
Here's a question for the list. What is the performance hit to using a xib? I thought they were a plus because they don't get loaded into memory until you need them. That said, that load time is longer which will slow your program down. Thoughts?
One thing I found better about code is for the event connections on controls, when you search for uses of a method (message) you find them if they are coded and you don't find them if they were set in IB.
On the other hand laying out objects on a view is much easier in IB where you can see their size and positions. When you do that in code you have to guess at the size and origin settings and then run it and make adjustments, then run it again to see what it looks like.
When your application has some kind of "standard" views, go with the XIB. If you need real customization, depending on external content (XML...) do it programatically.
I started using XIBs and now it's all code, I find myself more comfortable this way. I had real problems with XIBs, and now writing the interfaces all in code really saves me time.
I save tons of time when dealing with UIControllers (UITabBarControllers, UINavigationControllers etc.) in the start up phase where all the navigation stuff is hooked up.
I just build X viewControllers with a accompanying XIB, throw in the stuff needed in IB, labels, images etc. This means that for almost any sort of app you can have a proof of concept up in a few hours. This is enough to justify spending some time learning the ins and outs of IB. Especially on the iPhone where you can have a ton of good UI ideas, but they all fail when they move from the Simulator to an actual device.
The best thing, in my mind, is to balance it out, if you find yourself using a lot of time doing the "change the frame 3 px -> compile -> ahh.. needs two pixels more -> change 2 px - compile -> ahh.. 1 more px" for something that could be done in IB, you will seriously start to waste time.
I start as above, but afterwards I often throw the XIBs away for custom stuff. The trick is to not spend hours on implementing versions of custom stuff in code over and over again, but figure out how it should be and do the custom stuff once:)
The XML content of a nib file is very complicated. This makes it extremely difficult to review changes or fix merge conflicts with a version control system like Git.
Interface Builder is a nice idea, but Bret Victor, in his talk "Inventing on Principle" and his essay "Learnable Programming," implicitly challenges Apple to build an even better IDE.
One idea, based on Bret Victor's principle: What if I could select a "Move Tool" in the iOS Simulator app that let me move a button in my app and then the frame code changed in the implementation (.m) file? This would be much better.
Are there any performance, development drawbacks or advantages when designing views using Interface Builder?
Often you want to use Interface Builder; there are several reasons why you would want to do this over programmatic interfaces:
it is the more accepted way of creating user interfaces, due to its simplicity and visual advantages that you can't achieve as easily by simply using code.
it helps your applications to conform to the iPhone Human Interface Guidelines, through the use of the markers etc, which Apple encourage developers to follow, in order to maintain consistency and usability across iPhone applications.
Despite this, the main reason why programmatic interfaces are sometimes more favourable over using Interface Builder is for interface elements that need to be created several times - for example, creating n UIImageViews - based on a variable that cannot be replicated in Interface Builder. Programmatic interfaces allow for this flexibility and are usually more efficient in this case.
Note that NIBs/XIBs do also take up memory, and if all of your interfaces are placed in your main NIB file, it will not only increase memory usage by your application (for resources which may not be needed instantly anyway) but it will increase loading time. That being said, however, the normal workaround to this problem is not to use programmatic interfaces, but to place different groups of interface elements in different NIB files, placing the immediately required interfaces in the main NIB file, which gets loaded when the application starts, and other groups of interface elements in other NIB files which get loaded when required.
In short, the general way to go is to use Interface Builder, except for when you need to create a variable amount of elements that cannot easily be dealt with in Interface Builder.
One drawback is that it is easy to miss wiring up an outlet or action, and troubleshooting this can be painful. Two positives are that positioning, aligning, and anchoring UI elements is much, much easier, and elements redraw themselves when the phone is rotated (which is an animation process you would otherwise need to handle yourself with programmatic elements).
Speaking for myself, I found interface builder horribly obtuse when I was trying to learn how to develop for the iPhone. The workflow you're supposed to use still doesn't make much sense to me. The interface builder is faster for finicky interface layouts than hand-coding.
The disadvantage with generating the GUI programmatically in your UIViewControllers is that you've blurred the difference between Views and Controllers in the MVC pattern. If you can keep the GUI generation to the loadView method, you can still keep a decent boundary between code the generates information and code that displays information.
In short: I much prefer generating GUIs by overriding loadView in the UIViewController subclasses.
Why did nobody mentioned translation. We have a project in 11 locales - this will give a number of nib*(#locales) - it's just not acceptable (more than a hundred nibs for a project of 10 UIs).
From what I've seen until now, generating views with XIBs is VERY easy. But since I've not been developing on iPhone a long time, I can only direct you to this article that shows a sample XIB converted to Objective-C code.
http://arstechnica.com/apple/guides/2009/04/iphone-dev-convert-xib-files-to-objective-c.ars
Interface Builder anyday! :)
I'm sure there are no significant performance gains by directly coding the view.
Never look at the Code generation of NIB using the tool. But look at the Note by apple.
Note: Although you can create an Objective-C application without using nib files, doing so is very rare and not recommended. Depending on your application, avoiding the use of nib files can involve overriding large amounts of framework behavior to achieve the same results you would get using a nib file.