I am trying to make a web app with GWT and I am trying to use the MVP design pattern. It looks like an Activity is pretty much the same as a Presenter but a presenter is more specific to a certain view, which means a Presenter should knows the special methods/elements the view supports.
But there are two options to do the same thing.
a) Let Presenter extends an Activity with additioanl methods needed by the view.
b) Let presenter and activity hold a reference to each other. In this case, the activity will do generic operations and presenter will do view specific operations.
Could anyone please help point out which option is more viable? Thanks!
As always with architectural design decision: it depends.
I'd recommend starting simple, where the activity is the presenter; i.e. one class plays both the role of an activity (driven by the activity manager) and the presenter (that drives the view).
And if the need arises, split them. Either to obtain smaller more maintainable classes, or because you start having different lifetimes (in GWT's mobilewebapp sample, the TaskActivity lives longer than the presenters, and can switch between 2 presenters during its lifetime).
The rule of thumb is that activities are for navigation, and you can switch between several tasks without necessarily navigating (where each task would have a bookmarkable URL). In the case of the modilewebapp sample, switching between viewing and editing a task does not navigate between them.
Having separate activities and presenters also means that you could have different ways of navigating in different apps, sharing the same presenters but not the same activities (note: activities are already about that kind of dychotomy, but there are times where it doesn't really match, such as whether you consider switching between viewing and editing a navigation between "pages" or just switching task in the same "page").
Related
Is there any library / framework that could simplify Universal Windows Platform app development of the application that contains multiple Frames.
I mean, using MVVM Light or BezySoftware MVVM-Navigation the application is highly tied to the idea of navigating between different pages that are hosted by single frame.
The UI I try to develop consist of multiple content frames (main, left, right) which content varies. I need something that will let me navigate easily between different views (by placing these views into appropriate frame) and provide the same features I would have with BezySoftware MVVM-Navigation, so:
handling of the view model state persistence
the ability to activate / query deactivate view models
back button feature
Few different options:
Combination of a single navigation service injected into your view model AND user controls for areas that need to be repeated view to view (e.g. a tabs, status bars, etc). With this route, every time you create a new view you would paste in the common user controls that need to appear. You would also be able to expose bindable properties from said user controls.
Combination of ContentControl, DataTemplate, and DataTemplateSelector to load in either an entire view (Page) or fragments of XAML. As one person pointed out you cannot use DataType attribute, instead you use the DataTemplateSelector class to do the mapping for you. With this approach you can also use triggers to dynamically change the template (content) based on changes to properties on your view model and/or user interactions.
A mix between 1 and 2 above.
I might right the whole thing right here, but it too lengthy. I just recommend you see this article to get your answer.
MVVM patter in UWP
I try to understand how the gwt example about activities and places works (https://developers.google.com/web-toolkit/doc/latest/DevGuideMvpActivitiesAndPlaces). I am wondering why they define an interface for the presenter. I know the view interface is helpful to exchange the view easily. But what's the use of the presenter interface?
Its always a best practice to design application with interfaces rather than concrete classes.
Reference - What does "program to interfaces, not implementations" mean?
Reference - WikiPedia example for MVP
Another key factor in MVP architecture to make your design pretty clean is defining an Presenter interface(As we already know the beauty of interface OOP conceptin JAVA).
Presenter interface that allows our View to callback into the presenter when it receives an event. The Presenter interface defines the following:
public interface Presenter<T> {
void onAddButtonClicked();
}
And then you can set the presenter to your view like below
private Presenter<T> presenter;
public void setPresenter(Presenter<T> presenter) {
this.presenter = presenter;
}
Finally when your PresenterConcreteClass implements your presenter interface those implementations will triggers.
Besides the cleanliness of using an interface, there's also no reason you wouldn't test your view. You could use end-to-end tests, but you can also simply use a GWTTestCase where you instantiate the view and use a mock presenter.
You'd then be able to test that “when I click on this button, it should call this method from the presenter with the values X, Y and Z as arguments”, or “when I call this method of the view with those arguments, then such widget should turn red and that other one should hide/collapse/show/whatever”.
I've also used it, once, to similarly build a simple testbed app to manually test the UI with fake data. The app consisted of buttons to simulate the presenter calling the view with fake data, and handled the presenter calls back from the view with Window.alert or similar things. You'd launch the app in your browser and click here and there and validate that the view works as expected.
This can be useful when you later add a field to your form, to make sure you correctly wire it with the presenter. You don't want to setup your GWT-RPC/RequestFactory/whatever services from the real presenter, when a unit-test could be enough.
2 big reasons off the top of my head (there may be others too...)
Testing: Your Presenter then does not have to have a direct reference to the View, which is nice because the View contains GWT Objects (i.e: any Widget) which cannot be used in a standard Unit Test Case: Any GWT Object must have a JS container (i.e: Browser, or GWTTestCase) to be instantiated; A JUnit test case cannot use a Browser; GWTTestCase runs VERY slow, so you should prefer not to have to use it. Without the interface, the Presenter would have to reference the View's methods by a direct reference to the View; that means when testing the Presenter, you must instantiate the View, which must instantiate its Widgets (which at that point require the GWTTestCase for the Widgets). And all you should be aiming to do in the 1st place is to test the logic, which should be completely in the Presenter to avoid GWTTestCase... With the Display interface, you can do just that: Focus on testing the Presenter, without the complication of instantiating the View (which has its own degree of instantation complication) and messing around then necessarily with GWTTestCase
Have multiple Views for the same Presenter: [I think you would only ever do this if you have different platforms (i.e: mobile App vs. browser) which each require their own View (since a mobile App version of the View is rendered differently from a browser View, since they are different platforms with different GUI entities)]. The multiple Views would then all just implement the Display interface in their separate ways. Then the single Presenter can contain the logic that is the same for all Views, be used for all the different Views, and all View implementations are guaranteed to follow the same expectations (which are the codification in the Display interface) of that single Presenter! This is a manifestation of the OOP best practice of designing with interfaces, which #SSR Answers.
We've been using the recommended GWT approach of building parts of our application in an MVP manner. The logic we use is based on Google's examples - the Presenter fetches/prepares data and sets it on the View, and the View contains a reference to the Presenter which it calls (e.g. in UiHandlers).
Some parts of the application which we built should be reused in other views. For example - a view which is sometimes the "main view" of a part of the application - can be used inside a pop-up in another part of the application (of course, the views/presenters are initialized differently in this other case, but basically it is the same thing).
What would be the correct approach to do stuff like this? I cannot seem to find a suitable one without resorting to ugly hacky stuff.
For example - if I put the presenter of the reused component inside the main view - it is easy to initialize the reused component, but it is ugly to receive a result back in the main presenter. This can be solved by passing a runnable or creating a custom handler or passing the parent presenter itself to the reused presenter.
All of these approaches don't seem right to me though and seem ugly.
Any ideas/experiences?
What you're describing is a view being able to be controlled by 2 distinct presenters. Abstracting those presenters behind a common API, in the form of an interface, should be enough.
You can also see it as a composite widget being used within two distinct views. The composite widget would then expose events and a public API that both views could wire to their specific presenters.
See Activites and Places,It can help you to desing and structure you app.
https://developers.google.com/web-toolkit/doc/latest/DevGuideMvpActivitiesAndPlaces
.
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.
Lets say that on all my views, or generally at any time in my app, I want to be able to show an error message popup, and it always looks the same. How do I do that?
First thought is having all my view models extend a base view model which facilitates these things, but after that, do I have this base view model actually create the UI widgets and display them?
thanks,
Mark
If you've got some common functionality that you want to provide across a range of views, then you can implement a base class that inherits from the PhoneApplicationPage, and then derive all your classes from that class instead. The XAML for your pages then looks like this:
<local:BasePage xmlns ...
xmlns:local="clr-namespace:MyNamespace"
x:Class="MyNamespace.MyPage">
However, you will not be able to define common UI components in the XAML for your base page. If you wanted to have common UI components you would have create them manually in the code-behind for the base page, perhaps in a handler for the Loaded event, but I think a better solution would be to provide your common UI in a UserControl, which you then add to each of your pages.
If you want to show a Toast or Message Box, then I would recommend the ToastRequestTrigger and MessageBoxRequestTrigger from the Silverlight Toolkit as described in the patterns & practices WP7 Developer Guide.
you could probably define an event on base view model, which is fired inside view model whenever an error occurs, then in view, you can subscribe to this event and display the popup. You can carry error context in EventArgs of the fired event.
Additionally you could unify the logic for displaying the popup but that's probably another story :)
This is testable and nicely decoupled from the view.
Hope this helps,
Robert