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.
Related
I'm working in a company where we have several iOS developers and we use GIT to work in the same projects together. We never use Storyboards or .xib files in our development process as it's nearly impossible to merge them correctly.
With the introduction of the iOS7 I thought about the fundamental differences between Storyboards and coding all the UI "the old way", without the use of Interface Builder.
Is there anyone here who does just that? And most importantly, is there something you CAN do in Storyboards that you can't do in code in XCode 5?
I'm going to split your question into two: NIBs, and storyboards.
As far as NIBs are concerned, source control issues can be painful but manageable, mainly because you've typically got one NIB file per view controller. You could imagine a situation where you have two developers working on two different sections of your NIB powered app without any merging issues. Storyboards are different, since you have one single file that describes most - if not all - of the UI of your application. Clearly there is a far greater potential for conflict issues there.
NIBs can be extremely useful and time saving, if used correctly. Here's an example: the iPhoto App on iPad has a very complex UI. The vast majority of that UI is laid out programatically. However, the app also uses NIBs to load in graphical elements which are then laid out in code. This is how the brush panel works - all the brushes are created in a NIB. This means that Apple don't have to have dozens of identical image/image view alloc/init pieces of code. All the creation can happen in a NIB (this was discussed in some detail in a WWDC 2012 session on the iPhoto UI - it's well worth tracking down).
So NIBs - sometimes good, can save you a lot of time, and whilst there are merge issues they can in many cases be easily managed and handled.
Then we come to storyboards. Storyboards are interesting. On the one hand, they are extremely helpful and useful for straightforward apps and developers new to the platform. I've just converted a UINavigationController based app from NIBs to storyboards and found some significant time savings (particularly around table views, since with storyboards you can take advantage of prototype cells).
However, if you're working on a large scale project with several developers I'm not convinced storyboards are that beneficial. There are, as you say, big issues with merge conflicts, and unlike NIBs it's not easy to resolve them since that single storyboard file controls all of your app UI.
Here's what I'd suggest (and feel free to ignore me!) - if you're currently developing apps and doing your layout/UI entirely in code consider whether NIBs might save you time. They may well not - they're not for everybody - but it's well worth at least considering. You may be surprised at how many large apps actually use NIBs (iPhoto, as I mentioned, but also many built-in apps provided by Apple, as well as many popular third party apps by large teams). I probably wouldn't consider storyboards unless you were a sole developer working on an app with fairly straightforward navigation. That's not to do down storyboards in any way - I love using them - it's just they're not really suitable for collaboration.
Somebody posted this comment in reply to your question - I wanted to discuss it:
There is nothing you can do in storyboard and can't do in code. Objects, gesture recognizers, segues, even constraints - are all available for you to build programmatically
This is technically true, but in reality there are things in storyboards/NIBs that are much easier than code. A good example of this is auto layout. Whilst you can certainly manage your auto layout contraints entirely in code, the harsh reality is that the ASCII auto layout representation is much harder to work with than the visual representation you get in IB. This is especially true on XCode 5, where there are massive improvements to auto layout in IB (I can't detail it too much as it's still under NDA, but Apple publically talk a bit about the changes here).
For me the only big drawback of storyboards is the slow loading time and the usual lag that comes when navigating the storyboard. I'm not talking about 2-5 view controllers apps. I'm talking about 10 and more...
My personal preference is smaller storyboards if I really have to use them(UITableView prototype cells) or just plain xibs.
Doing it in just plain code is just a matter of .... do you have enough time on your hands? :) Usually you wont gain a lot from doing it this way.
You should consider these issues in your dessision:
Development time -
Obviously, working with the xcode UI designer is much more faster and easy to learn when creating new applications from scratch.
In the programmatically way, you will have to define in code each and every element property you'll want to set.
Working with storyboard will make the development process much faster.
Code reuse -
When working with storyboard you will have to bind UI elements to the controller with bullets that adds additional hidden code in the storyboard file. Same stubs are added when creating segues between controller.
This addition hidden code will make make it more difficult to reuse the controllers in other apps that you'll build.
If you are planning to make mass reuse of you controllers code, than creating the UI elements programmatically will be more suitable.
Source code integration -
Conflicts resolving is a common thing when several developers commits changes to the file.
Creating and changing UI elements with storyboard additional changes are added to the storyboard file that sometimes makes the conflicts resolve kind of tricky.
On the other hand, when changing UI elements programmatically only the changes that you'll make will be added the the controller file.
I want to decide if it is better to use XIBs or to designs my views completely using code.
So far I have read that when you design your views on interface builder they are pre-built, so even if they use more memory the user feels everything is faster.
People say doing everything using code is harder but I find it to be just as easy, so I want to know if anyone has experienced some real speed gains when using nibs.
What have been your experiences, advice, etc?
Thanks!
You should be able to do both -- there are times when building a view programmatically is better/easier, and times when using a .xib is better/easier. Even if you only ever do things one way, you'll run into code that does it the other, and you'll need to be able to deal with that.
If you don't know how to use IB, then building your views in code is certainly easier. That is why you should learn to use IB. Once you understand IB, it's way, way faster to put together most of the view-based UI your app will likely need. IB helps you line things up, center objects, align base lines, connect controls to their targets and actions, etc. I think it's safe to say that everyone who uses IB effectively experiences "real speed gains when using nibs."
You should know how to use both. Performance differences between the two are negligible and should not be the reason that you choose one or the other.
Many people who are new to iOS development have the misconception that nibs (.xib files) are inferior to programmatically creating your UI and that if you use IB you're not a good iOS developer. That view is 100% wrong. IB is created by Apple and in use by Apple's developers to create their own Mac OS X and iOS apps. If IB (as a tool) is good enough to be used by some of the best developers in the world, it's probably good enough for most of us.
In practice I have found that a combination of the two usually fits the bill.
In my own apps I find that .xibs are great for laying out the basics of your views quickly and they allow you to iterate very quickly while giving you a preview of what your view will look like. It's also much easier to use auto layout in a .xib file.
Then when you need to do more advanced things like add fancy animations or move views around that is what IBOutlets are for. Anything that you put into a nib can be referenced through an IBOutlet. This allows you do then programmatically make your view come to life.
Lastly, you should fully understand what a nib (.xib) is doing automagically for you. You should understand what happens when a .xib's objects are unfrozen. There are many resources on the internet to understand .xib files better.
Also, learn how to use .xibs in an encapsulated way. For example, .xibs are crazy useful for things like prototype cells and they allow you to keep your code base modular (much more so than storyboards). Also, you will require less UI code in your view controllers.
Lastly, I always say that people should think of IB/.xibs like jQuery. It's going to save you a lot of time but the best developers still know how to do everything in javascript if they have to.
Good luck and have fun!
TL;DR version
Performance is not a consideration when deciding to use .xibs or not.
Use .xibs because they give you a preview of the view you are creating and they allow you to quickly iterate
In practice most apps will use a combination of both. You will programmatically add animations or move views around but the .xibs will be a starting point
Understand fully what happens when the objects in a .xib are unfrozen
You'll be more productive but be sure you fully understand what is happening behind the scenes.
I would always use XIB files unless there was a reason not to. This allows your views to be maintained easily in the future.
Some reasons for creating the views programmatically might be:
A control needs to be resized,
repositioned or otherwise altered
depending on something else
Controls
need to be added or removed
dynamically
There may be more reasons but there are not too many.
If you programmatically create views when there is no need you make it a lot more difficult for other developers to try to figure out what the view will look like and to change it.
If you build your views programmatically, you have control over the loading of elements. e.g. you could use lazy loading, and load secondary buttons, subviews, etc. a fraction of a second after the more important elements, allowing the key parts of the UI to come up faster. You could even animate some elements into position.
If you use IB, you get guides as to proper element spacings and positioning, but you could always copy the coordinates from IB into code if you aren't changing the design that often.
For simple UI elements, you will end up with more lines of code to maintain if you create them programatically.
IB and NIBs do a lot to optimise loading/unloading of views, but it is largely oriented to minimising memory usage vs. perceived speed for the user. For example, lazy loading if anything might make the app UI slightly slower, but it should make memory usage lower. This in turn could make overall app performance better on a large application, and is very much encouraged, but it's difficult to define "performance" in a narrow way. It's also difficult to say when you should or should not use IB - there will be some times you're much better off doing it in code.
One often overlooked element to the IB or not debate is development speed, especially if you have multiple developers. On a larger team/project you'll probably have some developer(s) who specialise more in the infrastructure, business logic etc. of the app and some developer(s) who specialise more in the UI. In this case, use of IB will make it easier for them to work independently, which should make overall development more efficient.
I view IB as a core part of the development platform for iOS development. It's not the right solution in every situation but not knowing how to use IB will be a real limiting factor.
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.
I have been programming with the iPhone SDK for some time now.
I have not been using Interface Builder. This scares me a little. I know that in effect I may be 'fighting the framework' but I do not see it that way.
I find it very easy to just instantiate my UITabBarController in my app delegate, instantiate a UINavigationController, then push and pop view controllers as I go.
Naturally I do not have an extensive knowledge of how to architect an app with XIB files because I have never done so, however I do know the general gist of it, having built some Mac apps in Cocoa using NIBs. So I am not completely ignorant.
My question is whether there is an increase in development time when choosing to lay out UITableViewControllers and UIViewControllers using XIBs rather than programmatically instantiating them and then setting up the ivars.
As I see it, both methods still require you to subclass the view controller for customization which will probably occur for the majority of your views. As well, there are still manual classes required for delegates, and the process of connecting outlets from within the XIB seems comparable to me from setting an ivar.
Or am I missing some other major point?
Thanks!
Code takes much longer to write to configure UIs than IB does.
Plus, you can hand off design to designers and let them tweak the UI.
In the end they both accomplish the same thing. You should use either one depending on the circumstances. Most of the time writing the code to create and position views, and especially maintaining it down the road, will take much longer than using IB. In a simple app for the iPhone though, this might not be true and you'd be just as well off creating everything in code. Basically, you should know how to do both, and pick the path that involves the clearest code and quickest development.
IB shines when you're using it to actually lay out views; even two or three views can be a real hassle to lay out and configure in code. I do tend to use it for tab bar and navigation controllers, and sometimes for subcontrollers (usually only if I think the user is very likely to use it), but that's more just because I'm already there so I find it convenient.
With this new version 3 OS they're announcing next week, I'm hoping Interface Builder gains some of the flexibility it has in Cocoa, where you can add palettes for your own classes and even build up complex non-view data structures (by using custom palettes). We'll have to see, though.
Don't worry too much, IMO Interface Builder is a little over-rated too.
It's definitely useful for getting things up and running quickly, or if you have an app with a lot of screens that are tedious to setup, but you're not missing much.
For the uses you outline just doing things in code is fine, and possibly even a little easier to understand.
Laying out views, or custom cells though... then you get into a ton of font/color/position setting that quickly explodes into a lot of code, hard to maintain and tweak. Much easier to adjust what you want in IB in those cases.