Is there a right/wrong approach for creating a Custom view using code or IB? I mean what should be the preferred way of designing a custom view.
As for all broad questions, the answer is "It depends what you're trying to do". Both IB and writing code have their merits. Some projects will end up with a bit of both.
There's some discussion here:
http://wiresareobsolete.com/wordpress/2010/03/striking-the-balance-interface-builder-vs-code/
Personally, I started out working with IB. But as I went deeper into iOS development, I started building my views in code....
Gave me a higher sense of control over my view objects.
But, like everyone else says, both ways are correct; It just depends on what you're comfortable with.
Like me, try both and see which one works best for you. You have nothing to lose either way.
I used to do it in code but now I mostly use IB to lay out my views and then do fine tuning in code, like setting the font for a UITextView. Always seems odd that you can't do that one in IB...
Related
I have just spend a lot of hours re writing my app to have it all in code instead of using storyboard.
Mainly because I wanted to understand what the storyboard did for me.
Obviously with this, I have noticed that my files have become severely big in terms of lines of code.
Apple seems to be more in favor of storyboard then writing lines of code, as per their WWDC videos.
As fellow developers do you still feel that writing everything out in code is the better way to go? I hope to get a good few opinions on this as I want to see if my feelings on the matter are supported by your ideas, having done this for a longer period of time no doubt.
Thanks in advance.
There are few advantages and disadvantages of both.
Advantages of adding controls by Code
You can prefer writing everything to code if most of controls are dynamic. So that you can load controls whenever required.
Its easy to reuse code and make application more dynamic e.g you want to make UI themes for application
Advantages of Storyoard/ XIB
Using Storyboard/ XIB load all controls(Better if application is static) at once for that view you have to just bind properly.
Design UI with storyboard/ XIB is easy as compare to code.
These are few advantages of both as per my understanding.
making application through the code, helps developer lot, it gives flexibility.but going through the storyboard decreases lines of code. for mobile application development decreased number of lines codes or less code is always welcome.
I've been using Xcode for a while and had a brief look at the interface builder when I first started but then went straight on to coding everything.
So far it's working OK but I just wondered if I'm missing something by not using the IB.
Is there any advantage to using the IB at all? I've even coded subviews and stuff without using the IB but I can't help thinking that it might be more advantageous to use it?
If not I'll keep on doing what I'm doing as it's working for me up to now :D
Thanks
If constructing everything in code is working for you, then great. Personally if it can be done in IB it's done in IB.
I'd be surprised if there's a best practice for this; everyone will have their opinion and preference.
I like to do UI related work in IB - if i'm dealing with presentational concerns I like to be in an environment that offers immediate visual feedback. It also cuts down the amount of boiler-plate code that you would have if constructing everything programmatically.
That said you can't do everything in IB. There are times you'll fall back on programatically constructing or laying out a view.
A little knowledge of both approaches goes a long way...
possible duplicate of: iphone app best practice - is using the IB a better way to design your app, or writing UI code on your own better?
at the end of the day its whatever you feel more comfortable doing. IB is horrible in my opinion, programming takes more effort - more thought. :)
I usually use IB, get immediate visual feedback and make the layout looks exactly easier. Only in one case that I have to give up with IB is performance with UITableView scrolling. In this case, the best solution I can find is to write code to draw everything in the cell using code. This makes the performance much better.
Generally, I recommend to use IB until you have some specific requirements like performance or you need to have really much control over the view
New projects always start off simple so people tend to gravitate toward IB naturally.
Personally I've found that as a view gets more dynamic and complex (and they always do), it makes sense to code it.
YMMV.
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.
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.
I'm going through the Beginning Iphone Development Apress book and I'm constantly getting problems when building my NIB files. My practice apps crash because of the NIBS. I now this because I'll just trade out mine for the sample ones and the app will work. I'll look at the sample nib and all of my connections will be the same. I'm having problems debugging my NIBS and figuring out exactly what's wrong. So...
1) Can you just design your interface in IB and do all the wiring in Code?
2) What's the best way to figure out what's wrong with your NIB's?
3) Anybody else have the same problems with doing the examples in the Apress book?
1) Can you just design your interface
in IB and do all the wiring in Code?
You can but it's WAAAY more work. If you don't want to use IB, then doing everything in code is a better options.
2) What's the best way to figure out
what's wrong with your NIB's?
Check each control and check all reference outlets (Command-2) and class dentities (Command-4).
Check Interface, Implementations for IBActions and IBOutlets, and Implementations for proper load sequences. (i.e. if using IB then initialize your view in viewDidLoad)
3) Anybody else have the same problems
with doing the examples in the Apress
book?
No
Interface Builder will indicate errors and warnings in NIB files by showing an alert icon in the bottom-right corner of the NIB document window. Click on that to see what the warnings are.
You can safely ignore "illegal geometry" warnings but missing outlets etc can be fatal.
If your apps "crash because of the NIBS", then what kind of error message are you getting when the crash occurs? Usually there's a pretty big clue about what's wrong if you look in the Xcode console, and usually that's the best way to start finding out what's causing the crash.
You can build your UI totally in code if you want. I personally prefer this and only resort to NIB files for views that have a lot of items that need to be positioned.
I recommend Erica Sadun's The iPhone Developer's Cookbook for a good tutorial that shows you how to do this. I wrote a review of it here.
NIBs clearly have their place, and many developers prefer to wire things up using a visual tool like Interface Builder. But some of us (like me) would rather do things in code where practicable.
I am pretty much a newbie as you as well, but found this post which advises on striking a balance between the two and illustrates it with an example:
http://wiresareobsolete.com/wordpress/2010/03/striking-the-balance-interface-builder-vs-code/