*- I'm a Java programmer who wants to migrate to ObjC/Cocoa.*
Welcome.
Unlike some of the others, I don't think Core Data requires an
advanced degree in Cocoa. However, in my experience, trying to learn
both Cocoa Bindings and Core Data simultaneously overwhelms many
people new to Cocoa.
Both technologies are designed to eliminate a lot of tedious adaptor
code. But if you don't have any idea what that code was supposed to
have done, it can be quite difficult to debug.
My recommendation would be one of the following:
(1) Focus on learning the UI and Cocoa Bindings. This is spending a
lot of time in Interface Builder, and learning about application
delegates and the AppKit widgets. Pick the 'Cocoa Application'
template.
(2) Focus on learning Foundation & Core Data. Build a command line
tool that does the Core Data processing you're trying to learn. Pick
the 'Foundation Toool' and add <CoreData/CoreData.h> to your headers
and the CoreData.framework from /System/Library/Frameworks/ to your
project in the 'External Frameworks' bucket.
When you're confident, go back and learn the other part. There's a
lot of overlap like KVC, KVO, delegates, accessor methods,
properties, so it's not as bad as it sounds.
*Amount* is an calculated field and it depends on the previous transactions.
I don't know how to do it! It is not a value I can save on database, for
example, because it changes all the time (I guess I have to mark the
transient field at Core Data).
As someone else mentioned, you probably want to move "amount" over to
Account as "balance". You can make it transient.
This is probably best handled with custom accessor methods. Create
custom subclasses of NSManagedObject for Account and Transaction and
set them in your model for the corresponding Entities.
You can get a head start on the proper structure and form of Core
Data accessor methods, by selecting the properties in the model
editor, and going to the Design->Data Model->Copy ObjC-2.0
Implementations to Clipboard and pasting them into source and
deleting all the ones you don't need.
On the Account's NSManagedObject subclass, override -value to check
if balance is nil. If it is, iterate over all the transactions, and
sum them. Create an NSNumber with the balance and set it. Then
return it.
Also, override the to-many accessors for the relationship from
Account to Transaction. The Design->Data Model menu will create all
of them for you. You can learn more about them in the Foundation
reference for NSKeyValueCoding's -mutableSetValueForKey: method and
the 'Key-Value Coding Programming Guide'. Have them also set balance
to nil.
On the Transaction's NSManagedObject subclass, override -setValue: to
tell its Account to nil out balance.
Probably missed something, but you get the idea. It's also possible,
but more complicated to make 'balance' persistent, and for many of
these operations to 'fix up' balance by a delta instead of forcing an
entire recomputation.
--
-Ben
_______________________________________________
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 [EMAIL PROTECTED]
