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 (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
