Re: whether to use core data...
Re: whether to use core data...
- Subject: Re: whether to use core data...
- From: Colin Howarth <email@hidden>
- Date: Sat, 3 Oct 2009 21:59:08 +0200
On 3 Oct, 2009, at 18:08, I. Savant wrote:
[ big, massive, much-needed snip ]
hmmph.
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. :-)
Yes, Master. I'll try to focus.
No! There is no "try"! There is only "do" or "do not"!
OK. I am focussed.
Hey I get it! Lens Design Program... focus. Veeeery good! :-)
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.
Yes. A bit. Sometimes.
A1: A lot of beginners complain about this.
OK.
2 - You're trying for your first real Cocoa application.
That was just for background info. Wasn't a complaint or question, as
such.
(I was also trying to make it clear that I'm not a wannabe iPhone
developer,
with a "write my app for me" question.)
3 - Is Core Data right for your project?
That was sort of my actual technical question. :-)
Should I face up to the dangers and brave the world of Core
Data ... Or should I just have a nice simple "Lens" instance, [and
get on with the guts of the program]
... and you came up with an exquisitely simple, clear and precise
answer. :-)
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.
Thanks. Although, more precisely, the question is "should I dive in
now and get to grips with it, or leave it for later." which only I can
answer, I suppose.
4 - How do I model my idea?
Nooo.
Anyway, I ended up with a graph of Objects and methods which looks
nice and consistent and -- clean! :-)
I'm happy with my model. And I'm certain it would benefit from Core
Data.
A1: A lot of beginners complain about this. A lot of intermediate to
pros recognize that the documentation is far better than most
platforms.
That's not saying much :-)
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.
OK.
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.
No, I read the Core Data Basics chapter of the Core Data Programming
Guide, I'm happy enough with KVC and KVO for now - at least my
bindings between an NSTableView, NSArrayController and my NSArray are
fine. So, I'm sort of OK with bindings, notifications and delegation,
although not thoroughly immersed in the mind set. Yet. So, according
to the recommended learning path, the next step would be going through
the tutorial (which it later says, is NOT how you do things...)
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.
Right. Voodoo, later.
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.
Hah! It is not!
a) This is what I know so far.
b) This is what I've done / am doing.
c) I noticed that Core Data looks like it would fit well.
d) But, problem: The documentation looks a bit hairy.
e) Question: Should I have a go, or leave it for a bit?
I even put double lines in between sections :-)
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.
Damn! Just what I was complaining about :-(
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. :-)
wot? no chatting (about Cocoa) at all?
:-(
OK.
*sniff*
I shall confine myself to clear, concise, technical questions in the
future.
-- colin
PS. Thanks for your detailed reply
_______________________________________________
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