4 ms·

The one thing I would recommend people do is not use Interface Designer. It bloats your code base and adds more complexity to the view hierarchy. It might be go

The one thing I would recommend people do is not use Interface Designer. It bloats your code base and adds more complexity to the view hierarchy. It might be good to quickly mock-up a prototype, but not much else.

judofyr 15y ago
What's Interface Designer? Or do you mean Interface Builder?
- coreycollins 15y ago
  Yep, sorry. Interface Builder. Shows how much I use it haha.
Aqua_Geek 15y ago
> It bloats your code base and adds more complexity to the view hierarchy. Care to be more specific?
lurch_mojoff 15y ago
Would you care to qualify that. In my experience it has been the exact opposite -- setting up your UI in Interface Builder has always reduced the amount of code necessary and has allowed quite complex view hierarchies to appear pretty much flat in code. And I'm taking about iOS UIs, for which a bunch of the code saving goodies of AppKit Interface Builder are not available -- things like Cocoa bindings and the new auto layout machinery in Lion.
- coreycollins 15y ago
  I find that added generated NIB files just dirty the code base. Of course this is just my preference. However, when I was a beginner, beginning to create more advanced views, I found it easier to programmably add them then to use Interface Builder. I like to be in control of my views and it helps me better visualize the view hierarchy. One example, was trying to create a UITabController with UINavigationController's for each tab. It can be done with Interface Builder, but it takes a lot of steps.
  - bdittmer 15y ago
    No, no it doesn't take a lot of steps. Perhaps I'll do a screencast to prove it.
    - deleted 15y ago
      [deleted]
  - lurch_mojoff 15y ago
    I still don't understand how a bunch of stored-to-file object graphs "dirty the code base" but I guess you are right -- it is a preference thing. Believe me, I have weirder quirks than that when it comes to coding. Your example, however, is probably amongst the worst to support the argument you are making. Here are the steps to create a tab bar view with four tabs, each containing a navigation view, and those containing alternating table views and plain views: - drag out a UITabBarController - remove the two default UIViewControllers instantiated with it - drag out to the tab bar four UINavigationControllers - select each tab and drag out to the center area of the view a UITableViewController or UIViewController - customize to your heart's content - there is no step six… In my guestimate this will take at least 20 lines of boilerplate code, even with the minimal amount of customization. And you’d be missing out on all the rest of the benefits of NIBs, like the ability to see (and to some degree test) your UI without having to build and run your application or the ability to send it off for localization to a collaborator.
    - coreycollins 15y ago
      I think during XCode3 I just really started to hate NIB's haha. They seemed slow to initiate and load. I admit that i haven't yet used Interface Builder in XCode4 and it apparently has fixed a lot of those "weird" bugs.
patrickk 15y ago
I find the exact opposite. For example, instead of drawing a table programmatically, I can drag it into my view from Interface Builder's default list of objects. I can edit the table's properties quickly and easily. And that's just one tiny example. Suppose you have a complex interface with loads of different buttons, sliders etc, custom backgrounds - you would have to set everything in code (e.g. button background images, button type, x and y co-ordinates on the view). In my admittedly limited experience that adds massively to the amount of code you have to write. It's crazy not to use IB in my opinion, but each to their own.
gte910h 15y ago
I am a full time iOS dev: I cannot imagine professionals who completely avoid interface builder. For some screens, it is certainly faster and easier to programmatically build them up, but for the vast majority of screens, your comment seems to tell more about a willingness to learn than a desire to make good apps. Perhaps you stopped trying to use it during the Xcode3 days? Now, almost any hairs it did have got shaved off in the Xcode3->4 transition. I'm not saying use it for all adjustments to views, sometimes those go faster in code, but it is by far the better way to do almost every view.
- coreycollins 15y ago
  I admit I did stop using it during XCode3. I got so use to it I haven't yet used it in XCode4. I meant it more as a better way to understand the iOS view hierarchy, not necessarily the faster way to build apps. But building faster apps doesn't make them better.
  - gte910h 15y ago
    If you do the exact same amount of functionality in a shorter period of time, it frees up that time to then go make another part better. More features. More testing. Faster Release. More documentation. Accessibility features. If you prefer to boil each grain of rice separately for a pilaf, and it tastes the same at the end, you just wasted a lot of time in the kitchen for no good reason other than you've not stopped and learned how to boil them all at once. Try the new Xcode4 book: http://www.amazon.com/Xcode-Developer-Reference-Richard-Wentk/dp/111800759X/ref=sr_1_1?ie=UTF8&qid=1314973883&sr=8-1 http://www.amazon.com/Xcode-Developer-Reference-Richard-Went... It goes into IB's newest incarnation. IB is also fantastic when adding assecessability functions to your app. Another reason to add accessability functions to your app (beyond being a good human being who lets not-fully sighted people use your app) is that it allows kif to work: http://corner.squareup.com/2011/07/ios-integration-testing.html http://corner.squareup.com/2011/07/ios-integration-testing.h... (play the video). I'm not a IB Zealot, I make views manually when it makes more sense to or IB is just not doing it's job with any speed, but "0" is not the amount anyone should be using it who makes non-game apps.
randomdata 15y ago
> It bloats your code base and adds more complexity to the view hierarchy. How so? All Interface Builder really does is serializes the objects, much like you would any other object supporting NSCoding. The net result is that an instantiated view from IB should be identical to one you created manually. IB certainly isn't the right tool for all situations, but its design is pretty clever with tight integration with the rest of the system. I can't see any reason not to use it, when it is appropriate.
jawngee 15y ago
You're crazy town. How does it add more complexity to your view hierarchy exactly? Most people are getting away from doing their UI's in code and moving back to their proper place in IB. This is done almost entirely in IB: http://www.youtube.com/watch?v=Tk8HCkqZsNU http://www.youtube.com/watch?v=Tk8HCkqZsNU As is this: http://shavevideo.com/ http://shavevideo.com/ I'd still be typing if I did it in code. Weird.
- comex 15y ago
  Some random advice about the first video - It's unfortunate that the Default.png is a photo when the UI doesn't seem to vary enough to exclude the standard preview shot. In the adjustments view, "Finish" should be "Done". And tapping it should not trigger a flip animation-- it's too distracting. Also, the music is extremely loud.
  - jawngee 15y ago
    Thanks for the feedback. Not sure what you mean by the standard preview shot?
megablast 15y ago
Lots of downvotes, but I completely agree with you.

judofyr 15y ago

What's Interface Designer? Or do you mean Interface Builder?

coreycollins 15y ago
Yep, sorry. Interface Builder. Shows how much I use it haha.

Aqua_Geek 15y ago

> It bloats your code base and adds more complexity to the view hierarchy. Care to be more specific?

lurch_mojoff 15y ago

Would you care to qualify that. In my experience it has been the exact opposite -- setting up your UI in Interface Builder has always reduced the amount of code necessary and has allowed quite complex view hierarchies to appear pretty much flat in code. And I'm taking about iOS UIs, for which a bunch of the code saving goodies of AppKit Interface Builder are not available -- things like Cocoa bindings and the new auto layout machinery in Lion.

coreycollins 15y ago
I find that added generated NIB files just dirty the code base. Of course this is just my preference. However, when I was a beginner, beginning to create more advanced views, I found it easier to programmably add them then to use Interface Builder. I like to be in control of my views and it helps me better visualize the view hierarchy. One example, was trying to create a UITabController with UINavigationController's for each tab. It can be done with Interface Builder, but it takes a lot of steps.
- bdittmer 15y ago
  No, no it doesn't take a lot of steps. Perhaps I'll do a screencast to prove it.
  - deleted 15y ago
    [deleted]
- lurch_mojoff 15y ago
  I still don't understand how a bunch of stored-to-file object graphs "dirty the code base" but I guess you are right -- it is a preference thing. Believe me, I have weirder quirks than that when it comes to coding. Your example, however, is probably amongst the worst to support the argument you are making. Here are the steps to create a tab bar view with four tabs, each containing a navigation view, and those containing alternating table views and plain views: - drag out a UITabBarController - remove the two default UIViewControllers instantiated with it - drag out to the tab bar four UINavigationControllers - select each tab and drag out to the center area of the view a UITableViewController or UIViewController - customize to your heart's content - there is no step six… In my guestimate this will take at least 20 lines of boilerplate code, even with the minimal amount of customization. And you’d be missing out on all the rest of the benefits of NIBs, like the ability to see (and to some degree test) your UI without having to build and run your application or the ability to send it off for localization to a collaborator.
  - coreycollins 15y ago
    I think during XCode3 I just really started to hate NIB's haha. They seemed slow to initiate and load. I admit that i haven't yet used Interface Builder in XCode4 and it apparently has fixed a lot of those "weird" bugs.

patrickk 15y ago

I find the exact opposite. For example, instead of drawing a table programmatically, I can drag it into my view from Interface Builder's default list of objects. I can edit the table's properties quickly and easily. And that's just one tiny example. Suppose you have a complex interface with loads of different buttons, sliders etc, custom backgrounds - you would have to set everything in code (e.g. button background images, button type, x and y co-ordinates on the view). In my admittedly limited experience that adds massively to the amount of code you have to write. It's crazy not to use IB in my opinion, but each to their own.

gte910h 15y ago

I am a full time iOS dev: I cannot imagine professionals who completely avoid interface builder. For some screens, it is certainly faster and easier to programmatically build them up, but for the vast majority of screens, your comment seems to tell more about a willingness to learn than a desire to make good apps. Perhaps you stopped trying to use it during the Xcode3 days? Now, almost any hairs it did have got shaved off in the Xcode3->4 transition. I'm not saying use it for all adjustments to views, sometimes those go faster in code, but it is by far the better way to do almost every view.

coreycollins 15y ago
I admit I did stop using it during XCode3. I got so use to it I haven't yet used it in XCode4. I meant it more as a better way to understand the iOS view hierarchy, not necessarily the faster way to build apps. But building faster apps doesn't make them better.
- gte910h 15y ago
  If you do the exact same amount of functionality in a shorter period of time, it frees up that time to then go make another part better. More features. More testing. Faster Release. More documentation. Accessibility features. If you prefer to boil each grain of rice separately for a pilaf, and it tastes the same at the end, you just wasted a lot of time in the kitchen for no good reason other than you've not stopped and learned how to boil them all at once. Try the new Xcode4 book: http://www.amazon.com/Xcode-Developer-Reference-Richard-Wentk/dp/111800759X/ref=sr_1_1?ie=UTF8&qid=1314973883&sr=8-1 http://www.amazon.com/Xcode-Developer-Reference-Richard-Went... It goes into IB's newest incarnation. IB is also fantastic when adding assecessability functions to your app. Another reason to add accessability functions to your app (beyond being a good human being who lets not-fully sighted people use your app) is that it allows kif to work: http://corner.squareup.com/2011/07/ios-integration-testing.html http://corner.squareup.com/2011/07/ios-integration-testing.h... (play the video). I'm not a IB Zealot, I make views manually when it makes more sense to or IB is just not doing it's job with any speed, but "0" is not the amount anyone should be using it who makes non-game apps.

randomdata 15y ago

> It bloats your code base and adds more complexity to the view hierarchy. How so? All Interface Builder really does is serializes the objects, much like you would any other object supporting NSCoding. The net result is that an instantiated view from IB should be identical to one you created manually. IB certainly isn't the right tool for all situations, but its design is pretty clever with tight integration with the rest of the system. I can't see any reason not to use it, when it is appropriate.

jawngee 15y ago

You're crazy town. How does it add more complexity to your view hierarchy exactly? Most people are getting away from doing their UI's in code and moving back to their proper place in IB. This is done almost entirely in IB: http://www.youtube.com/watch?v=Tk8HCkqZsNU http://www.youtube.com/watch?v=Tk8HCkqZsNU As is this: http://shavevideo.com/ http://shavevideo.com/ I'd still be typing if I did it in code. Weird.

comex 15y ago
Some random advice about the first video - It's unfortunate that the Default.png is a photo when the UI doesn't seem to vary enough to exclude the standard preview shot. In the adjustments view, "Finish" should be "Done". And tapping it should not trigger a flip animation-- it's too distracting. Also, the music is extremely loud.
- jawngee 15y ago
  Thanks for the feedback. Not sure what you mean by the standard preview shot?

megablast 15y ago

Lots of downvotes, but I completely agree with you.