Hi all, I haven't done anything with Core Animation so I'm belatedly trying to learn it.
As a controlled environment to do this, I've written a simple game app that implements the old 'dots and squares' game. First I did this in a classic manner using a custom 'static' view to draw the board, now I'm adding animation. The app strictly splits things according to MVC. I have model classes representing the 'board', which contains all the 'squares' and together these embody all the state information about the game. This is managed by a game controller which creates the board + squares + players and also adds higher-level state such as whether the game is running or in 'game over' state and so on, and selects which player is up. Finally I have a view which more or less passively displays the game and resolves user input and passes that down to change the game state. This is on Mac but if it were ported to iOS (a further goal for this exercise is to learn to do that also) the only thing that would need to change significantly is the view - all the controller and model classes are portable. In adding animation, I'm finding that the purity of MVC is being severely compromised. The Core Animation programming guide states that layers are model objects, and I can see that's true in a limited sense (from the view's point of view). But in the context of a real app, they are definitely much more to do with the view - they have no impact on the game state and everything to do with how things appear on screen. And of course they must be hosted by a view. So my initial stab was to add all my needed layers to the view. I have layers for the board background, a layer for each square which are sublayers of this, and a layer which draws the walls in front (the walls are part of the state of individual squares, but are most efficiently rendered as a single path for all squares taken as a whole). Keeping the layers purely in the view was really painful - of course they have to be added to the view, but connecting e.g. a square's layer with a change of state of the square itself required either lots of notifications to be used or adding lots of methods to the view to pass along the state change. So I moved the square's layer into the square itself, so that state changes in the square can trigger animations directly. That seemed cleaner, even though there is still the need to perform some set up whereby the layers are collected from the squares and added to the view. The problem is that this seems to be putting into the game's data model stuff that is strictly view. A state-change in a square, which is a purely logical thing, now triggers explicit animations such as flipping which are appearance-related. This doesn't seem to be something the square should be doing, even though it makes the code nice and simple. It also makes the data model less portable (though CA exists on iOS of course). Another problem is the walls layer. The 'walls' are a bezier path generated by looking at the squares' walls state. This becomes the layer's content through delegation. The problem here is that it's easiest if this layer belongs to the board (model), yet the path drawn needs to be sized to fit the view, which is unknown to the model. And again, the board model object is doing things to the layer which have nothing to do with the game's state and everything to do with its appearance. I'm wondering how others deal with this. I've been looking at GeekGameBoard for inspiration and it seems to me that it litters its data model with CALayers. In fact, much of its model is embodied in layers, meaning that the whole MVC idea has gone - there is no place in that app that strictly models a given game's state without tying it to some particular animations. Am I worrying too much? Or is there a better way to think about layers that means I don't have to give up on strict MVC? Many thanks for any insight. --Graham _______________________________________________ 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
