whether to use core data...
whether to use core data...
- Subject: whether to use core data...
- From: Colin Howarth <email@hidden>
- Date: Sat, 3 Oct 2009 17:14:20 +0200
This is a long (but witty and interesting) rambling post about design,
apple documentation, learning Obj-C & Cocoa and so on.
I'm writing a raytracing / lens design program. This is basically my
fist serious attempt at a real Cocoa program, and whist I'm quite
happy with C and Perl, I don't like Java and hate C++. So far
Objective C is nice and simple, except that the compiler doesn't help
much :-)
I've read Aaron's 'Cocoa Programming for Mac OS X' (1st & 3rd
editions) which is, of course, excellent, and have Scott et all. 's
'Cocoa Programming' which is, ummm, big (and good) :-) (It's an old
2003 edition though, so doesn't have anything on Core Data).
I've got over the initial "Huh? What's going on? Where's the code?"
frustration. And the way IB keeps changing from one version to the
next. Now I'm happy with Aaron's "click here, ctrl-drag that there,
alt swish here - and look: it works!"
Right - now to the subject at hand...
Whilst scribbling some of my classes down on a bit of paper, and
sorting out which objects are supposed to know what, I ended up with a
class with just one instance (a singleton, I guess) called Lens. It
contains an array of glass data (refractive index, dispersion
constants etc.). It also contains an array of Elements (an 'element'
being a single lens-shaped bit of glass. A 'lens' usually has lots of
elements). [Well, that's wrong for starters! What does a Lens have to
do with Schott's glass catalogue? Answer: nothing. The Element class
needs to know what the various values are for the instances it creates
- but I don't want the whole table in each element. A class variable
in Element would have been ok...]
The actual program (which works) at present uses an array of Surfaces,
but I realized that's not right.
Say you're holding a simple element (e.g. a magnifying glass). What's
the surface made of? :-)
Also, how does a Surface know the distance to the next Surface? [--
embarrassed silence -- Well? -- OK, it has a pointer to the app and
accesses the app's array of surfaces... :-( -- Arrrgh! How *could*
you? -- OK, ok, I'm designing it now, all right?
Anyway, I ended up with a graph of Objects and methods which looks
nice and consistent and -- clean! :-)
The punchline:
Then, because it reminded me of something in Aaron's book, I just
added save:, load:, new: and -- undo: and thought "Ooooh, that looks
like a perfect example of a Core Data application...
The reason for the post:
There's *a lot* of documentation to read on Core Data [oh, and on KVC,
KVO, Instruments, Memory Management, Shark, GDB, Scripting, Unit
Testing, Cocoa Drawing, Quartz, OpenGL, OpenCL and various other
bits... "Haven't you read the documentation yet?", they ask. No, not
all of it.]
But the Core Data documentation starts like this:
...
Core Data is not an entry-level technology.
...
You should not simply try to read [The Core Data Programming Guide]
straight through to understand Core Data.
...
Do not attempt the NSPersistentDocument Core Data Tutorial unless or
until you also understand Cocoa bindings.
...
Although Cocoa bindings and Core Data are independent and address
different issues, both provide abstraction layers that—while
individually they are reasonably straightforward to grasp—can be
challenging to master simultaneously.
Bloody hell!
WARNING! Do not even ATTEMPT the NSPersistentDocument Core Data
Tutorial! Your very MIND is in MORTAL DANDER!
Now that's a shame, because save: load: sounds like a persistent
document to me. But if even Apple's documentation says WARNING, Do NOT
attempt to read the Programming GUIDE in order to understand Core Data
-- well, I believe 'em!
To be honest, I find Apple's documentation to be -- unhelpful -- at
the best of times...
On the other hand, somewhere else it says that if I'm starting a new
project (I am) or it does the sort of thing mine does (it does) I
should definitely consider using Core Data. It even says "you should
Definitely Consider it! OK? Got it? Good." which is sort of a threat.
Sooo, (you still with me?)
Should I face up to the dangers and brave the world of Core Data
(damn! even "Core" sounds intimidating now) because, of course, the
rewards (automatic undo, you don't need to write any code (hah!)) are
great. And Aaron's example (click, click, bind, bind, click, swish -
ooh! Look! You have an RDBMS with a GUI and undo -- and you didn't
even touch the keyboard! Is that cool?) looks enticingly *simple* :-)
Or should I just have a nice simple "Lens" instance, which contains an
array of "Element"s and will give me a nice array of "Surface"s if I
ask it. And then do something more interesting, like turning the point
spread function (done that) into a modulation transfer function,
creating merit functions and bounds and implementing the relaxed,
damped, orthonormal minimization routine? :-)
And finally, how do Apple manage to make load: save: undo: sound more
intimidating than quantum interference?
Thanks for reading.
--colin_______________________________________________
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