I'm developing an application using GWT 2.6.
Now I have a task to implement a functionality to switch between simple/expert modes (of view) at run-time. It means to show a simplified version of view which may contain another widgets.
But the problem is that all the views in most cases are "static" and defined as singletons (using GIN).
Is it possible to implement this using only GWT and what should I use to make it?.
There are many ways that this can be done. A couple of ideas that spring to mind:
Option 1.
Instead of using GIN to inject the view, inject a view provider (com.google.inject.Provider). This can be used by the code that builds the view (the activity?) to get the view. The implementation of the view provider can then return an implementation of the view for the relevant mode, simple or expert. For example,
#Inject
public ComposeMessageActivity(Provider<ComposeMessageView> viewProvider, ...) { ... }
#Override
public final void start(final AcceptsOneWidget panel, final EventBus eventBus) {
view = viewProvider.get();
Option 2.
Use deferred binding. This is not so dynamic but has the advantage a simple implementation will be a smaller download than an expert implementation. There is a project, gwt-seminar, on github that shows this in practice that has mobile and desktop versions.
Related
Can someone explain What benefits an MVVM framework such as ReactiveUI or MVVM Light provides to Xamarin.Forms application? we can implement INotifyPropertyChanged in our viewmodels without using any of these frameworks.
Am I missing something?
I'm an author of a small MVVM framework for Xamarin.Forms (https://github.com/daniel-luberda/DLToolkit.PageFactory). I'll try to point some advantages of using it as some of features are common for other frameworks too:
Ready to use INotifyPropertyChanged implementation (just inherit from BaseViewModel or BaseModel)
ViewModel oriented Navigation (you can move your navigation logic to view models)
Built-in messaging to easily pass data/arguments between pages or view models
Page caching and reusing (better UI experience as views/pages are reused)
Every page has access to typed ViewModel instance which is automatically instantiated and wired to BindingContext
Those features vary between libraries. Some of more advanced MVVM frameworks offer you a possibility to move your entire project to a different platforms/sdks as they have multi platform support. It may be a nice deal for a larger projects.
Sample code to illustrate some features (the code is called from a ViewModel):
PageFactory.GetPageFromCache<SecondPageModel>()
.ResetPageModel()
.SendActionToPageModel((model) => { model.Message = "Hello World!"; })
.PushPage();
There is more to an MVVM Framework than just INotifyPropertyChanged. To give just a couple of examples there are:
RelayCommand - A class that can provides an implementation of the ICommand interface and allows you to bind a delegate to the view. Useful for buttons
EventToCommand - This allows you to bind an event to a command in your view model. Instead of having to use code behind for UIElement Events
These are just two classes that are provided by an MVVM Framework such as MVVMLight
By using MVVMLight it means that you do not have to implement INotifyPropertyChanged in every project you just make sure your ViewModel inherits from ViewModelBase and you also don't have to write your own implementation in every project for the two classes mentioned above.
The final thing to mention is that you can also install code snippets for MVVMLight. Meaning that writing code is EVEN faster!
For example if you would like a property that raises property changed as well just use the mvvmlight property snippet. And similarly if you would like a RelayCommand property you can just use the mvvmlight RelayCommand snippet
The Model-View-ViewModel (MVVM) architectural pattern was invented with XAML in mind. The pattern enforces a separation of the XAML user interface (the View) from the underlying data (the Model) through a class that serves as an intermediary between the View and the Model (the ViewModel). The View and the ViewModel are often connected through data bindings defined in the XAML file. The BindingContext for the View is usually an instance of the ViewModel. Please click here to see more details and sample code.
You don't need to use ReactiveUI or MVVM Light, you can just use INotifyPropertyChanged interface to notify clients that a property value has changed.Below, you can see my ViewModelBase class code, hope this helps you out;
public class ViewModelBase : INotifyPropertyChanged
{
#region INotifyPropertyChanged
public event PropertyChangedEventHandler PropertyChanged;
public void OnPropertyChanged([CallerMemberName] string propertyName = null)
{
if (PropertyChanged != null)
{
PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
}
}
#endregion
}
In my ViewModel here is how I inherit from ViewModelBase and how I create my property;
public class ImageButtonViewModel : ViewModelBase
{
// ...
private string header;
public string Header
{
get
{
return header;
}
set
{
header = value;
OnPropertyChanged();
}
}
// ...
}
I have been using with great success with Askaiser.Mobile.Pillar, and I do not see anything wrong, I am still investigating, but this has become a great candidate for my projects.
Doc
I hope I have helped.
A greeting
The plain truth is that MVVM Frameworks (and their IOC Containers) are short-cuts to save you time. They come at an extraordinary expense:
They cause a simplistic alignment between views, view models and models. Only one can really belong to another. This is not "IOC" -- it's a hard-coded assignment based on a file naming convention such as this:
MainPage
MainViewModel
MainModel
In a real injection scenario, any number of models could serve any number of view models, provided they implement the proper interface. Also, any number of view models can serve any number of views as long as those view models support the views' interface(s).
MVVM Frameworks create classes through a reflection trick using a string prefix. In the example earlier, the string "Main" allows us to find the page, the view model and the model. But this is not view-model-to-view-model navigation. It is string to view model navigation.
The frameworks create classes using Activator.CreateInstance, which creates havoc on the compile-time linker.
The frameworks instantiate using hyper-simplistic constructor parameter logic. Modern programs use instantiation as a form of control. In these frameworks, there is no real control.
The complete code for these remarks is at https://github.com/marcusts/xamarin-forms-annoyances. See the solution called MvvmAntipattern.sln.
The GitHub site also provides links to a more detailed discussion on this topic.
I'm developing an application consisting of 3 modules.
The users can start a web chat (implemented as a widget) and then navigate through the modules. I would like the web chat widget to be kept during the navigation.
I've added a static field in the widget containing the current instance, but it is only persisted while I remain in the same module. If I change module the widget is re-created by scratch.
Is there a way to define an object with application scope?
A better solution (than keeping global state) would be to use Dependency Injection and inject your widget to all relevant views.
Using gin it'd look like this:
#Singleton
public class CommonWidget {
}
public class View1 {
#Inject
public View1(CommonWidget widget) {
}
}
public class View2 {
#Inject
public View2(CommonWidget widget) {
}
}
Now, widget in View1 and View2 point to the same widget.
The problem is that you have to be careful when using this widget - remember that you can only add a widget once to the DOM, so before adding it in View2, you have to remove it from View1.
I think that instead sharing the widget this way, you should either share the messages between two chat widgets or better yet, move the chat widget "above" the views (either literally or figuratively), so that there's only one instance.
Of course, there are more steps to setting up gin, but you can read about them in the docs.
You can create any widget in your entry point class (#onModuleLoad), and then reference/call this widget from any activity that needs it. However, I would only recommend this solution in two cases:
A widget is a container for the entire application or part of the application (e.g. top menu, main panel) that is always visible on a screen, so you don't add/remove it from UI - you simply call it to change its state.
A widget is a popup panel or similar (e.g. confirm dialog, error notification, etc.), so reusing it in different activities/views does not cause any problems.
You may want to take a look at Activities and Places design pattern. It supports most typical navigation scenarios, where you move from one Activity/View to another within the same app (container) widget.
UPDATE:
This is a quote from GWT docs about the use of multiple modules:
If you have multiple GWT modules in your application, there are two
ways to approach loading them.
Compile each module separately and include each module with a separate
tag in your HTML host page.
Create a top level module XML
definition that includes all the modules you want to include. Compile
the top level module to create a single set of JavaScript output.
The
first approach may seem the easiest and most obvious. However, the
second approach will lead to much better end-user performance. The
problem with loading multiple modules is that each module has to be
downloaded separately by the end-user's browser. In addition, each
module will contain redundant copies of GWT library code and could
possibly conflict with each other during event handling. The second
approach is strongly recommended.
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.
I want to create a GWT UI where I basically will have a single HTML page that loads a PanelA object. The user will then do their thing and eventually perform an action that will move them onto another view/screen.
I have simplified my existing views to contain just a single button which moves the user onto the next page etc. for simplicity I only have 2 views to start.
Here is my start up entry point.
public class StockWatcher implements EntryPoint
{
public void onModuleLoad()
{
final RootPanel rootPanel = RootPanel.get();
rootPanel.add( PanelA.getInstance() );
}
}
Here is the PanelA class
public class PanelA extends HTMLPanel
{
private static PanelA panel;
private PanelA()
{
super("Panel A");
final RootPanel rootPanel = RootPanel.get();
Button btnNewButton = new Button("Go to panel B");
btnNewButton.addClickHandler(new ClickHandler() {
public void onClick(ClickEvent event)
{
rootPanel.clear();
rootPanel.add( PanelB.getInstance() );
}
});
add(btnNewButton);
}
public static PanelA getInstance()
{
if (panel == null)
{
panel = new PanelA();
}
return panel;
}
}
My other PanelB class is pretty much the same as PanelA , ie button that brings me back to PanelA
My UI works as desired.
My Question is, Is this singleton type pattern a correct or proper way to do this? ie Have a stack of Singleton UI views that get popped on/off the main panel?
Also, what is the best way to handle hitory/breadcrumb trace through a GWT app, ie allowing a user to go back to the previous screen bearing in mind that they may navigate to PanelX from either of PanelA, PanelB or PanelC
I use "Activities and Places" to manage all of this, and it's been working quite well in production for a year or so.
https://developers.google.com/web-toolkit/doc/latest/DevGuideMvpActivitiesAndPlaces
I think it's fine to use a Singleton mechanism for your views, but you have to make sure to completely reset any state you store. For me, it was easier to just create new views every time the user navigates to a new spot, and then if I detected a problem with load times or something to retroactively cause the view to re-use its components. I'd advise you to get the navigation working first, and then worry about the singleton (or not) optimizations.
I recommend Activities and Places design pattern.
It covers all the issues you raise in your question, plus many more that you have not thought of (or did not ask about) yet, like native browser history management and ability to bookmark different places within the app, handling of page reloads, efficient memory management vs optimized DOM operations, scalability (building an app with dozens/hundreds of views with minimal code duplication), testability, and code-splitting (where to split large apps).
I suggest you refer "GWTP" framework to make a GWT Project, some of the features currently supported by GWTP:
Dependency injection through GIN and Guice;
Simple but powerful history management mechanism;
Support for nested presenters;
Lazy instantiation for presenter and view;
Effortless and efficient code splitting;
Integrated command pattern supporting undo/redo;
So your questions and query like Singleton UI views, best way to handle hitory/breadcrumb trace and singleton type pattern , will cover and one good framework will make easy project management.
I'm trying to adapt my GWT web application from my home-grown MVC to GWT Platform.
I've managed to port the my application views with presenters, and essentially able to access views via PlaceRequest. And with changing the URL (#).
However I am not sure how to deal with Models using this GWT platform, in the common MVP I know there is a go() method in the presenter which fetches data, say from server via RPC.
In the GWT platform presenter here are the methods automatically generated by the Eclipse plugin:
Constructor
revealInParent
onBind
onReset
Where should I put the RPC code that will fetch and update my model. Say in the presenter I have:
ProfilePresenter.java:
public class ProfilePresenter
extends
Presenter<ProfilePresenter.MyView, ProfilePresenter.MyProxy> {
public interface MyView extends View {
HasText getFullname();
HasText getLocation();
HasText getAboutme();
HasText getLastlogin();
}
private User user; // Model which represents the User information etc.
And when the View associated with the Presenter is shown I need to fetch the User model from the server and update the model and then subsequently update the view through the interfaces it expose.
Also, say I have some buttons in the view, which then can be accessed by the presenter through HasClickHandler where should I put the event handlers?
I would put the RPC call in the onReset method.
See the presenter lifecycle
Personally I deal with events using the reversed MVP pattern. But you can also call a handler this way:
getView().getSubmitButton().addClickHandler(new ClickHandler() {
#Override
public void onClick(ClickEvent event) {
}
});
with the following signature for getSubmitButton in your view interface:
HasClickHandlers getSubmitButton()
Sydney covered most of your questions.
In general onResetmethod is a good place to make backend calls.
Sometimes when the backend call takes longer and you want to display the view only after the data was loaded you can use manual reveal.
But for the profile page I don't think that is necessary.
I also agree with the reverse MVP pattern. It's way easer to test presenters using the reverse MVP Pattern than using the HasXXXHandlers interfaces.