Hacker News new | comments | show | ask | jobs | submit login

I'm pretty new to Mac OS X programming (coming from a very hobbyist cmdline/web app python background) so using an IDE has been pretty weird for me. I found the disconnect between IB and XCode the most difficult thing about it, it's like there was another layer of programming you couldn't see immediately (the connections) which made it harder to slip back into a project if you hadn't touched it for a while. Not to mention the fact that every time I picked up this project (it's an after hours thing that I don't get a lot of time to play around on) I would almost have to re-read a tutorial to remember how all the connections, etc. worked in IB. I think the main problem really was the disconnect though, so I'm looking forward to actually having everything there.

So, when will it be done? :D




It sounds to me like you don't have a very good understanding of your software's design.

That's understandable. Most other IDEs handle GUI development by simply mashing the view and the controller together into a single unit. That is fine if you just have a simple window with some buttons and text fields, but this approach quickly falls apart when applied to larger, more sophisticated software.

The Cocoa approach is different in that it completely separates the view (the NIB or XIB) from the controller(s). You're free to design your views, controllers, models as you see fit, and Interface Builder is there to help you realize that design.

But you actually have to design your software; XCode is not going to hold your hand and shoehorn you into a specific design, like most other IDEs.

A NIB is still a NIB. That's not going to change just because XCode and IB are now a single application. You will still have to design your software, and you will have to understand that design.

But software design is hard, so don't be discouraged. It will come with experience.


This is completely true! I'm very much learning as I go -- back at university when we did user interfaces it was all done in-code: I learned Java and TCL/TK without IDEs, then went on to do web programming and commandline stuff that didn't really need an IDE. So to actually start learning how to use an IDE I not only have to learn about design via IDE but also how the IDE works (also Obj-C, but that's another story) :)

And this is why I am still soldiering on with my little app (which is really just a learning opportunity for me rather than anything I plan on capitalising on, so it's okay for me to make mistakes :). I'd like to learn how to do it better, and you're right, that comes with experience. That said, I think the new XCode will help people like me a bit more because it will probably be easier to see the links between the UI and the code. :)


Partially disagree. The problem (at least what I've seen) is not view/controller dichotomy - most modern development platforms already have this.

I find the mechanism of connecting UI elements to outlets by dragging around to be gimicky and pointless.

Why can't the runtime auto-bind them by matching names? Doesn't ruby work this way?

There seems to be a bit of pointless work that you have to do to get a new controller and view connected and up-and-running.


I find the mechanism of connecting UI elements to outlets by dragging around to be gimicky and pointless.

Why can't the runtime auto-bind them by matching names? Doesn't ruby work this way?

The whole point of having the action/outlet system is that it provides a layer of indirection and lets you write less code. There's no need to write an event handler for a button to make it print a view. You just drag an action from your NSButton to your view, and set its selector to print:. The same goes for outlets.

I'm not sure what you mean by "auto-binding by matching names". The only way I could see that working, is if you gave the control and the target names, then inputted the action as (control name, target name, action). IMO this would be a lot more work than the current UI.


I'm not sure what you mean by "auto-binding by matching names". The only way I could see that working, is if you gave the control and the target names, then inputted the action as (control name, target name, action). IMO this would be a lot more work than the current UI.

Well, I was referring more to linking IBOutlets as opposed to IBActions.

I think Visual Studio's way is superior - ie, from the UI Designer, you can autogenerate and link the action for a button as well as having the option to link an existing action.


Well, I was referring more to linking IBOutlets as opposed to IBActions.

You still have the problem of selecting the object owns the outlet. You may want to connect a text field to an outlet on a view nested down a few levels. You'd have to give both the text field and the view names, which again takes time and effort.

I think Visual Studio's way is superior - ie, from the UI Designer, you can autogenerate and link the action for a button as well as having the option to link an existing action.

I haven't used VS for quite a while. IIRC there is always a user class associated with the UI. This is not the case in Cocoa. It's common for file's owner to be, say, a plain NSWindowController, and there to be no user classes in the nib at all.

It's tempting to think of an "action" in Cocoa as being synonymous with a method. But this isn't the case. When you click a button, it doesn't directly call it's action on its target. The actual process is more complex, and provides a lot of room changing where the action message is sent. This is what makes insane magic that is first responders work.


Alright, I'm sold. I never really considered any if those circumstances. I'm still feeling my way around.


It sounds to me like you've grown accustomed to a difficult, obtuse tool and don't like to hear that it is difficult and obtuse. That's understandable, you put in all that work to become proficient at a needlessly complex tool and it bothers you to see how simple interface design can be with a better tool. It makes you feel superior because you trudged through a hopelessly befuddled design and now that you've mastered it you can feel smug as you look down your nose at anyone who might dare suggest there could be a better way.

But software design is ever improving, so don't be discouraged when the world passes you by because you've stuck with your antiquated ways.


And 'visual tools' like IB quickly fall apart when trying to do dynamic layouts, or anything slightly out of the ordinary (in IB's case, you can't even do layout inside subclassed cells, necessary for almost any project).

This is a totally independent issue from view/controller separation. The right way to do UI development is through a layout language, like HTML/MXML, not through a GUI tool. The web world learned this a long time ago.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: