How do I finish an Activity from within a Presenter or a View in the mortar sample app?
The majority of the time you would want to avoid doing this. But in dire circumstances you could follow the same pattern the ActionBarOwner[0] class implements. Create an injectable class that exposes Activity#finish via an interface.
Item 3 in [1] is related but the calling order is inverted. (Activity lifecycle methods to presenters instead of Presenters to Activity methods).
Hope that helps!
[0] https://github.com/square/mortar/blob/master/mortar-sample/src/main/java/com/example/mortar/android/ActionBarOwner.java
[1] Mortar + Flow with third party libraries hooked to activity lifecycle
Related
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").
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
.
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
I'm working on a new WPF application and I'm trying to stay as close to the MVVM pattern as I can. My XAML files right now have no codebehinds, and all my interactivity is achieved using Josh Smith's RelayCommand class and commands in my ViewModel classes.
This worked great until I started working on the housekeeping tasks, such as an about box and a system preferences page. I want to have these as modal dialogs, but if I create a RelayCommand to open these pages, I'll be creating a dependency on the view within my view model.
This strikes me as against the grain of the MVVM pattern.
Is there an established method for creating new windows (modal and/or modeless) within the MVVM pattern without creating a dependency? It seems the only way I can keep the ViewModel clean is to create a Click event handler in the XAML codebehind file and create the new view within the old view.
Any recommendations?
One way to handle this is to implement a service that provides Views to ViewModels. Views register with the service and ViewModels can request dialogs from the service. This is an example of the Gang of Four mediator pattern.
Take a look at my Modal Dialogs solution for Silverlight 4:
Modal dialogs with MVVM and Silverlight 4
Please see my answer to this question about why the Window class itself is a ViewModel, so you can use it directly from your ViewModel without worries.
Laurent Bugnion has a weak-referenced mediator, in which he uses it to show dialog messages. Along with the message that is broadcast, a callback delegate is sent for the subscriber to execute. You could use the same concept to show an about dialog. Check out DialogMessage.cs from the source here.
We use Controller classes which are responsible for the UI Workflow. They create the modal windows and they mediate between various ViewModels.
How you can open a modal window with the View-Model-ViewModel (MVVM) pattern is shown in the ViewModel sample application here:
WPF Application Framework (WAF)
http://waf.codeplex.com