1; Don't mess content - markup - style - behavior
GWT app is a web app, however it is compiled to JavaScript, and written in Java. Every web app runs in an sandboxed environment, usually in a Web Browser. The Web browsers has different engines concerning:
- Markup : wrapper for content, the <html> tags. They are parsed during page load, by the browser parser engine.
- Style : Describes, How the page look like. Style rules are written in CSS, and handled by the browser's engine concerning Css.
- Behavior: Describes how the web page behave, interact. It is a JavaScript, interpreted by the browser's JavaScript engine. With it, the former two (content and style) can be changed too.
We already violate this rule with GWT, as we create content with JavaScript. Don't do more violations, so separate style in css, like described here: http://code.google.com/intl/hu-HU/webtoolkit/doc/latest/DevGuideUiCss.html. Only set classnames and id-s from GWT. It is not just easier to maintain, but also better for mobile browsers (.css file are downloaded and handled during js parsing).
2; Write as much as possible in Java
It is tempting to use JSNI methods to write things in plain JavaScript. Don't do that, as plain JavaScript won't be compiled and obfuscated. If it takes a two day more to write it in Java, please do that. It can win many bandwidth after compilation.
3; Avoid Try - Catch
It is used a lot in Java, but very rarely in JavaScript. While it get a different execution context (like the with, or eval statements) it gets very slow in the catch clause. Also, as Java development mode in Eclipse handled by the App Engine, that is basically Java, you will get different result and strange errors in production (like sliders don't working). After it is very painful to "catch ( :-) )" where it is exactly, and why doesn't working.
4; Everything is Asynchronous
Say it out loud: EVERYTHING IS ASYNCHRONOUS. When the code requests a resource (image, file, etc...) it don't available at the given moment, but must be fetched. As resources on Web mostly far away from you (and even from me :-)) it may take time, or can happen very quick. So the browser don't want users to wait, but has attached load handlers on the given resource (for example image) that can notify the code, when the image is loaded. During resource loading, the browser don't freezes, and can do other things. It is good. What is bad:
public BufferedImage(ImageElement imageElement) {
Canvas cv = Canvas.createIfSupported();
cv.setCoordinateSpaceWidth(imageElement.getWidth()); //WE can't be sure that we have width here!
cv.setCoordinateSpaceHeight(imageElement.getHeight());//We can't be sure that we have height here!
Context2d c2d = cv.getContext2d();
c2d.drawImage(imageElement, 0, 0);
img = (CanvasElement)cv.getCanvasElement().cloneNode(true);
}
The solution is to attach a load handler to the a given imageElement, and if it "fires" that means, we have a loaded image.
Async loading and callbacks (functions that "called back" when resource arrives) are so widespread in web environment, that used everywhere where computing, fetching etc takes time (Web Workers, File readers, etc).
Just be sure, that if you request something, and looks like it is not there, but should, it is because of that.
5; Logging. Don't do
$wnd.console.log(YOUR_LOG_MESSAGE)
or
System.err.println(YOUR_LOG_MESSAGE);
Please use GeoGebra's logging system:
@geogebra.web.main.Application::debug(Ljava/lang/String;)(YOUR_LOG_MESSAGE);
or
AbstractApplication.debug(YOUR_LOG_MESSAGE);
Here you can read some more details on Debugging.
