Re: Getting a handle on CoreAnimation and MVC
Re: Getting a handle on CoreAnimation and MVC
- Subject: Re: Getting a handle on CoreAnimation and MVC
- From: Graham Cox <email@hidden>
- Date: Wed, 25 May 2011 12:28:07 +1000
On 24/05/2011, at 11:49 PM, Joanna Carter wrote:
> I would definitely argue that this kind of design is not really "cleaning up" the design but, further, polluting it :-)
>
> In the Cocoa world, the Controller is a very important part of getting the non-UI code to connect to the UI elements and to respond to gestures made through those UI elements.
>
> I would venture to suggest that you are tending to think of the visual elements, put together in IB, as the View; I would rather think that you could look at creating View classes, which can hold the appearance "properties" and, to which, the UI elements should be bound to achieve their "look and feel".
>
> The MVP concept of Interactors, responding to UI gestures can be "emulated" by a Controller class, looking after the "input" side of things, whilst a "View Presentation" class would become the "output", from which UI elements get their data.
>
> I could go on further but would rather get to know if you think this makes any sense or needs further explanation.
Thanks for the ideas Joanna, much appreciated.
I'm not familiar with MVP in a formal way, but what you say makes a lot of sense and in many ways fits with what I have done in other designs, e.g. DrawKit.
Regarding this particular situation though, what you seem to be suggesting is closer to my original approach, but here's why it sucked, compared to the "polluted" design I have now. In this game, there is a board consisting of a regular grid of cells. I'm modelling this using a 2D array where each cell is addressed using a (row,column) index. Each cell has various properties.
Now when I first attempted to keep the presentation aspects of the design separate from the model, I started out by having a second 2D array in my view which held the CALayers for each of the cells. The view would use the same row,column index to access the layer and go back to the data model to link changes in the cell to animations on the screen. Each property of the cell had to be observed (using KVO or classic notifications) to trigger the appropriate animation. Keeping these two separate but strongly related 2D structures in sync required a lot of setup work to build the second array, and hook up all the observations.
In the second iteration, the second presentation 2D array has gone and each cell looks after its own CALayer. When cell properties change, the appropriate animation is triggered directly. There is no set up required at all except to add the layers as sublayers to the view's backing layer. No observations are needed, and there is only one main structure so there is nothing to keep in sync. Animations are triggered directly and so "just work". That's why this seems to be a much cleaner design. Why it worries me is that it puts the presentation behaviours - the animations - firmly in the domain of the data model, which just seems wrong. But the alternative was far worse :) It's certainly acceptable for this simple little game, but how would that scale to a bigger, more sophisticated app where animations should definitely not pollute the data model?
The design of CALayer seems to encourage that it should become a major element of any data model in having arbitrary properties that it will archive automatically. Apple say it's a model object, but it seems to me to be a very schizophrenic one, since it is overwhelmingly concerned with appearance.
--Graham
_______________________________________________
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