We have a GWT application specifically designed to handle mobile clients and built with MGWT.
Now, we need to build a frontend for classical web clients, probably building it with GWT-Bootstrap and I'm wondering what's the best solution to achieve this.
How should we proceed with modules, gwt.xml configuration, client type detection, etc ...
What are your suggestions ?
Check this question for how to tell what platform the user is on.
Beyond that, GWT uses only HTML and Javascript, so unlike Flash applications, it actually works fine on mobile devices too; most events (such as clicks) are translated by the browser, so a touch becomes a click, you don't need a separate handler or anything.
Basically what I would suggest is you have a single GWT regardless of platform, and only for certain Widgets, add separate options for Mobile and Desktop, as necessary.
I don't know the architecture of your app and if you use the MVP pattern but GWTP with its Form-factors feature allows you to share almost all of your business logic (your presenters) across the different platforms. You have just to write the view depending on the platform you want to support.
Related
in standard "page-based" webapps, it´s quite easy to implemet direct links to several pages, f.e, an url abc.com/app/customer/4711 which directs the user directly to the page diplaying customer 4711.
Is there a way to reproduce a similar behaviour in an GWT-App?
Tnk Mica
You can use Activities and Places design pattern. It provides easy access to any "place" within the app:
https://developers.google.com/web-toolkit/doc/latest/DevGuideMvpActivitiesAndPlaces
Every once in a while this question is being asked in one form or another and I think misconception exists about what GWT is best suited for.
GWT is an amazing set of tools for creating web applications: JavaScript multi-screen user interfaces which run in modern web browsers, load as a single web page and generally don't need full page reloads or page switching for their operation.
Navigation between screens happens in response to triggered events (for example, a user pressing a button, a timer firing or server-side state changing). The data needed to be presented is acquired asynchronously via XHRs (again without web page reloading).
GWT provides an elaborate framework for all of the above - Activities & Places for navigation, as Andrei mentioned, GWT-RPC and RequestFactory for data acquisition and exchange, and much much more to make advanced and highly-structured web apps which leverage the processing power of modern machines and capabilities of modern browsers.
First off, I've never used GWT before. I have good experience in HTML/CSS/JS/JSP.
I'm looking for people's opinions on the suitability of Google Web Toolkit for a brand new web app I'm developing.
A big requirement is that the UI is attractive and well designed (Does not look like a clunky Java/Swing App).
It should look like any typical HTML/CSS/JS based modern website.
It is an internal company application so no SEO is required.
JSF is not an option.
The web app frameworks used will be Spring Webflow and Spring MVC. It will use lightweight controllers to communicate with a service layer.
Would Spring Tiles combined with JSP be an easier or more flexible option than GWT for what I am trying to achieve?
Advantages/Disadvantages of GWT and other options welcome.
Thanks
Advantages of GWT
You don't really need to know any JavaScript, since all your client side code will be in Java
This is usually the main reason people go for GWT. They're backend developers who know Java but don't know Javascript, and they don't really want to learn it. Still, you should be careful about this. GWT is a very complete and complex framework with many concepts that are specific to GWT. Even though you'll be coding in Java you will still have to go through many tutorials and documentation before you can build a clean GWT app
Ready to use widgets, like date pickers, dynamic tables, layout panels, popups
It's not really specific to GWT. Other front end framework, like jQuery or Dojo or whatever also give you these. You can have a look at the GWT Showcase to see what GWT has to offer.
GWT takes care of a lot of complex and potentially dangerous stuff for you.
Stuff like Cross-Browser Support, Internationalization, Image and static resources bundling, Front end security, Ajax communication with a server, Events and MVP (just like MVC) framework support. Have a look at the documentation, it is very well done and very thorough.
Debugging is easy
GWT has two different 'modes'. When you're building your app for production, gwt will compile all the java code for the front-end that you wrote into javascript. This javascript will be executed in your clients' browsers. But when you're developping, you can run your app without compiling your java code to javascript. This lets you use a debugger to debug your interface. It's a very good tool.
Disadvantages of GWT
As I said before, GWT is a full framework, with concepts specific to it. Don't think that just because it's in java and you know java that you won't have to learn new stuff.
Interfacing GWT with back end frameworks is not easy
The most common way for your GWT client code to communicate with a server is by using GWT RPC mechanism. It means that you will need to have servlets that implement specific interfaces. You should definetly read the docs on client-server communication to see if that fits well with Spring. A search on SO or Google should give you pointers to setup your application.
We're planning on creating a feedreader as a windows desktop- and iPad application. As we want to be able to show Websites AND to run (our own) JavaScript in this application, we thought about delivering the application as HTML/CSS/JavaScript, just wrapped by some .NET control or a Cocoa Touch webbrowser component. So the task at hand is to find out which framework to use to create the HTML/CSS/JS files to embed in the application.
For the development of the HTML/CSS/JavaScript we would be happy to use Vaadin, GWT, or some other framework, as we're a lot better with Java than with JS. We favor Vaadin after a short brainstorming, as the UI components are very nice, but I fear that most of the heavy lifting will be on the server and not in the client (and that wouldn't be too nice). We would also like GWT, but the Java-to-JS compiling takes a lot of time and an extra step, and slowed down development time in the past when using it.
The question is: which development framework would you choose (given you wanted to implement this project and you mostly did Java so far) and why? If there are better framework options (List of Rich Client Frameworks), please let me know.
Edit: The application will need to talk to our server from time to time (sync what has been read for example), but mainly should get the xml feeds itself. Therefore I hope that most of the generated code can be embedded in the application and there doesn't need to be heavy activity with our server.
Edit2: We (realistically even if you doubt) expect at least 10000 users.
Based on my experience with Vaadin, I'd go for that, but your requirements are somewhat favoring pure-GWT instead.
Vaadin needs the server and server connection. If building mostly offline desktop application, this can be solved with an embedded Jetty for example. (synchronize with an online service only when needed), but for iPad you would need to connect online right away to start the Vaadin application.
GWT runs completely at the client-side and you can build a JavaScript browser application that only connects when needed.
Because Vaadin is much quicker to develop, you could build a small Vaadin version first and see if that is actually problem on the iPad.
On the other hand, if you can assume going online right away, you can skip the local server installation altogether. Just run the application online and implement the desktop version using operating systems default browser control (i.e. the .NET control you suggested). Then Vaadin is easier.
Vaadin is just framework base on GWT but have two very important features:
don't need to run GWT compiler. It is pure java. Of course if not add addons because then gwt compiler must run.
you don't need to write communication code. So you don't need to solve DTO problems, non-serializable object mappings and dont need to write servlets.
I use Vaadin in my work for one year and we haven't performance problems yet (desktop like application with ~500 users). IMO very good solution is to use Vaadin just for UI, logic move to independent beans and connect this two elements using Spring or Guice.
In this case you should use MVP pattern and Domain Driven Development.
Bussines beans is domain objects and logic that use view interfaces to send responses.
Custom Vaadin components (could extends standard components) implements view interfaces.
That way is good when you decide to change UI engine if Vaadin is not for you. Just rewrite guice/spring mappings and write new implementations of view interfaces.
My 3 cents:
If you decide to use vaadin, You will benefit from already GOOD LOOKING components. Since you dont want to write (alot of) CSS , vaadin is already good looking out of the box. How ever, Vaadin is a SERVERSIDE framework. User interface interactions will hit the back end even if they dont involve getting any data (e.g moving from one tab to the other) .
If you decide to use GWT, you will have to atleast style the application (this is not hard) . There is also the problem of long compilation time (but you can test and debug on hosted mode which allows you to run the application without compiling , then you compile only when deploying). The main advantage of gwt is that you control what gets sent to the wire, For UI interactions that dont require getting data from the backend, it will work purely on the client side. You the developer will determine when to send a request to the back end. (Doing RPC requests in GWT is very easy)
Hope this will help you make the decision.
I am working on a GWT app that needs to serve a different layout to mobile device users. I can easily determine if a user is using a mobile browser; however, I'm not sure about the best pattern for handling them.
I am currently using the MVP pattern - would it be best to simply pass a browser-specific view to the Presenter or is there a more appropriate method?
You could set up GWT to detect the web browser used, as described in this question. Then, via Deferred Binding, let the compiler "slip" the correct view into place for the, say, mobilesafari user agent. That way, you won't have to litter your Java code with browser detection, etc.
The way I've done it is to have different GWT modules (with their own entrypoint, Gin modules, even different CssResources) and then on the myapp.html page you just have to check out what browser is requesting the content and based on it (javascript checks) the appropriate module
<script src="myapp/myapp.nocache.js"/>
or
<script src="mymobileapp/mymobileapp.nocache.js"/>
is loaded.
If you are working with GIN and an MVP framework (gwt-platform is my platform of choice) you can then reuse the code that was already written for the presenters and only implement different views.
I've been thinking about this recently and I don't know a really nice and tidy way of creating a mobile version of an existing or new MVC2 website/app.
I think the easiest way would be to just use a different stylesheet depending on whether a mobile was detected but sometime you need to change the view content too if you have massive inline images everywhere or for other reasons.
What is a good approach for this? Is there a way of theming fairly easily in MVC2?
Well MVC is just your server-side technology, what you should ask to yourself is "what is the best practice to create a mobile web site, regardless of the server side tech".
In my opinion, creating a well-formed and semantic (x)html is the first step. As you say, the most logical thing to do is create different style sheets for different media types, and you're right.
As for the problems you mention, like inline images, consider this: are those images content or presentation?
In the first case, they should be present even in the mobile version.
In the latter, they are defined in the style sheet, so you can simply avoid them in the mobile css.
The only exception I can think of is when you want to provide different functionality on mobile, or if you're forced to, i.e. on pages that rely heavily on JS and those scripts wouldn't run on mobile browsers. In this case, you might want to create different versions of those pages and serve the appropriate version based on the user agent.
Check the source code for NerdDrinner. They've implementated a MobileCapableWebFormViewEngine class which inherits from base WebFormViewEngine class. The MobileCapableWebFormViewEngine uses the HTTPContext to decide which View to render in the client. This'll make more sense when you see the source code