views:

252

answers:

3

I am making an Cocoa app with custom interfaces. So far I have implemented one version of the app using CALayer doing the rendering, which has been great given the hierarchical structure of CALayers, and its [hitTest:] function for handling mouse events. In this early version, the model of the app are my custom classes.

However, as the program grows I feel the urge of using Core Data for the model, not just for the ease of binding/undo management, but also want to try out the new technology.

My method so far:

In Core Data: creating a Block entity, with attributes xPos, yPos, width, height...etc.

Then, creating a BlockView : CALayer class for drawing, which uses methods such as self.position.x = [self valueForKey:@"xPos"] to fetch the values from the model.

In this case, every BlockView object has to also keep a local copy of xPos, which is NOT good.

Do any of you guys have better suggestions?

Edit: This app is a information visualization tool. So the positions, dimensions of the blocks are important, and should be persisted for later analysis.

A: 

Is editing and saving the position and size of these “blocks” the task your app exists to accomplish?

If not, that information probably shouldn't be in your model.

Peter Hosey
Yes. Position of these blocks are meant to be saved, for later analysis.
ivanTheTerrible
A: 

So in your implementation each  BlockView has it's own x?

Why not have your BlockView class hold a reference to a Block?

The view can be initialized with a Block which it uses to set it's position. 

This keeps a nice separation between your view classes and model.  

lyonanderson
+1  A: 

Using Core Data to store the actual run time locations of your graphics objects is not a good idea. Doing so mixes the data model directly with the view. This will make the app difficult to debug and maintain and will make its components far less reusable.

Instead, you should have core data provide any pre-exsisting position data to the viewcontroller when the view objects are created and then save the data when the processing is done.

Ideally, the view should work regardless of what kind of persistent store method you use and the persistent store method should work regardless of the type of view used to display the data. For example, you should be able to use the same data model for a view that uses a Webview, view that uses Core Animation or even plain text output.

TechZen