Re: whether to use core data...
Re: whether to use core data...
- Subject: Re: whether to use core data...
- From: Brent Gulanowski <email@hidden>
- Date: Sun, 4 Oct 2009 15:38:14 -0400
The best way to learn all this stuff is a step at a time.
On Sat, Oct 3, 2009 at 11:14 AM, Colin Howarth <email@hidden> wrote:
> 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 :-)
>
Liking Objective-C means you will not approach it with a hostile attitude,
which will make it easier to work with it.
>
> 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 wonder if Aaron and Scott (and don't forget Erik) get a warm glow when
they get praise on Cocoa-dev? ;-) (I read them too, back when they first
came out.)
> 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...]
>
Right away, if you don't just jump in to Core Data, you're already missing
one of my favourite parts: the model designer. That thing is a serious time
killer. Much better than scribbling on paper. Omni-graffle or similar is
also nice for defining larger modular chunks graphically (I love it for
sketching client-server protocols and architectures).
>
> 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...
>
I'm afraid your conceptual model is foreign to me, and absent a fuller
description, its hard to evaluate your data model or whether it is well
suited for a persistence service like Core Data, but it would probably work
great. I think the best way to decide depends on how customized your
objects' behaviours have to be (versus being able to leave the framework to
do the majority of the management), how many objects you're dealing with (if
it's dozens, you won't get performance benefits, but as you said you might
get other benefits, like Undo), and whether you'll get any benefit from Core
Data's enforcement of your model's rules, managing deletion behaviour, etc.
>
>
> 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.]
>
Every tool has its benefits. You don't need to use them all immediately, or
master those you do use. ISoftware development is an advanced profession,
with lots of tools available for those who make their living from it (like
me). Investing time in learning them has paybacks in software quality, which
saves money (in support costs).
You'll find that you'll pick up the tools and technologies as you need them.
The essential basics would be:
- Objective-C
- fundamental Cocoa patterns:
- memory management
- KVC/KVO
- the fundamentals of bindings
- delegation
- essential Cocoa classes:
- container classes
- archivers and the NSCoding protocol
- the responder chain
- the fundamental application classes: NSApplication, NSWindow,
NSWindowController
- NSView and the general details of how the drawing system works, inc.
the view hierarchy
- the document architecture (NSDocument, NSDocumentController)
- the Xcode build system
- Interface Builder
- and the basics of GDB
If you've gotten through most or all of that, there's no reason not to dive
head-first into Core Data. Or at least to put a toe in.
>
> But the Core Data documentation starts like this:
>
> ...
> Core Data is not an entry-level technology.
[snip]
> Bloody hell!
>
> 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...
>
The Core Data and Cocoa Bindings docs are ... intimidating. Fortunately,
sample code goes a long way to getting over that hurdle. In fact, just
starting with an Xcode Core Data template and adding things one at a time,
and seeing how they work (or fail to work), and then comparing what you've
done to sample projects (there's lots around on the 'net, along with lots of
other tutorials) will teach you more, more quickly, than reading the docs
alone ever could.
>
> 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* :-)
>
The basics are straightforward. But the next steps can be exceedingly
frustrating if you miss even one fundamental concept. But don't let that
stop you. Obstacles are inevitable. The docs could never cover everything.
They'd be boundless. And dead boring. Because you'd never find the exact
info to solve the specific problem you will run into simply by sheer volume.
That's why they invented mailing lists.
>
> 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.
>
>
Go play with Core Data. If you don't like it, you can always find another
way to do what you want, including rolling your own SQLite wrapper (we've
got a couple in my company) or using one of the many others that already
exist. At least they'll let you use straight SQL if you feel like it.
Here's something that uses Core Data, which, though abandoned, unloved, and
not very useful, might show you some techniques to get you started.
http://bitbucket.org/bgulanowski/branchline/
--
Brent Gulanowski
_______________________________________________
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