• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Okay I have those pieces... now where's the g lue?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Okay I have those pieces... now where's the g lue?


  • Subject: Re: Okay I have those pieces... now where's the g lue?
  • From: Nathan <email@hidden>
  • Date: Tue, 27 May 2008 17:16:21 -0400

I'm not joining your discussion here, just giving you a nice linkie. Cocoalab.com has done a great job with their tutorial, becomeanxcoder or something like that. It assumes you have no knowledge of C, and it has put me into a great position, I'm able to use other tutorials now.

On May 27, 2008, at 5:09 PM, Erik Buck wrote:

How do I allow controller A to send commands to controller B and vice
versa? If controller A initialized controller B, then A knew about B, but
what about the other way round?

1) A can have an instance variable that points to B.
2) B can have an instance variable that points to A.
3) A can be the delegate of B. (specialization of 2)
4) B can send notifications that A observes.
5) B can send messages up the responder chain. If A is in the responder chain it will get a chance to respond to the message unless some object earlier in the chain consumes the message.
6) B can access A through a global variable...perhaps [[NSApp delegate] doSomething];
7) A can observe properties of B. (not recommended for newbies)


Which technique you choose depends on the problem you are trying to solve and the design of your application. All of these techniques are common Cocoa design patterns. In a total vacuum of information, I bet you want option 4.

But as only Controller A knows about B and not the other way round
this seems not possible.

This seems like a good scenario to use notifications or the responder chain.


I have created a NSPopupButton in IB. I also created some MenuItems
for it in IB.
How can I identify the current menu item?

Don't store application state information in user interfaces.
Have each menu item send a different action to your controller and have the controller update the model accordingly. Don't poll the state of a user interface item.


Alternately, have all of the menu items send the same action and use the menu item's tag or representedObject or even its index to determine which menu item was selected. Then have the controller update the model accordingly. Don't poll the state of a user interface item.

Ps: Is there any generic(!) open source app that you would recommend
me to study to learn more about how to structure an app at best?

Many Cocoa developers learned via the Sketch sample application or its predecessor. There are many good Cocoa examples on your hard disk and at developer.apple.com. There are also opensource Cocoa projects that you can find with Google.


_______________________________________________

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:
@mac.com


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


References: 
 >Re: Okay I have those pieces... now where's the g lue? (From: Erik Buck <email@hidden>)

  • Prev by Date: Re: Okay I have those pieces… now where's the glue?
  • Next by Date: Re: Cover Flow in Cocoa?
  • Previous by thread: Re: Okay I have those pieces... now where's the g lue?
  • Next by thread: if statement
  • Index(es):
    • Date
    • Thread