Design pattern for core data, document based, graphical application
Design pattern for core data, document based, graphical application
- Subject: Design pattern for core data, document based, graphical application
- From: Kenneth Baxter <email@hidden>
- Date: Mon, 16 Aug 2010 18:18:13 -0700 (PDT)
- Date-warning: Date header was inserted by spool002.mac.com
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 (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