Re: Handling preferences changes
Re: Handling preferences changes
- Subject: Re: Handling preferences changes
- From: Steve Israelson <email@hidden>
- Date: Thu, 3 May 2007 11:33:49 -0700
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.
Well, the file will likely be stored in the location that the prefs
are stored in.
I am not using the prefs mechanism since the data I have is an object
graph (the DB).
Using CoreData and bindings allows me to make the entire preferences
UI with no code.
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.
You MUST retain the object to be sure it is around for KVO to work.
Otherwise CoreData will get rid of that object and you are observing
nothing.
In any case it does not work without retaining the object I am
observing.
I'll read up again in any case, maybe I'll get a little more out of
the docs.
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?
Well, no. Using KVO is a kind of binding all by itself.
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).
Bingo, yes I am. Plus some settings for stuff that can be configured
in a table view too.
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.
If I have 100 controls (views) in several different windows, having
one object track em all and decide what needs drawing would seem to
be a poor choice. Really, only the view itself KNOWS what settings it
is making use of, so only it knows what to look for in regards to
changes. In other areas its the controller that knows about the
changes. I suppose I can put all view configuration into the
controllers and then all prefs changes can be know about by the
controller.
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.
But I am in some cases.
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").
Well, when my settings are tables within tables of data (a DB, sort
of), I don't see how writing code to manage these just so I can let
the defaults controller save it to disk gets me anywhere.
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.
Unfortunately I can not go to my customer and tell them to come back
in a year.
I feel that using technologies in a real world app of some complexity
makes for a better understanding of the issues involved in using any
one technology.
_______________________________________________
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