I am doing a silverlight using the MVVM model, and i am finding it hard to do the events handling via MVVM especially that the events handlers are doing lots of changes in the view like enabling and disabling buttons, update media element functions and position. I am still new to the MVVM and i can't Imagen how can i do this. does anyone already know good article to start with or simple approach to understand :) I'll reply with what i may find interesting while i do my search as well. Thanks
1) Understand that there are different "flavors" of MVVM. Strict/hardcore MVVM patterns, although theoretically desires, isn't necessary.
2) Many view events can be handled via Commands. WPF supports this, and i believe Silverlight 4 does as well. A simple view-event to start with would be Button clicks. This allows you to handle the event in the ViewModel (instead of the View's 'code-behind').
3) For things like enabling/disabling view controls/states via the MVVM model, here is an example/explanation:
Xaml controls (say, a Button) is Data-Bound to the ViewModel for whatever property
(in this case, it will be the button's IsEnabled property).
Your ViewModel has an IsButtonEnabled property.
Whenever you change this property in the VM, raise the PropertyChanged notification, and you will see the binded result in the view (the button's IsEnabled state will be updated).
ps - you can do many things via VM properties in this manner: from text, to various property states, color, you can even play animations in the property setters/getters....etc.
Cheers
Related
https://github.com/brianchance/MvvmCross-UserInteraction is a very nice plugin for showing cross platform Alerts!
But for this question, can we assume it can not use a UIAlertView (or some other top level MessageBox type call on other platforms) but needs to show a Message within a given subsection of the screen (i.e. on IPhone you would need to supply a UIView to the plugin which it will use to show the message within).
So, how would you set this up so the ViewModel knows what View to use as its display container?
As a specific example, if I wanted an Error Service, as so -
public interface IErrorPFService
{
void Show();
void Hide();
void SetErrors(List<Error> errors);
}
and I create a platform specific implementation for it.
If I inject this into my ViewModel so it can control Error Show/Hide/Set how do I tell it the UIView (or equivalent) that I want my Errors to show within?
Can I just expose the IErrorPFService field as a public property and do -
MyViewModel.ErrorPFService = new ErrorPFService(View);
in my ViewDidLoad ...
Or is this coupled incorrectly vs Mvvm Practice?
I would expect the ViewModel to subscribe itself to the ErrorService.
When receiving a message it would expose it in a collection(?) and the View would bind to that collection.
This way the View is unknown to the service and the ViewModel has the chance to influence the View contrary to your solution.
It would help if you could give an example for the scenario you are describing.
Sometimes, the way you visually want to display something might not be the best way, so if it's possible for you, you might find a different and simpler way, which spares you from having to find a solution regarding what you are describing.
Generally, I always do the best I can to avoid the idea of having to actually pass a 'view' or an abstraction of it, from the view-model to view. Also, cross-platform wise, things can work very different in terms of UI interaction. You can find yourself in a situation when things are complicated just because UI works differently than what you expected.
But let's try find another perspective:
At any given point, the view knows what data \ feature it's displaying. So when you are calling from the view-model an user interaction action (by a service, property change, event, etc) the view should 'expect' it.
For example, the platform specific user interaction implementation is able to get the currently displayed top-view and interact it in a platform specific manner or based a relationship. In your example, the message-box can be displayed in a specific sub-view of the top level view.
In advanced scenarios, I guess you could try to create a cross-platform approach for this, but you should try to put in balance all the abstraction you want to create just for that. Think about doing this as a plan ... Z. If possible. Again, giving an example might help.
I have a property on my ViewModel called LostFocus, and I want the View to know when this changes so that it can act on this info if it pleases (i.e. maybe the designer of the view might make it blur if LostFocus is set to true, or maybe they won't do anything).
I'm using Caliburn.Micro, so if it has any features I should be aware of here please do tell. Otherwise, how would you go about doing this in an MVVM fashion?
This can be accomplished with ordinary data binding as I understand it. Since you're using Caliburn.Micro, the designer can use conventions to do the binding. For example, if there were a check box control on the view that was to be checked when LostFocus is set to true, the designer would just have to ensure that the Name property of the check box was set to LostFocus and then Caliburn would set up the binding automatically.
Also, on your View Model, make sure you raise the property changed notification event when you change the value of LostFocus.
You could also, rather than using a LostFocus property, create a LostFocus event on your view model. You could then raise this event whenever you feel it's appropriate and then, on the view, the designer could respond to that using an event trigger and trigger action. For example, on one of my projects, I set up an event trigger to respond to the view model's Activated event and then I wrote a custom trigger action to play a storyboard that was responsible for doing the view's intro animation. This approach isn't restricted to Caliburn.Micro, but I did use it on a Caliburn.Micro project, so it definitely works.
I ended up learning about the BindingConverter and used that to convert a boolean property of false to null and true to a BlurEffect.
Where exactly is the limit to adopt VM so it can suite better a particular View? Example:
There should be a command in UI (ex button) that should allow adding new item. Additional requirement can be that new item should be selected, ensured that its visible on control (lets say TreeView control), and to begin edit on the newly added item (in order to change predefined value that was set in VM). Lets assume that control doesn't have automatic mechanism to achieve this, so we need to do it manually. So the execution flow looks like this:
invoke add command on VM - done is View's xaml.
set SelectedItem to new item (usually we bind control's SelectedItem property to VM's CurrentItem property, and then just assign new item to CurrentItem.
ensure that new item is visible on control - this must be done in View's code behind.
Start editing - this must be done in View's code behind.
Now, since everywhere on net there are articles on using messages for almost everything, a question:
What do I break if I do it in the simple old fashion way? I use Click event instead of Command binding on adding new item, and in the method I do this:
// in View's Click event handler
ViewModel.AddCommand.Execute(null);
EnsureVisibleSelectedItem();
BeginEdit();
.. clean and clear! And what do I gain if I do it using messages:
// in ViewModel's AddCommand
AddNewItem();
SetCurrentItem();
SendMessageToEnsureVisibleSelectedItem();
SendMessageToBeginEditSelectedItem();
... where View has registered to receive these two messages.
Any light on this is greatly appreciated. To my opinion, UI can change, and VM should be able to adopt new UI without making changes to itself, so I dont quite understand current MVVM policy that is preached on internet.
I would say "make it simple".
What's really important in MVVM is:
what doesn't depend on the view should go in the ViewModel (your ViewModel must not be aware of the view in any way - not just by object reference)
everything else in the View and its code-behind.
Yes, in its code-behind. There's nothing wrong in writing code-behind if it is code that is related to the view, not logic. For instance, drag & drop management should be written in the code-behind.
To answer your question, you do not break anything in writing:
// in View's Click event handler
ViewModel.AddCommand.Execute(null);
EnsureVisibleSelectedItem();
BeginEdit();
Everything that is not related to the view is in the ViewModel, everything else in the View/code-behind. That's just fine.
No if I look at your second example:
// in ViewModel's AddCommand
AddNewItem();
SetCurrentItem();
SendMessageToEnsureVisibleSelectedItem();
SendMessageToBeginEditSelectedItem();
AddNewItem is OK (not related to the view), SetCurrentItem is OK (not related to the view), but what about SendMessageToEnsureVisibleSelectedItem and SendMessageToBeginEditSelectedItem?
EnsureVisible is typically useful for a treeview, but what if your view wasn't built with a treeview? What if the control would automatically make the new selected item visible? Of course you could ignore the message, but you would have written some useless code in ViewModel because you thought your view would need it for UI display.
You have typically written here some code in the ViewModel that is aware of how the View should be working. Yes, you have reduced the number of lines in the code-behind, but you definitely have broken the pattern.
Your "old fashion way" is actually a good way for your needs. Your ViewModel is not aware of the view, that's what's important.
Consider these two scenarios:
a user presses a button in a view (e.g. Fulfill Order) and we want the view to update immediately (disable the button, add a progress bar, etc.)
a service layer raises a business event, which ultimately must be reflected on the view (e.g. a product has become out-of-stock).
Both cases legitimately require some mechanism, X, to update the viewmodel. With MVVM, the view can do this by setting properties of the viewmodel in an event handler, through command binding, or via some other mechanism.
The service layer can do this using some mechanism, Y. For example, raising events in the business/domain model, creating commands to manipulate the viewmodel, calling methods on the viewmodel etc.
In fact, X and Y could be the same mechanism (or pattern).
What's a good one to do this, that keeps to the spirit of MVVM, but is DRY?
I think you need to pick an MVVM framework and follow the pattern for this that it supports.
In general:
Your button will be hooked to a FulfillOrder method on your ViewModel, via an ICommand or whichever your MVVM-framework supports
A "CanFulfillOrder" boolean property will be hooked up to disable your button via INotifyPropertyChanged, this can be triggered by the FulfillOrder method or the event you mention. It could also be bound to the Visibility on a progress bar.
Another property could provide the percentage on the progress bar and update it appropriately
A good, general-purpose MVVM framework is MVVM Light.
If you are looking for more power, and can handle more complexity, try Caliburn.
Or if you want to use dynamic and try something cutting edge, try my framework: NoMvvm.
I have been using the MVVM Light Toolkit to help learn the MVVM pattern. However, I have not been able to solve the problem of usercontrols within controls scenario.
For example, in a Timesheet application, lets say we have a control called NewUnitOfWork. When it first loads, a panel with a ListBox with a list of projects is loaded as the Content of the NewUnitOfWork. The user clicks on one. A new panel is swapped in with a ListBox containing the possible tasks for that project. A task is selected and a new panel is loaded which will contain controls to input data for the chosen task of the chosen project.
So, we have the selected item in one usercontrol being passed to the other two user controls, which are, in turn swapped in as the Content of the NewUnitOfWork control (or window).
If each control has its own ViewModel, we need to pass the selected value from one ViewModel to the next etc.
I have got it working in a single user situation using global variables (via a "service"). However, there are concurrency issues with that and it is not a good solution. It's sub-par.
I have seen many times the suggestion on this forum to have on ViewModel as a member of another ViewModel. Whilst this solves the problem at hand, I believe it is a violation of the MVVM pattern. Another ViewModel is not UI-related functionality that the ViewModel shoule be directly.
So. Has anyone found a clean MVVM-complying way to do this sort of thing?
Cheers
Please always keep in mind that MVVM is just a pattern and it is designed to help you separate your UI and logic. Do not be afraid to “violate the pattern” if it helps to increase testability or maintainability of the application.
Having a master ViewModel with several child ViewModels is very handy if you have a complex UI. The main ViewModel may be responsible for handling the top level UI controls and for coordination of the child VMs, while other ViewModels are responsible for communication with the sub regions of your UI.
Moreover, if you have a really complex UI with the multiple nesting UI layers, you can implement an infrastructure to automatically cascade all the events from master to child VMs.
And of cause, you may try to use one of the more advanced MVVM frameworks. For example Catel implements pretty comprehensive model to resolve such situations with nested VMs.
I don't see a problem with ViewModels referencing other ViewModels (based on my experience with TreeViews). Have a look at any article about TreeView and MVVM. You will see that each node is a ViewModel, that references a collection of child nodes, which are ViewModels. Trying to do that without VM-VM references would be a nightmare.
Josh Smith
http://www.codeproject.com/KB/WPF/TreeViewWithViewModel.aspx
I have been using the following setup:
A 'master' VM with a 'collection' VM and a 'details' VM as nested properties.
The master VM is tied to a View that is used as a master-detail form. This master-detail View is composed from two other Views.
I find it a very neat setup because it allows me to put search criteria in the master View(Model) and keeps the other View(Model)s clean.
I can't see how this would break the pattern.