On Oct 3, 2009, at 11:14 AM, Colin Howarth wrote:
This is a long (but witty and interesting) rambling post about
design, apple documentation, learning Obj-C & Cocoa and so on.
[ big, massive, much-needed snip ]
FOCUS!!!
I get that you're trying to be witty, but I was forced to skim much
of your "question" because it's mostly rambling. Witty is fine. Even a
good dose of funny irrelevance, but you do need at least a *little*
focus. :-)
Following will be matter-of-fact, but not at all hostile. Please
keep this in mind.
You appear to be saying / asking four things:
1 - The documentation is large and unhelpful.
2 - You're trying for your first real Cocoa application.
3 - Is Core Data right for your project?
4 - How do I model my idea?
A1: A lot of beginners complain about this. A lot of intermediate to
pros recognize that the documentation is far better than most
platforms. The trick is, you just have to take the time to familiarize
yourself with it. Study, study, study. This is a very large platform
with a lot of powerful technologies. It's not a toy language or API by
any stretch of the imagination. Finding your way around will take
time. Learning what are clearly labeled as "advanced" technologies
will require you to master the basics first (surprise!), so give it
time and study.
A2: All the more reason to heed the warnings and stick to basics.
Whether Core Data is a good match for your project or not (more on
that in a second) is largely irrelevant since you have already
indicated (I think - the rambling makes this hard to say for sure)
that you haven't read the more basic technologies upon which Core Data
is built. Therefore, your first app should use the most basic methods.
Build your data structures with dictionaries, arrays, and NSCoder-
compliant custom objects as you wish ... then write the main container
to a file. There's your document format. Start with the basics, then
move on to the voodoo.
A3: Is it right for your project? Possibly (see A4), but the better
question is, "is it right for my skill level?" Best answer: an
emphatic NO.
A4: The short answer: I have no idea. None whatsoever. It's hard to
tell what your model is because your e-mail is extremely disorganized.
I refer back to my opening point: You need to organize your thoughts
into pointed descriptions and questions. Throw in some funny as you
wish, but your entire e-mail is all but inscrutable. Clearly describe
your best guess at the model layer (not a stream-of-consciousness
ramble with lots of inline corrections) and the list will probably be
able to help describe how your Managed Object Model should be
constructed. As it stands, I couldn't tell what you were really trying
to build.
In closing: If you want help, follow technical mailing list
etiquette and ask coherent questions. If you want to ramble and
lament, tell it to the blogosphere. :-)
--
I.S.
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 (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/idiotsavant2005%40gmail.com
This email sent to idiotsavant2...@gmail.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
