I am trying to use CellTree, i am confused about placement of class implementing TreeViewModel, This class will need Collection of elements required to be rendered as tree if this is view type class i need to push collection from the presenter. If its a Presenter class i can directly call the server function and get the collection.
I am finding it more near to Presenter.... please sugget
According to GWT docs,
A key concept of MVP development is
that a view is defined by an
interface. This allows multiple view
implementations based on client
characteristics (such as mobile vs.
desktop)
So, looks like Presenter should know neither about data presentation widgets used in view implementation, nor about specific ViewModels and data providers used by these data presentation widgets (since data presentation widgets may be changed). ViewModels are generally coupled with particular way to implement data presentation, so I usually consider them as a part of View.
I usually create presenter methods like getObjectsList(params), which return array / list of required data, and then transform these results to ViewModel.
BTW, it would be great to hear other opinions :)
Related
I am looking for a solution/mvvm framework that supports nesting ViewModels and Views. What I mean is:
Each ViewModel derives from BaseViewModel
ViewModels have properties that are of type BaseViewModel which are sub-ViewModels (nested inside parent ViewModel)
Each ViewModel have corresponding View
Views have ContentControl (control that can display templated view) corresponding to sub-ViewModels of corresponding ViewModel
Now, when creating instance of ViewModel it is needed to pass appropriate instances of concrete sub-ViewModels. Views should be automatically resolved and nested (somehow) base on ViewModels structure.
I do not define somehow because there may be a lot of ways to do it.
I hope my idea is clear. This approach allows easy and dynamic creation of ViewModels and Views. Just create tree of ViewModels, for example in XML, and base on this create new functionality.
The questions are:
Is there any mvvm framework (mvvmcross, catel) supporting such approach for Xamarin.Forms?
How would you store tree of ViewModels - in XML, database tables, ...?
How would you create instances of ViewModels - deserialization, dependency injection, ...?
How to create Views and resolve (if framework does not support it)?
After some time I can share some experience about the questions I asked:
I do not know whether there is any mvvm framework supporting such approach. Probably Catel v5 is going to support this, but I did not checked this. I use custom solution.
In my solution I store ViewModels definitions in single database table in parent/child structure.
ViewModel instances are created by custom factories using definitions from database table.
Views are created using ValueConverters. It is possible, because each view has bindings created base on ViewModels structure.
Beside above answers I can suggest to use Prism. Although it has some disadvantages for me it is the best framework in such approach.
Yes! There's an MVVM Framework that fits exactly to what you are looking for and is created with Xamarin.Forms in mind:
FreshMvvM: https://github.com/rid00z/FreshMvvm
Quickstart Guide: http://www.michaelridland.com/xamarin/freshmvvm-quick-start-guide/
How does it compare to other options?
It's super light and super simple
It's specifically designed for Xamarin.Forms
Designed to be easy to learn and develop (great when you are not ready for RxUI)
Uses a Convention over Configuration
Features
PageModel to PageModel Navigation
Automatic wiring of BindingContext
Automatic wiring of Page events (eg. appearing)
Basic methods (with values) on PageModel (init, reverseinit)
Built in IOC Container
PageModel Constructor Injection
Basic methods available in Model, like Alert
Built in Navigation types for SimpleNavigation, Tabbed and MasterDetail
You can nest or derive ViewModels as much as you'd like (In our case we have a BaseViewModel). We have been using FreshMvvM for our startup and has been battle tested to work and fit to whatever we need.
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
.
We are using the GWT-Presenter framework and attempting to use CellTable to put together an updateable grid. It seems as though several of the GWT constructs for CellTable don't lend themselves to easily breaking up the logic into clean view and presenter code.
Examples: 1) Within the View's constructor, the CellTable is defined and each column is created by anonymous inner classes that extend the Column class to provide the onValue() method. 2) The FieldUpdater interface must be implemented to provide logic to execute when a user alters data in a cell. This seems like it would best fit in the Presenter's onBind() method, but FieldUpdaters often need access to the Cell or Column which belong in the view. CellTable does not have accessor methods to get hold of the Columns or Cells, so it seems the only way for the Presenter to get them is for me to create a multitude of member variables on the View and accessors on my Display interface.
Can anyone provide good examples for dealing with CellTable in GWT-Presenter or a comparable MVP
I think the main point of GWT MVP is that Presenters (Activities in 2.1) do not depend on View implementation, so that you can easily swap in mock Views for easy testing.
Further, it's OK to have Views that depend on Presenters (= call presenter methods), but not vice versa (well yes, but via interface).
Usually I just keep Presenter reference inside View, so that FieldUpdater anon inner classes can call methods in Presenter. You could put this methods in an interface, but it would make no sense since there is only one version of given type of Presenter.
Or, if you want to have things more decoupled, then just have View send a GWT Event which Presenter listens to.
Are you trying to avoid binding of Model class with View? i tried doing that for cellTable but it was becoming confusing to maintain code so i decided to let Model class couple with View. you can avoid this coupling by some generic arguments while creating view..
-Saket
The Data Presentation Widgets in GWT 2.1 seem to have it all sewn up: model, view and presenter. So how does all of this data presentation goodness fit in with MVP? For example; how might I associate presenter (aka Activity) instances with the nodes of a CellTree? And is that even something that I should be trying to do?
EDIT (elaboration):
Where does the TreeViewModel belong? Is it rightly part of the View, or part of the Presenter? And how does one obtain a reference to the ListDataModel for a sub-branch of the tree?
It's OK to give your view a reference to your presenter, and vice versa. If your CellTree needs access to your presenter, define a function like setPresenter in the CellTree.
Another solution would be to create EventHandlers that attach to your view, and then have your presenter listen for those events and respond by calling into the interface of your view. Less coupled, more verbose. I like to create generic interfaces for both my Presenter and my View to keep them totally separate but still avoid having to deal with EventHandlers.