Re: Newbie Bindings questions: Alarm clock application
Re: Newbie Bindings questions: Alarm clock application
- Subject: Re: Newbie Bindings questions: Alarm clock application
- From: Mike Abdullah <email@hidden>
- Date: Mon, 8 May 2006 11:48:08 +0100
Hi Greg.
You are indeed correct that you should only need one
ObjectController. So,
1. Instantiate a copy of your model object, I'll refer to it as
alarmModel
2. Instantiate a single NSObjectController as well (this is all in
your nib file)
3. Set the content outlet of the controller to be your alarmModel
4. Go to the attributes of your controller. In the keys box, add a
key for each variable of your alarmModel. So I expect you to have a
list along the lines of:
*fireDate
*repeatAlarm
* etc.
5. Select one of your interface elements and bring up the bindings
inspector for it
6. Bind to controller
7. Controller key selection
8. Key path - the appropriate keyPath from your controller
Should be as simple as that :)
One thing to note is that there is no need to make boolean instance
variables in your app NSNumbers. You can use BOOL just fine, the
Bindings system will convert things to NSNumber if it needs it.
I'm afraid I've never played with NSMatrix and bindings so I can't
help you there.
However, with regards to multiple windows, I would personally go with
the document architecture and simply remove the menu items for saving
and loading. This way you get a nice convenient, pre-written way of
handling things.
Mike.
On 8 May 2006, at 11:18AM0, Greg Hurrell wrote:
I'm not a Cocoa newbie but I *am* a bindings newbie. Ever since
bindings came out I've been trying to get my head wrapped around
them without success. I am currently trying to put together an
alarm clock application as a way of teaching myself about bindings.
Unfortunately, things that I would have thought would be easy with
bindings are not proving to be easy (or possible) at all, and I'm
wondering if I am trying to use bindings in ways in which they were
not intended to be used. I have a few doubts and questions.
I began by setting up a window in Interface Builder. I added some
checkboxes for things like whether the alarm timer should repeat or
not, a pop-up menu for choosing what should happen when the alarm
goes off, a slider or an NSDatePicker for choosing when the alarm
should go off etc. This was before writing a single line of code.
My plan was to start hooking things up with bindings and writing
code as needed along the way.
The only thing I've ever had success with with bindings up until
now is using NSUserDefaultsController, but this little app doesn't
have any preferences. I've also checked out the many NSTableView-
related examples at http://homepage.mac.com/mmalc/CocoaExamples/
controllers.html but this app doesn't have any NSTableViews either.
The first code I wrote was a model class that contains all the
information about the timer window with instance variables for each
aspect of it. An NSDate for storing the "fire date", NSNumbers for
storing boolean values like whether it should repeat or not (I used
NSNumber instead of a simple BOOL because it seems that bindings is
built for objects, not scalars).
But my first doubt is that in order to bind any of this stuff in my
nib I had to instantiate multiple NSObjectControllers. For example,
one for the "fire date", one for each check box etc. I would have
thought that I could just use a single controller, seeing as I have
a single model class behind the scenes, and somehow access the
instance variables of that model class via that single controller.
But no, the only way I can get it to work is to have a dedicated
controller for each instance variable. This just seems wrong. Am I
doing this in completely the wrong way?
Basically, in each NSObjectController I set the contentObject to
bind to my model class, and I use the instance variable name as the
"model path". Then I bind the views to the controller with the
controller key set to "content" and the model key path left blank.
This works but it feels wrong to have separate controllers for
every instance variable. I've tried to throw out all these separate
controllers and just use a single one but I can't get it to work,
either binding to "content" or following the pattern used by
NSUserDefaultsController and binding to "values". The other thing I
note is that because you *have* to define a "model path" I can no
longer just pick a single instance variable; so that forced me to
create a new NSMutableDictionary instance variable and use that
instead, packing all the other variables that were previously
instance variables into the dictionary. I'd be prepared to persist
with this if I didn't have so many doubts about the validity of it
from a design standpoint (and not even knowing if it will be
possible to make it work). Basically I just need someone to give me
a hint about how the heck I should be proceeding.
I also can't seem to achieve even very simple stuff with bindings,
like enabling/disabling checkboxes depending on which radio button
is selected in an NSMatrix. Everyone sings the praises of bindings
and how it enables them to get rid fo their glue code, but I just
can't get this to work and I'm going to end up writing old-
fashioned glue code anyway!
And finally, I'm totally confused about how I should handle
multiple alarm clock windows at once. Should I be worrying about
NSWindowController, NSDocument etc? I've read the documentation on
document-based apps and am not sure what to do because the alarm
clock windows aren't technically documents (I certainly have no
intention of saving or printing them) but I'd like to be able to
have multiple such windows in my little test app. From the
architectural/design standpoint, what Cocoa design patterns and
classes should I be thinking about using here?
Sorry that I don't have any more specific questions. I basically
just need some reassurance and to be pointed in the right
direction. I've spent many many hours experimenting, poring over
sample code, reading the list archives, and I *still* feel totally
ignorant about bindings. I'm hoping someone with experience can
give me a nudge in the direction that I should be going.
Cheers,
Greg
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40gmail.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden