I have a view which contains a menu, it allows you to browse 5 different sections depending on where you click. When you click you are not changing page, you are hiding the other sections and showing the one you asked. It is required that everything occurs under the same Place.
From the View is simple and clean as each section is a different class and visually they are mutually exclusive. I access the controls of each section by "getting" the section itself
From the Presenter is a mess, I am having to register the handlers on the onBind() method for all 5 sections on that single presenter class, and all the logic of the events goes there as well, event handlers are beginning to conflict with similar names.
How can I break down the Presenter as I'm doing with the Views?
view Example
public interface MyView extends View {
public DeviceSettings getDeviceSection();
public Reports getReportsSection();
public License getLicenseSection();
public Support getSupportSection();
}
You can create PresenterWidgets/Views for each of your sections and then inject them into your MainPresenter.
You add handlers to your menu and then based on what is clicked just add/remove the corresponding PresenterWidget to your content slot.
You can check out the nested presenter example.
Related
I am playing around with Xamarin.Forms (mvvm) with Prism and have noticed that some tutorials show navigating to another Page while others show navigating to a View.
At a high level, I understand the literal difference... however I do not understand when I should use one over the other? I have an inclination that some of the reasoning is around dependencies, for example:
A Page has the instance of User > navigate to a view = User is still present when the back operation is used... meanwhile if you want this same behavior in navigating to and from a page, you'll need to pass the instance around via parameters... Is this correct/the reasoning behind navigating to and from views instead of pages?
In X.Forms View's are only visual objects, they do not support any navigation or any kind of infrastructure. They can only be showed when you navigate to a Page that hosts them, it doest not make sense the phrasing navigate to a View. So you should only use Page's.. In your example project they also only navigate to Page's. In the one you say they are navigating to "Views" it is only in the name, because ViewA is a ContentPage
Technically, in pure MVVM, the ViewModel should know completely nothing about the View and vice versa. When you use Page First Navigation approach you violate the first sentence. Here is an example:
class MyViewModel
{
}
class MyView
{
public MyView()
{
InitializeComponent();
// Alternatively you can do the same thing in XAML
this.BindingContext = new MyViewModel();
}
}
As you see the View is aware of the ViewModel.
When you use a ViewModel First Navigation approach, the decision of which
View should have witch ViewModel is delegated to a dedicated class. This class then is used in a custom NavigationService to match a ViewModel to a View. So it will be possible to navigate from a ViewModel to a ViewModel. This way both ViewModel and the View know nothing about each other. The disadvantage of this approach is complexity.
This is a very short answer, however, I hope you will get the key point. There are many examples of both approaches:
ViewModel First Navigation
Page First Navigation
P.S.: Prism has very nice mechanism that handle navigation. What I wrote above and the examples that I provided are just for low level understanding of this approach. If you want to use Prism you definitely have to be familiar with it.
I have a few stacked views, for one I would like to do some checks and in certain cases remove the View from the stack.
The view should be removed/hidden during initialization, before the user gets to see the view.
The views are registered using the org.eclipse.ui.views extension point and stacked using the org.eclipse.ui.perspectiveExtensions (relationship="stack").
I tried the following but the view is still visible:
#Override
public void init(IViewSite site) throws PartInitException {
site.getPage().hideView((IViewPart) site.getPart());
}
I guess there is a way using IPartListener or IPartListener2 but I would prefer some nicer way.
My GWT app will have 4 - 5 different views but each one will have 2 similar buttons on the bottom of the view. The function of these buttons will vary between each view but their appeararnce/position will remain the same. Is there any design strategy that I could apply in this case? Could I go down the road of having a base panel class that adds the buttons and each extending class then implements the different functionality or is there a better way to do it?
Create a composite widget BottomToolbar consisting of a panel with two buttons. Add two methods to this widget: setLeftButtonHandler(ClickHandler handler) and setRightButtonHandler(ClickHandler handler).
When you add this widget to the view, your Controller/Activity/Presenter (whatever you use) only needs to set these handlers.
The best to do is to create one view that takes a controller which is different for your 4 or 5 views.
This is a basic MVC pattern : your view can be instanced several times but user can interact differently depending on the controller you give to the view.
Then, you can also extends your main view to provide more ui differences.
I have two ListViews (in separate views). These views are bound to separate view-models but the ListViews contain the same entity type. Both views allow the user to select an item and navigate to it's detail/edit view.
What do I need to do to share this detail view between the two list views?
Here is what I have tried:
Assign the selected item to a property in the detail view's view-model
This initially appeared to work but actually breaks Kendo MVVM. Since the item is in the list view's view-model, assigning it to a property in another view-model causes problems.
Refresh data in each view's show event
While this almost works, it has a couple problems. 1) Getting fresh data all the time can be slow. 2) When saving changes in the detail view and navigating back to the list view, the save is async, so there is no guarantee that those changes will have been persisted before the call for ListView data. This also negates one of the benefits of MVVM and observables.
Share the view-model across views
The examples I have seen that have a list and detail view, have both views sharing a view-model with a selectedItem property. This is not possible in my particular case because I have two list views that navigate to the same detail view - not to mention that I prefer to have a separate view-model for each view so that the view-models don't become a huge mess. Am I supposed to have all views share a single view-model?
What am I missing?
Maybe you could extract the observable model to a plain object model with the toJSON() method, and then create a new observable model from it by wrapping it again. This should clear the existing bindings and avoids the conflicts you've found in your first approach.
var model = kendo.observable( otherModel.toJSON() );
I'm using WPF and trying to program the MVVM way.
I understand how every view has its own view model and this works quite well. I am struggling to manage the interaction between views though.
Say I have two views, View1 and View2, each with its own ViewModel, ViewModel1 and ViewModel2. If I have a combobox on View1 and a button, what is the correct way to close the first view, notify the second view of the selection and show the second view once the button is pressed? It doesn't seem like it should go in the model because it's a UI thing. The ViewModel shouldn't know how to open and close WPF forms (or should it?) And the views shouldn't know about any other ViewModels (or should they?)
So how are these problems solved? In a nutshell:
1) How is data passed between views?
2) What manages the lifetime/visibility of views?
It will depend on whether you are doing view model or view first, and the exact implementation details will depend on if you are using an MVVM framework. If you aren't using a framework, then I would strongly recommend you start using one.
In your example, when the button is pressed, a method on ViewModel1 will be invoked. If doing view model first (which I would recommend), you would instantiate an instance of ViewModel2, and at this point you could pass in the combobox selection to the constructor of ViewModel2.
Depending on your framework, there will be different ways of then displaying the view associated with ViewModel2.
For 1) you can sychronize data through the DataModel. Provided each view shares the same instance of the DataModel and it implements INotifyPropertyChanged multiple views can be updated simulateneously.
Your sesond question is a matter of design, as #devdigital states it can depend on whether it is View first or ViewModel first. I would consider the introduction of a Controller class in much as the same way ASP.Net MVC works which controls which view is displayed. You can expose a ViewClosed event on the ViewModel which the controller can listen to and based on your workflow open another view.
You might consider introducing Controllers which are responsible for the lifetime management of the ViewModels. Furthermore, they mediate between the ViewModels.
The sample applications of the WPF Application Framework (WAF) show how these Controllers can be implemented.