Do you use interface builder at all?

Discussion in 'iOS Programming' started by floyde, May 14, 2009.

  1. floyde macrumors 6502a

    floyde

    Joined:
    Apr 7, 2005
    Location:
    Monterrey, México
    #1
    Hi guys. I've been wondering about this a lot. It seems that the more complex the code sample, the less NIB files are used. Is this perhaps because the samples were made before IB was available for the iPhone SDK? Or does using interface builder become a nuisance when dealing with more complex applications (this is the impression I'm getting right now)?

    So far it seems to me that linking and maintaining .xibs when dealing with a lot of views is more difficult than the programmatic approach. Is this true or did I get the wrong impression?
    Thanks
     
  2. Fontano macrumors member

    Joined:
    Jun 27, 2008
    #2
    I use IB all the time, even for some of the most complex stuff.

    However, in examples, a graphical design tool doesn't really expose itself well unless you are making a VIDEO based training material.

    You can't see all the linking done (objects and methods). The usage of the inspection tool to get the placement fine tuned and items such as that.

    The inline code versions, server that purpose well. It also teaches you what is actually going on in the code and how all the items actually work together.

    I personally find, that using multiple NIB files for common classes, offer me an opportunity to rapidly design in some situations. For example in one of my current projects, I have 7 different graphical layouts for the same custom class object.

    I build a ViewController, that allows me to pass an object to it, and then the view controller will return me the proper NIB name and initialize the class, and I get the object. And the view is the proper view for the current state of the object.

    I now have the ability to add even more views of that data, to the same structure with very little code, and most of the work is done with the movement of the mouse. :)

    So use the examples to understand the nuts and bolts, but don't be afraid to use IB once you know how to use it properly. Is also goes without saying, that using IB exclusively is not always the best solution. There are times, when a simple class without a NIB is the most efficient way to go.
     
  3. fenrus110 macrumors regular

    Joined:
    Mar 24, 2008
    #3
    Yeah I use it quite often, but I usually don't overkill on it. I'm still very proficient at hand coding if necessary.

    And I often set up my delegates with code instead. I hate it when I forget to set a delegate in IB then I get this mysterious crash.
     
  4. PhoneyDeveloper macrumors 68030

    PhoneyDeveloper

    Joined:
    Sep 2, 2008
    #4
    I use IB for the majority of my UI. For something like a screen that has a bunch of UIKit objects doing layout in IB is much easier than in code. In some cases I have a bit of code that makes some adjustments for rotation of the device.

    For table view cells most of mine are implemented in code but I have some that are done in IB. I started out doing them in code before there was much instruction on how to do them in IB and haven't seen the need to update the code. Also, there is some advice that building table view cells from nibs is kind of slow.

    IB is not hard to learn. Laying out graphical things should be done graphically. Doing graphical layout in code is so 90's.
     
  5. Delirium39 macrumors regular

    Joined:
    May 19, 2008
    #5
    Nope, I don't use IB for any of my games, and don't intend to. I like having full control. :)
     
  6. jnic macrumors 6502a

    Joined:
    Oct 24, 2008
    Location:
    Cambridge
    #6
    Nope. Enjoy the control, and also often isn't appropriate to what I'm doing. I prefer to stay in code rather than continuously context-switch.
     
  7. BlackWolf macrumors regular

    Joined:
    Apr 9, 2009
    #7
    well, I started developing when IB wasn't available. When I started to use IB, I thought it was kinda complicated and unnecessary and that you lose a lot of control.
    But if you get used to it a little you really notice that it makes life a lot easier and still gives you full control over everything, since you can still change everything you did in IB programatically.

    As for the examples ... I believe some of them were done before IB was available, at least I used them back then and it seems they are the same as today.
     
  8. Compile 'em all macrumors 601

    Compile 'em all

    Joined:
    Apr 6, 2005
    #8
    I use IB also but it seems most tableview-based apps are done in code. For example, Loren Brichter the dev of tweetie didn't use IB.

    I have no idea for example how to configure using IB the navigation bar of a uitableview.
     
  9. Niiro13 macrumors 68000

    Joined:
    Feb 12, 2008
    Location:
    Illinois
    #9
    Not at all [unless I need to get the height of the slider (just wanna be consistent even though the height is fixed no matter what you put)]. Even if my application is pretty standard and can be done in IB. At the time IB was released with the iPhone SDK, I didn't understand how it worked at all so I've never used it since.

    And sometimes I'd have a bit more complex UI where I need a navigation controller in another navigation controller or a forced navigation bar height.
     
  10. dejo Moderator

    dejo

    Staff Member

    Joined:
    Sep 2, 2004
    Location:
    The Centennial State
    #10
    I try to use IB as much as possible. Reading the "Beginning iPhone Development" book gave me much more confidence with it. But occassionally I find it still can't do what I need it to do and then hand-code instead.
     
  11. kainjow Moderator emeritus

    kainjow

    Joined:
    Jun 15, 2000
    #11
    I too use IB as much as possible. For the iPhone, it's not as big of a deal to write some of your views in code manually because the UIs aren't that complex. However, in Mac OS X I use it all the time for almost everything, because UIs can get very complex.

    The more complex your UI gets, the better IB shines IMO. If you ever find yourself getting overwhelmed trying to manage a UI in IB, remember that you can break it down into subviews (and separate nibs) and only use a few lines of code to add them back together.
     
  12. mccannmarc macrumors 6502

    mccannmarc

    Joined:
    Aug 15, 2008
    Location:
    Manchester, UK
    #12
    Never used IB and never intend to unless they make it more like visual basic's UI building, its much easier to code everything than use a half assed tool imo
     
  13. dejo Moderator

    dejo

    Staff Member

    Joined:
    Sep 2, 2004
    Location:
    The Centennial State
    #13
    Care to elaborate on why you think VB is so much better?
     
  14. mccannmarc macrumors 6502

    mccannmarc

    Joined:
    Aug 15, 2008
    Location:
    Manchester, UK
    #14
    Sure, it's not the language or anything, cocoa is pretty much perfect in that regard. I just feel that stuff like being able to double click on the objects and be taken straight to the relevant code etc would make IB far better and a lot easier to deal with. As it stands I find it much easier to just code everything than mess about and battle with the nuances of IB
     
  15. CocoaPuffs macrumors 68010

    Joined:
    Aug 23, 2008
    #15
    It's comforting to know that most of you use IB quite frequently, which is the same thing I do.

    I second PhoneyDeveloper's comment on custom table cells, IB is too limited for custom cells that involve user interactions.
     
  16. floyde thread starter macrumors 6502a

    floyde

    Joined:
    Apr 7, 2005
    Location:
    Monterrey, México
    #16
    Hmm well, it's seems that it is more a matter of choice. And what Fontano said makes sense, a code sample with a lot of NIB's would be hard to follow.

    I was hoping to use IB for the basic layout, I think it's very tedious to change the position of a control and then build it just to see if it's in place and if it is looking good.

    I did find IB (well not just IB, but the whole NIB thingy) to be a bit unintuitive though, and I was worried that I would spend more time dealing with issues than coding the interface.

    Last night I spent a few hours figuring out how to create a view (not a view controller) class with a NIB, while keeping a view controller to handle rotation and view-switching. I'm not sure I got it right. I still have a hard time understanding the relation between View Controllers, Views and NIBs. I would've assumed that a view was linked to a NIB, but often it is the view controller that is related. This still seems very awkward to me, but I guess once I learn these concepts properly, I'll be able to save some time by working with IB.
     
  17. PhoneyDeveloper macrumors 68030

    PhoneyDeveloper

    Joined:
    Sep 2, 2008
    #17
    There are definitely some concepts that are non-intuitive related to nibs and IB. mccannmarc wants to double-click something and be taken to the code. Newsflash: there is no code.

    Nibs can be used to build a view hierarchy, which can easily be done in C++ or other languages. However, the connections between objects in the nib can also be generated in Obj-C, without any code. Outlets and actions can't really be done in C++ without generating code. This is a continuing mystery to many iPhone developers and is part of the reason they hate IB.

    Understanding KVC isn't really required for most iPhone development so many developers don't know about it at all. Consequently they believe that by generating their UI in code they have more control, which isn't true.
     
  18. admanimal macrumors 68040

    Joined:
    Apr 22, 2005
    #18
    The first version of my main app was built without IB at all for the most part, as I was also somewhat mystified by it at the time. However, as I got the hang of everything and the app got bigger, I began to appreciate IB more and the fact that it eliminated a lot of code (always a good thing). For the 2nd major release of my app I basically rewrote a large portion of the app to use NIBs as much as possible for the GUI, and I would never go back to doing it all in code.
     
  19. mccannmarc macrumors 6502

    mccannmarc

    Joined:
    Aug 15, 2008
    Location:
    Manchester, UK
    #19
    NewsFlash: I know there is no code, and its one of the many reasons I think IB stinks. Just because in my opinion I wish IB was different it doesn't mean I need informing of basic facts. I am well aware how how IB & Nibs work and it is not to my liking.

    I am also not one of the people that hard codes their UI believing it gives me more control, but it gives equal control at minimum and I'm happy to do it (not to mention its unavoidable when coding games in openGL if you don't like to have UIKit controls ruining the theme). I think a lot of it comes down to previous experience. I have always tended to swing towards the graphical side of programming making games and graphics intensive applications, programming a UI (minus the design aspect) for these types of app is usually trivial as it's not the main mechanism hence why I CBA getting IB involved. My development partner and I have both done a lot of VB and its not until you've used it that you realise just what IB could be if Apple wanted it to (whether or not it involves a huge change). My development partner also feels the same way about coding UI's as opposed to using IB so that's just the way we have decided to go and is only our opinion.
     
  20. mraheel macrumors regular

    Joined:
    Apr 18, 2009
    #20
    Its a matter of preference really.. Specially what background the coder has. Some are comfortable writing alot of code and some are fans of Visual Basic!

    Specific to iphone, IB is there to make things easier.

    Simple uncomplicated apps are easier to make in IB. While games/OpenGL require some hardcoding.

    I guess the more creative you become in the future, the more you'll be independent of IB. You'll be making custom controls. Eventually, the more different your app interface looks, the more away you've gone from IB.
     
  21. mccannmarc macrumors 6502

    mccannmarc

    Joined:
    Aug 15, 2008
    Location:
    Manchester, UK
    #21

    Or like myself, both. I prefer the coding approach to VB but VB is good at what it does
     
  22. dejo Moderator

    dejo

    Staff Member

    Joined:
    Sep 2, 2004
    Location:
    The Centennial State
    #22
    Have you used the latest version of VB? I've heard they have moved away from that double-click-to-see-code approach, much to the chagrin of many VB developers.
     
  23. mccannmarc macrumors 6502

    mccannmarc

    Joined:
    Aug 15, 2008
    Location:
    Manchester, UK
    #23
    I've not coded in VB since VB 6 to be fair, from what I have seen of the latest VB's though its still pretty much the same its just linked to the .Net frameworks as opposed to the API and is a lot more object orientated than it was. My coding partner may be able to clarify better as he uses VB quite a lot, I'm more of a C/C++ guy when it comes to Windows although I went through a stint a few years ago of doing a heck of a lot of VB 6
     
  24. RobertBlackburn macrumors newbie

    Joined:
    Oct 7, 2008
    #24
    Not sure which version you are talking about but VB2008 is still double-click-to-see-code, as is C# which is probably a better thing to compare obj-c & IB to.

    It would be very nice to see IB in a similar style. If i really wanted to i would just make my own IB in VB to let me use a VB/C# Interface that can write out the code/files for me but for now i think i will just code my UI interfaces as i find it much more logical.

    If i remember right Borland had a C++ interface builder that was double click and type style so there is no reason IB cant be the same, each to their own i guess.
     
  25. johnnyjibbs macrumors 68030

    johnnyjibbs

    Joined:
    Sep 18, 2003
    Location:
    London, UK
    #25
    I ditched IB early on, and barely used it at all in my first app. But I found it quite useful for my next app, where I didn't use many table views and it had quite a static interface.

    So I think it depends on the app. But it has its advantages and disadvantages in every situation.
     

Share This Page