Animations are a strange mix of view and control, and they sometimes need to be synchronized with delays between them, callback to code, etc.
So, without being specific to any particular GUI framework, where should I put my animation code in a MVC architecture?
This is such a general question, but I would be inclined to put this completely in the view if possible. You could think of it like jQuery animations which have a final value and a duration - you could think of this being handed off to the view, which could take care of everything at that point.
Related
I created a custom NSView that displays some data exactly the way I want it to (a line chart of sorts). I now want to add a couple of sliders to have the ability to zoom the displayed data in and out. I would also like to add a couple of checkboxes so that the incoming data can be interpreted and graphed in different ways, and maybe some scrollbars to be able to see past data. I need to have at least 5 copies of this view (with all its controls) on screen at the same time, each showing a different data feed.
This way of thinking a user interface falls nicely into the WebComponents paradigm where you can design a component that encapsulates many different ones. As I understand it, there is no way of nesting controls like this into a master control in Xcode.
Of course I could layout all the views and all the controls separately inside a view controller and achieve exactly what I want but it would not be as maintainable as having ONE object that I can duplicate either in interface builder or in code.
My question is: what is the proper way to achieve this in Xcode (if any)? I don't need code examples but rather a conceptual answer and I'm only interested in answers related to Cocoa rather than CocoaTouch.
I just learned that you can have multiple view controllers as child controllers. This is exactly what I was looking for as it maximizes reusability and reduces maintenance.
I have an animation and I want to show several time hints at certain points.
What is the best way of doing that?
I tried to make events in animation.. and call function which should notify the main GUI class, that something changed, but I am not sure if it is a good solution.
(actually I do not know how to do it effectively).
Or I can make a loop in my main GUI class, just reacting to time.. but I am not sure if the synchronization will be ok.
If it is a cutscene like animation, I would use these animation events. This way it is easy to edit it later, if something changes in the animation. If you calculate seconds in the code while playing the animation, it will be a maintenance hell.
This question is about a Cocoa app I'm working on but it could apply to anything using an MVC or related architecture.
Who is responsible for animations?
I can see two arguments:
1) Animation code should exist in a view (part of a view's presentation, how it draws itself) but be controlled by a controller (interpreting user input, etc).
2) Animations and their lifecycle should be managed completely by a controller and act on the views belonging to that controller.
I think first option is better because it would be fast if we can handle the events at view itself. Animation is most of the cases do not need additional data...so there is no need to reach to controller.
I think an animation is a modification of the model which is shown by the view. That's why I see the animation handling in the controller.
Views are, by definition, supposed to be logicless. When a user interacts with a view, it notifies its controller. When state changes in the app, the controller notifies the view. But I'm confused as to the nature of the communication between view and its controller when it's time to re-render some or all of the view.
Let's pretend I'm making a two player card game. The view is responsible for showing the deck, the discard pile, the cards in players' hands, and any other UI components. When a player plays a card, the view needs to reflect this change, and it's the controller's job to notify the view to do so. Which of these options is the best way to handle this event?
The controller tells the view simply to re-draw. The view, through the controller, has access to all the parameters of the game state. It uses these parameters to re-draw everything including the deck, both player's hands, etc.
The controller tells the view that a player played a card. The view knows that when a player plays a card, only that player's hand needs to be re-drawn. Like option 1, the view uses the parameters of the game state to determine how to re-draw the player's hand.
(Similar but different from 2) The controller tells the view to re-draw that player's hand and passes it all the parameters needed to do so. The view has no access to game parameters.
Any other approach I'm missing?
Option 1 seems to be the easiest two write because the view is stateless -- it just re-draws everything every time. But for that same reason, it is very wasteful. We don't need to draw both player's hands when just one player played a card. It's also difficult to do things like animation because every time we re-draw, we're essentially throwing away our old canvas and building a fresh one with all new view components.
On the other end of the spectrum, option 3 seems to be best in terms of removing logic from a view, but it comes with some issues. First, I've found it more difficult to write because it's imperative that all the proper messages are sent to the view. If any are missed, the view won't properly reflect the state of the app. Second, it seems like a full re-draw is still necessary at times for when, say, the user is restoring a saved game in progress.
In both options 1 and 2, the view "pulls" data about the game state whereas this data is "pushed" to it in option 3. Should views be able to request information like this, or does this imply that there's too much logic in the view?
Thanks in advance for any light you can shed on this topic!
MVC is not the best fit for all applications. It also depends on what kind of frameworks which are available.
By not taking the platforms/frameworks into account I'll say that HMVC (Hierarchical model–view–controller) or PAC (Presentation–abstraction–control) is a better fit for you since a page can be splitted up into several parts (three views: hands & deck).
When it comes to native applications (GUI) it seems like MVP is preferred over MVC.
Martin Fowler has a nice article about the different GUI patterns here: http://www.martinfowler.com/eaaDev/uiArchs.html
I am building a complex iPad application; think of it as a scrapbook.
For the purpose of this question, let's consider a page with two images over it.
My main view displays my doc data rendered as a single UIImage; this because I need to do some global manipulation over them. This is my DisplayView.
When editing I need to instantiate an EditorView with my two images as subviews; this way I can interact with a single image, (rotate it, scale it, move it). When editing is triggered, I hide my DisplayView and show my EditorView.
In a iPhone app, I'd associate each main view (that is, a view filling the screen) to a view controller.
The problem is here there is just one view controller; I've considered passing the EditorView via a modal view controller, but it's not an option (there a complex layout with a mask covering everything and palettes over it; rebuilding it in the EditorView would create duplicate code).
Presently the EditorView incorporates some logic (loads data from the model, invokes some subviews for fine editing, saves data back to the model); EditorView subviews also incorporate some logic (I manipulate images and pass them back to the main EditorView). I feel this logic belongs more to a controller. On the other hand, I am not sure making my only view controller so fat a good idea.
What is the best, cocoa-ish implementation of such a class structure?
Feel free to ask for clarifications.
Cheers.
Huge fat controllers are fine.
If necessary, just break off some "purely logical parts" from it and shove them in other "helper classes". And use tricks like categories extensively where you can.
Definitely go with a HFC (huge fat controller) if that feels right.
Then, just get on your engineering bike and slim the hell out of it!
You should definitely not avoid the right structure, the good structure, the structure you want, just because one thing will be too big.
Just slim that big thing down by outsourcing concepts, going nuts with categories, etc etc - every trick in the book.
My belief!
Some reasons to wrap a viewcontroller around your view:
to use it in an Apple API that requires a viewcontroller (popover views, modal views, navigation bars, tab bars, ...)
because the view can be invisible for a while, and so it makes sense to clean it up in low memory situations. The viewcontroller then guards the data that needs to survive such an unload-reload cycle.
because you just like the MVC pattern
I think the second bullet justifies a viewcontroller for your editable content view and another one for your non-editable content view.