When you develop apps for the iPhone, you have a choice when it comes to doing the UI. You can either do it (almost) entirely in code or you can do a whole lot in Interface Builder.
When I started off doing iPhone development, I started doing the UI almost completely in code. It was fairly simple. I completed my entire project using this method.
I kept flirting with the idea of doing the UI using Interface Builder. It sounded tempting for a few reasons:
1. Programmers always like less code. The more lines of code, the bigger your project, the more the chances of errors and the tougher it is to maintain the code. If you do the UI in IB, there is that much less code.
2. Easy to make changes. It is easier to change things in IB compared to doing the same thing in code. In IB, you have a visual interface - check a box here, drag something there. In code, you have to actually look for the relevant part of the code and then change it.
So, when we decided to change the architecture of our new product, I decided to try out IB for the UI.
We had 2 tab bar controllers which we had to display based on what the user was doing. It was fairly easy to setup the basic tab bar controller with simple view controllers associated to each tab. However, we had a situation where we needed navigation controllers in some of the tabs. I struggled. I read up some documentation. No luck. I then looked up some forums. I found this advice there:
"I use Interface builder sparingly. It often makes things far more complicated. This is one example of it. NavControllers and TabBarControllers should NEVER be made via interface builder, but by code. Apple never uses interface builder for this, as its way too stupidly set up. The programing way to do it is simpler, and far more understandable when you understand a bit of Objective-C."
So, then I decided not to go down that route despite the advantages. I guess IB needs to be made simpler to be able to use it to do the UI.
Comments