Re: Handling preferences changes
Re: Handling preferences changes
- Subject: Re: Handling preferences changes
- From: "I. Savant" <email@hidden>
- Date: Thu, 3 May 2007 14:07:29 -0400
On 5/3/07, Steve Israelson <email@hidden> wrote:
I am trying to decide on the best way to handle changes to my
preferences.
...
These settings are all stored in a CoreData DB.
Maybe I'm not getting something, but ... why wouldn't you store the
application's preferences in the application's preferences (ie, using
the established preferences mechanism)? See NSUserDefaults and
NSUserDefaultsController. The former is *the* Cocoa preferences
mechanism, the latter is an NSObjectController subclass that lets you
use Cocoa Bindings with the former.
Oh, and don't think of Core Data as a "DB". You'll get yourself in
trouble making that broad an assumption. Read the very beginning of
the introductory documentation - Core Data and a relational database
share many things in common, but they have plenty of things "in
UNcommon" that means you don't use both for exactly the same sorts of
things.
1) Each UI object that makes use of any one setting retains that
setting and observes changes made to it. Also must observe changes
made to the object that indicates which style group to use. This
means that there are potentially many many observations going on.
Retains?? ... I think before worrying about anything else, you
should read everything you can (and make sure you thoroughly
understand) the concepts of KVC/KVO (key value coding / key value
observing) and the Cocoa Bindings mechanism. There are plenty of
various articles available via Google in addition to Apple's
documentation. Live it, learn it, love it.
2) The preferences controller can observe everything and detect
changes made and then broadcast a general message indicating that
some preference related to UI changed and all UI objects can the re-
render. This would mean every little change made will cause a re-draw
of everything since knowing what changed is not handled.
... which would make using Core Data and Cocoa Bindings kind of
pointless, wouldn't it?
Also, try not to think of a state change causing redrawing. That's
totally outside the realm of what you need to worry about (unless
you're creating your own control with its own actual drawing code). If
your controller were responding to a state change in a specific
preference, it would of course be checking to see if the state is
actually different than the UI control it's governing, then if it is,
it would tell the control to -setState: (or something like that) and
the control itself would worry about redrawing itself *if necessary*.
Anything less is poor practice.
Since you're not writing a custom control, whether it redraws itself
or not is really none of your business from a design standpoint. Just
don't make unnecessary calls to set a control's state and you've got
nothing at all to worry about.
Anyway, see above - use NSUserDefaults/Controller and store your
app's preferences where they belong. Use the Cocoa Bindings mechanism
and let *it* worry about handling / reflecting preferences state
changes automagically. *Don't* worry about whether it'll cause
unnecessary drawing (see "premature optimization").
3) ? Your cool solution here.
I suppose people could invent all sorts of cool (but redundant)
solutions, but the established mechanisms are time-tested and work
well. Use them.
What follows is my opinion only, take it as you will: I think at
this point you're trying to tackle too many big things at once (using
several rather involved technologies together without first mastering
any one of them) and your head will likely explode. Stop it. ;-) Take
a step backward, slow down, and delve into the documentation a little
more before you get lost and slap together a barely functioning
clunker of an app. You'll do neither yourself nor your users any
favors by rushing your research.
--
I.S.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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