Design pattern for core data, document based, graphical application
Hi, I am working on an application that uses core data at the back end, and the NSPersistentDocument architecture at the front end. It is a graphics application which essentially displays a tree of objects, destined for 105+ deployment. I also want the functionality available by AppleScript. I have created a couple of applications in Cocoa, but that was about 5 years ago, and I need to work with the latest technologies now. I am familiar with the MVC model, but am finding it difficult to really tie down the controller layer in the architecture, and am not certain about how the messaging should work. How I'm thinking of it is that I have a view controller for my canvas view, which uses KVO to observe when children objects are added or removed in my tree structure in core data. In the old way of doing things I would have had one big canvas view with a controller for each graphical object as it was added, and have it responsible for drawing itself within the canvas view. This would also allow me to have overlapping objects, and keeps the number of views down below the recommended 100 max per window. I could still do that, and have each of those controllers register themselves for KVO notifications on anything that should change how the object looks on the screen, but that would seem to leave me out in the cold as far as animations go (apart from just using an NSAnimation as a timer to call back to the controller for each object). I understand that in 10.5, views became more lightweight, and also gained the ability to overlap, so maybe I could create a view controller and view for each graphical object. If I go this kind of route, I am not sure of the drawing classes I should be using. I want to use animation for moving and reshaping my graphical objects. It looks as if I can just use an NSView directly and use -animator, or can get the views to be layer-backed, or use CALayers. The dynamics of the application are that is would be very unusual for there to be more than 500 of my graphical objects on the screen at once, and typically a user action would make about a dozen objects change shape (not just a transform - they would have to redraw each time), and another 50 move. Sometimes one graphical object is partially or wholly on top of another. It is possible that I may want to make an iPad version of this app later, so would like to choose the best technology to minimize rework to do that (I guess that would mean drawing everything in CG rather than NS methods, but am not sure of the overall view class choices). Recommendations? Then we get to the user interaction... I can tie the values back directly to the core data counterparts (using bindings in IB), but that skips the controller layer in the middle, and as far as I can see, would mean that I would have nowhere to put an undo action name, and also when someone changes something on my objects, in some cases I want other things updated synchronously, and sometimes asynchronously, and a controller layer would seem the place to trigger that. What is the right way to go about this? Should I ignore bindings at the user interface layer, and have IBActions to my view controller, and have that use manually configured bindings to update the model? If I was exposing all this to AppleScript, would I be able to leverage my view controllers etc, or would I have to use a different architecture? Thanks, Ken.___ 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
Re: Design pattern for core data, document based, graphical application
On 16 Aug 2010, at 8:18 PM, Kenneth Baxter wrote: > If I was exposing all this to AppleScript, would I be able to leverage my > view controllers etc, or would I have to use a different architecture? I believe Apple's sample code for "Sketch-112" will put you a long way into your quest. Search for "Sketch" in the Xcode documentation browser. — F ___ 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
Re: Design pattern for core data, document based, graphical application
You have too many design options on the table. Try some of them in
mini-prototypes to see how well they work and then drop some of the ideas.
I have used Core Data to store Model data for 2D and 3D drawing/visualization
applications. My approach was to use the Core Data designer to specify custom
subclasses of each Core Data entity (NSManagedObject subclass). Then I don’t
touch the custom subclass files themselves. I add methods for drawing to each
subclass in categories. That way, the designer can regenerate the subclass
interface and implementation files as many times as needed without impact to
the code added in categories.
For example, a Core Data entity for a “GraphicalThing” might have a “color”
attribute stored as an archived NSColor instance in NSData. It might have an
“isFilled” attribute stored as a Boolean. Then, a “CircleGraphicalThing”
sub-entity of “GraphicalThing” is implemented as a subclass of GraphicalThing
and add float attributes for “centerX”, “centerY”, and “radius”.
Drawing pseudo code might be
@implementation CircleGraphicalThing (Drawing)
- (void)drawInContext:(id)aContext
{
NSColor *currentColor = [self transientColor];
if(nil == currentColor)
{
currentColor = [NSUnarchiver unarchiveObjectWithData:[self color]];
[self setTransientColor: currentColor];
}
[aContext setColor: currentColor]
[aContext drawCircleAtCenter:CGPointMake([self center], [self centerY])
radius:[self radus]];
}
@end
Drawing is not the Controller's responsibility. Drawing is a View
responsibility, but in a drawing application, Model objects draw. If you need
to support multiple types of View such as an OpenGL View in addition to a
Quartz2D View, just have multiple categories. Add a -drawInOpenGLContext:
method in a different category. Store the category implementation files as
part of the View subsystem even though they extend Model objects.
Most of your other questions are resolved using Controllers in ways that are
independent of the Model details. For example, synchronous side effects are
handled nicely by bindings that are set up in Interface Builder without any
impact to the Model. A synchronous notifications are discouraged but can be
accomplished with -performSelector:withObject:afterDelay: or by putting
notifications in an NSOperationQueue, etc.
___
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
Re: Design pattern for core data, document based, graphical application
Thanks Fritz - I had a look at the Sketch example, and see how it implements the AppleScript. I see also that it uses the concept of a single canvas that has objects that can draw on it. I think I'll have to do some testing with the other scenarios to see how performance would go using views or layers. Things like the "video wall" application Apple made make me think that I should be able to get good performance using those technologies. On 18 Aug, 2010,at 01:00 AM, Fritz Anderson wrote: On 16 Aug 2010, at 8:18 PM, Kenneth Baxter wrote: > If I was exposing all this to AppleScript, would I be able to leverage my view controllers etc, or would I have to use a different architecture? I believe Apple's sample code for "Sketch-112" will put you a long way into your quest. Search for "Sketch" in the Xcode documentation browser. — F ___ 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
Re: Design pattern for core data, document based, graphical application
Thanks Erik Having the model doing the drawing directly like that is something I hadn't thought of. Definitely worth considering. I'll still have to observe changes in related attributes to trigger UI updates, and I have many ancillary objects that need to be involved in the process, so I may have to factor them in as supporting classes or something like that. Anyway, that gives me a good starting point, and gives me the flexibility to represent the objects on whatever view hierarchy works without having to change things. Time to start making a few prototypes to test out the different design options... On 18 Aug, 2010,at 01:33 AM, Erik Buck wrote: You have too many design options on the table. Try some of them in mini-prototypes to see how well they work and then drop some of the ideas. ___ 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
