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: Tue, 24 May 2011 22:33:11 +1000
On 24/05/2011, at 3:05 PM, Quincey Morris wrote:
> On May 23, 2011, at 18:27, Graham Cox wrote:
>
>> 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?
>
> I'll take a stab at this -- not pontificating, just expressing an opinion, and a hesitant one at that ...
>
> There's nothing *intrinsically* wrong with the data model encapsulating the appearance of "views", if the appearance *is* the data that needs to be manipulated. You may, therefore, have made things hard for yourself in this exercise by choosing a game as your paradigm for investigation. It seems likely to me, in a general sort of way, that a game is indeed going to concerned at the data model level with both the appearance of the views and to some extent the UI interactions the user will face.
>
> The "V" in "MVC" doesn't really refer specifically to views (and the baggage they drag in like windows and input methods, etc), but to the logical concept of a "view" of the data -- an arrangement, a filter, a massaged representation of the underlying data model. It's a pragmatic decision, in any given application, where to draw the line between MVC "V" and MVC "M".
>
> What if you use a different kind of application to investigate Core Animation, one that (Core Animation aside) fits much more easily into the MVC paradigm? I'm thinking of something like a simple catalog (or store) application, where the product database is the data model. There could, of course, be product images or movies in the database, so this example would not be totally devoid of questions about how the display of things interacts with the data model, if it does.
>
> The other thing that comes to mind is that I'm pretty convinced there is no viable MVC pattern, as such, except for the simplest applications. Every real-life example I've worked on has had a "back end" data model (the "M"), but has always had an auxiliary data model embedded within the "C" (such as a window controller) which meditates between the back end and the "V" (the user interface). In this sense, the MVC pattern is really a M(MC)V pattern, and sometimes it's even a M(MC)(MVC) pattern, if the views themselves are complex enough. It's possible that layers properly belong to one of the mediating data models, not to the back end.
>
> Maybe you are worrying too much, but if you figure it out, let us know. :)
Thanks for your comments Quincey, as valuable as always.
Of course I'm simplifying when discussing MVC - I have rarely found a case that's "pure" in the sense of just M, V and C as well, usually there are several layers of controller and the data model is distributed among different objects as well. I felt the game example might be advantageous because it's a very simple game which is easily modelled, though even there I ended up with 3 classes to do it.
However, you may have hit the nail on the head in saying that a game is also going to have to compromise because it's very much concerned with how the thing is presented - the game *is* the presentation as much as anything - there really isn't much you can do with the abstract data model in this case except present it and interact with it. That said, my original non-animated design was very clean in that all the on-screen stuff was restricted solely to the view class.
I've now moved a number of "view-like" properties into the data model - things like the background colour of the board and so forth - these were originally conceived as properties that the view layer brought to the party; the game logic does not need to know what colour the board is, but then again, it's reasonable to think of this as a property of the board itself. By doing this and letting the relevant model object create and manage the CALayer that ultimately represents it on screen, I'm back to a clean design, just one where the animation layers are woven into the model and controller layers.
I guess the thing I've learned is that adding animation as an afterthought to a classic 'static' view approach might not work well - it's better to design it with animation in mind from the start so that the placement of layer objects can be inserted more appropriately. I'm not sure I can yet generalise what I've learned in this case to app design in general though.
--------------
As a follow-up question more particularly related to CALayer:
I'm setting an image (CGImageRef) as the 'contents' property' which the layer scales down on the screen - the image is rendered at 256 x 256 offscreen and the layer on screen varies in size up to this amount, but is usually smaller. The image includes a rendered shadow which when drawn directly is nice and smooth, but in the CALayer rendition is clearly much less so. Seemingly the drawing context used by Core Animation has a lower level of image antialiasing set.
Is there a way to access the drawing context used by CALayer so I can set the image interpolation value to high? I couldn't see an obvious way to access it, or even whether the question makes sense. As I understand it CALayer is really generating a texture for OpenGL so perhaps there's nothing can be done to render images at a higher quality?
--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