For a long operation that will be executed in presenter, where to set the wait cursor?
in View? the view shouldn't know too much about business logic, it is passive.
in presenter? seems odd in presenter to call UI code.
add method to View interface, like SetWait(bool), and call it in presenter?
So what do you think?
I usually do it as no.3 from the presenter tell the view to show the user a "long running operation" feedback... whatever that means for the view (wait cursor, message, etc.)
Related
So I was always taught that the correct cycle is that a view (e.g. a dialog in a gui) only holds display features and no functionality -- it is "dumb" in a sense.
In the view you then have listeners for when a user presses a button, and when that happens, the view communicates to the controller that the button was pressed (via an observer pattern), and then the controller does the appropriate action -- update the GUI and model. So the view never interacts with the model.
But then there are other versions like the one below, in which the view interacts with the model directly.
It's kind of annoying that there are so many different variants across the internet and no one standard thing -- so what really is the correct mvc style for GUI apps???
There is no "correct" way. Different people have come up with different interpretations. Maybe you would like to read the answers of a similar quora question.
For your own sake you can settle on the interpretation that is most appealing to you (or that is the company standard). Best is just to stay with one interpretation and not use different approaches for every piece of the software.
I am trying to show the progress of my windows form application in a panel within the form. However, all the messages show together at the end of when the application completes executing. Is there a way to display the messages as the code - execution "progress" through these messages - just the way it would in an interpreted language?
PS: I am adding the message as a label control to the panel at different points within the code.
Thank you.
You have to invalidate the label every time you change the message:
label1.Text = "Initializing...";
label1.Refresh();
// Do Stuff
label1.Text = "Working...";
label1.Refresh();
// Do Stuff
label1.Text = "Completed.";
label1.Refresh();
Or, it may be worth using a backgroundWorker (or another thread). Whats happening now is that the main thread (the one that also draws the UI) is too busy doing the processing to update the UI.
I'm not sure what language you're using, but Ill assume C#. In that case, create a BackgroundWorker that reports progress. Call the Background worker asynchronously so that it does the processing and use the Reports_Progress event to set the label. You cant set the label in the main Backgroundworker do_work procedure since the label was created by another thread. See this example, it may help (admittedly he sets a progress-bar value but you can just as easily set label text - http://www.dotnetperls.com/progressbar)
If you dont have the Backgroundworker class, you can implement the same logic, just using a different thread.
If you need some more info, let me know.
I have in my model an object, that when modified requires a large number of other objects to recompute values based on those changes.
The way this is currently set up, is that this one object can only be modified in one place. This is a sheet with a Cancel and an OK button. Once the user commits the change, the sheet shows a progress bar and starts processing the objects affected by the change. The presentation and dismissal of the sheet are wrapped in a NSUndoManager group. The user may undo all changes in one pass after dismissing the sheet.
What bothers me is that I keep thinking that all this should happen at the business level. Rather than at the controller level. I.e. I should be able to modify my business object any place in the UI and code and have it trigger the necessary computations.
So I would set up KVO to watch my object and trigger the long running operation when needed. Once I go down that path, I start hitting walls.
How do I coalesce changes? My object has several attributes. I don't want to start a computation when the first attribute is changed and the second is likely to change next. Basically I need an edit sheet and some control point to commit all changes at once.
How do I add a UI to this long running operation? I could have an NSOperationQueue attached to the NSManagedObjectContext and have my window controller observe that. When the queue is not empty, I would pop up a sheet with a progress bar monitoring the current operation.
How can I implement Undo/Redo support? If I delay recomputation to an operation running after the fact, I cannot imagine how to undo the initial change and the propagated once at the same time. I can only imagine undoing the original change and having that trigger another reevaluation of all other object.
In short:
What is the best practice for such dependancies?
Is the propagation a job for the model layer or the control layer?
I believe I came up with a solution:
the center-piece model object watches itself for changes
on change, it creates or amends a ToDo object
the controller watches for new ToDo objects
the controller dequeues the ToDo, presents a progress-bar and performs the operation
Say you're building a Tetris game. As any proper programmer, you have your view logic on one side, and your business logic on the other side; probably a full-on MVC going on.
When the model sends its update(), the view redraws itself, as expected.
But then... if you wanted to add, say, an animation to vanish a line, how would you implement that in the view?
Make any assumptions you want---excepting that "Everything is properly encapsulated".
Personally, I would separate draw the screen as often as possible, even if there was no update of the block position. So I would have a loop somewhere with an "update" and a "render" part. Update plays the ball to the logic which does or does not any update of positions and/or block removal. Render plays the ball to the graphics part, which draws the blocks where they should be.
Now if there are lines to erase, the logic knows and can mark those lines to be removed. I assume here, that every piece consists of 4 single blocks and any of these blocks is a single object. Now when this block has the "die"-flag set, you may take some render-parts to vanish the block (let's say, 500ms to explode). After this time, the object may be disposed and the block a line above falls down. Why 500ms? Well, you should definitely use time-based movement as this keeps the game speed the same on different computers.
Btw, there are already so called game engines which provide such an update-render-loop. For example XNA, if you go the .NET line. You may also code your own engine but beware, it's not an easy task and it's very time consuming. I did this once and don't expect it to be an engine like the Source Engine ;-)
Most games execute a loop that constantly redraws the view of the game as fast as possible, rather than waiting for a change in the model state and then refreshing the view.
If you like the model view pattern, then it might work well for the view to continue to draw some types of objects after they are removed from the model, fading them out over a few milliseconds.
Another approach would be to combine class MVC with something like differential execution - the 'view' is a model of what is presented, but the drawing code compares the stream of events the 'view' creates with the stream from the previous rendering. So if in one stream there's a line, and the next there isn't, the drawing code can animate the difference. This allows the drawing to be abstracted away from the view . Frequently the 'view' in MVC is a collection of widgets, rather than being something which draws the display directly, so you end up with nested MVC hierarchies anyway: the application is MVC ( data model, view objects, app controller ), where the view object has a collection of widgets each of which is MVC ( widget state (eg button pressed ), look and feel/toolkit binding, mapping of toolkit events -> widget state ).
I've often wondered this myself.
My own thoughts have been along this line:
1) The view is given the state of the blocks (shape, yada-yada), but with extra "transitional" data:
2) The fact that a line must be removed is encoded in the state, NOT computed in the view.
3) The view knows how to draw transitions now:
No change: state is the same for this particular block
Change from "falling" to "locked": state is "locked in" (by a dropping block)
Change from "locked" to "remove": state is "removed" (by a line completion)
Change from "falling" to "remove": state is "removed", but old state was "falling"
Its interesting to think of a game as an MVC. Thats a perspective I've never taken (for some odd reason), but definitely an intriguing one that makes a lot of sense. Assuming you do implement your Tetris game with an MVC, I think there are two things you might want to take into account in regards to communication between your controller and your view: There is state, and there are events.
Your controller is obviously the central point of interaction for the user. When they issue keyboard commands, your controller will interpret them, and make the appropriate state adjustments. However, sometimes the game will enter a state that coincides with a particular event...such as filling a line with blocks that should now be removed.
Scoregraphic has given you a great foundation. Your view should operate on a fixed cycle to maintain consistent speed across computers. But in addition to updating the screen to render new state, it should also have a queue of events that it can perform animations in response to. In the case of filling lines in Tetris, your controller could issue strongly typed event objects that derive from some kind of base event type into the view event queue, which could then be used by the view to perform the appropriate animated responses.
I have a set of nonGUI objects which have a one to one realtionship with GUI objects.
All events are routed through the top level window.
Many ( not all ) events occuring on the GUI object result in calling a method on the associated object.
Some methods in the NonGui objects which when called change the GUI objects.
One example would be some sort of game like Rogue with a modern GUI.
You have the area a player occupies in one turn ( call it a region )
and you have the object ( a button ) associated with it on the GUI.
Keep in mind it's only an analogy ( and not even the real problem ) and no analogy is perfect.
The question is, how does one design this sort of thing?
Since the button class is from a third party library, I cannot imbed a reference to the nonGUI object in it, though I can imbed a reference to the GUI object in the nonGUI object. So it looks likeI will have to create a map from a buttons to "regions" somewhere, but where do I put it? In the toplevel window? In the top level model?
Do IU spin off some sort of interface class?
Suggestions?
It would help if you mentioned your platform and language, but generally it sounds like you are describing Model-View-Controller.
Your "GUI" object(s) are the View. This is where you keep all the rendering logic for your user interface. User interactions with the View are handled by the Controller.
The Controller is a thin layer of event handles. User interaction calls methods on the Controller, which then routes them to the Model.
Your "non-GUI" object(s) are the Model. This is the object that contains business logic and whose state is ultimately updated by clicking buttons on your GUI.
You mention "embedding" references between the objects. This is not necessary as long as events in your GUI can be routed by some mechanism to your Controller. This design pattern is useful because it separates your UI logic from your business logic. You can "snap on" a new Views very easily because there is very little event wiring between the View and the controller.
The Wikipedia article has more information and links to implementation examples.
Waste a little time looking at Falcon's Eye (though it is Nethack rather than Rogue). There's a long history of skinning rogue like games (or command line apps in general), which isn't quite classic mvc - it already has a full UI, instead you're adding a decorator to that UI with either a direct translation, or another metaphor (such as gparted, the gnome partition editor, which allows construction of a sequence of partition editing commands by direct manipulation)