Re: Cocoa bindings and reluctance to use NSPopupButon
Re: Cocoa bindings and reluctance to use NSPopupButon
- Subject: Re: Cocoa bindings and reluctance to use NSPopupButon
- From: David <email@hidden>
- Date: Sun, 18 May 2008 21:57:59 -0400
This is a very interesting topic.I've been writing my first large Cocoa
application. New to objective-C and Cocoa, very experienced with Java.
I started out wanting to learn what facilities are available in this new
platform, partly to try to get a quick feel if it was worth switching to
rather than just writing the app in Java.
So I started with CoreData and was able to get most of the application
working with some trouble.
My first problems were really with Core Animation. I wanted to do what
seemed like a simple transition effect, yet it seemed way more involved than
I wanted to get into. I abandoned that effort after learning a reasonable
amount about Core Animation.
Then I tried to add some optimization to my Core Data application to handle
threading. Whoa. Big catastrophe. Found out that Core Data and bindings are
NOT threadsafe. I had taken it for granted that they were threadsafe. The
hoops that are required to use it in a multi-threaded environment are way
more involved than I was willing to invest in. And I realized as a result
that I was very much using the wrong tool for the job. Core data is too big,
too heavy weight for what was really a simple outline view requirement.
So, I backed down to use bindings. Bindings are working pretty well for
me... until....
Seems simple. I want to use a NSButtonCell in the first column of the
outline view. Again this seems to me to be the typical, in almost all cases,
use of a NSButtonCell in an outline view. Yet it seems like I've asked it to
make Martians. Too obscure. If I could find out what the message exchanges
are, it shouldn't be difficult. But a combination of minimal and hard to
find documentation, classes with unpublished interfaces and closed source
make it difficult for those not in the know.
So, I'm realizing that maybe its more reasonable to back down to just using
a data source, target/action and delegates.
I'm still having trouble understanding the delegate signatures when they
throw in some (id) types, I'm not sure what data types are expected.
In anycase, I started with the highest level facilities expressly because
I'm a newbie. Coredata and in turn bindings, seemed simple to configure and
use. I didn't have to learn all the underlying gorp. Sadly that doesn't seem
to be the case. It reminds me of trying to understand MFC without knowing
anything about Win32. It helps to know Win32 to see that MFC is simply an OO
wrapper around Win32 to understand some of its awkwardness.
In the end, unfortunately it makes me question if I've made the right choice
writing for Cocoa and Obj-C rather than Java. Much of the value add I saw in
Cocoa, with Core Data, Core Animation, bindings etc. has slowly whittled
away. I'm now fairly comfortable with Obj-C so I'll probably stick it out in
hopes that more value will become apparent over time.
On Sun, May 18, 2008 at 8:03 PM, Erik Buck <email@hidden> wrote:
> Johnny Lundy had a difficult time using NSPopupButon along with bindings.
> The struggles are archived via www.cocoabuilder.com for posterity. Mr.
> Lundy recently wrote "...I am still very very hesitant to put another
> NSPopUpButton on my interface, because of the complete absence of guidance
> on how to implement the thing, and the many days it took to get a single one
> working, and even now I have no idea why it works..."
>
> Having just now re-read Mr. Lundy's questions and follow-up, I don't think
> he had any problem with NSPopupButton at all. That makes sense because
> NSPopupButton is not particularly difficult to use. I think Mr. Lundy's
> struggles were all with "bindings." Had I been inclined to participate in
> the threads at the time, I would have said the following:
>
> 1) Bindings are an ADVANCED technique that was recently introduced and not
> yet completely documented. If someone tries to use bindings in a situation
> where he/she doesn't already know how to write the application without
> bindings, it is a mistake to use bindings.
> 2) Bindings exist to _reduce_ the amount of Controller code needed when the
> Model View Controller pattern is used. Bindings don't eliminate controller
> code and can't handle all Controller responsibilities.
> 3) Bindings appear to be magic, but they are in fact just an abstraction
> that enables reuse in place of commonly re-written controller code.
> 4) Bindings ARE NOT A REPLACEMENT FOR ALL CONTROLLER CODE, and bindings are
> often not the best technique to use.
>
> Mr. Lundy would have been better off writing his controller code explicitly
> and using the established outlet, target and action patterns instead of
> bindings. Not only would he have achieved complete control over all aspects
> of his application's behavior, he would have gained insight into how, and
> and why bindings work or not. I find that I hardly ever use bindings in my
> own applications. I am more comfortable doing things the good old fashion
> way in part because I often want very fine control over application
> behavior. I blame Mr. Lundy's specific struggles on misguided insistence on
> using the wrong tool for the job.
>
> I counsel Cocoa newbies to just forget about the Bindings inspector in
> Interface Builder and pretend they don't exist.
>
>
>
>
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden