Introduction
This section of the website describes how to use Google Web
Toolkit with C#. So we will have Google Web Toolkit on the client side and C#
(ASP.NET) on the server side. Communication is carried out using an efficient
text encoding mechanism (this is more compact than JSON).
Basic Usage of Eclipse
If you are used to the Microsoft Visual Studio way of doing
things, then there are a couple of confusing pieces of information when using
Eclipse (particularly with respect to the Google Web Toolkits Add-On) which may
be helpful to know.
Running the web page
To debug Eclipse you hit this button
And then run the ‘Web Application’
You will then, after the compile has finished, be presented
with a clickable link which will start your default system browser.
Killing a session
Whether running in debug mode or release binary mode, once
you have finished running your application (and closed the web browser) you
must STILL kill the Ellipse debug processes by hitting the two buttons below
until they both become disabled.
If either of these buttons are enabled it means you have
previous debug binaries running in memory and these may be picked up instead of
your latest’s ones. It is a really annoying thing to have to do but you
just have to remember to do it!
Running a debug session with breakpoints (plus a ‘gotcha’)
You can set break points anywhere in the code (client side
or server side) and they will be picked up and you will be able to step through
the code. However, you sometimes have to refresh the page once or twice before
they will be picked up. I do not know why this is but you just have to do
it this way.
To start a debug session you must use this option but apart
from that, everything works the same
Building the final release binaries
To create the final release binaries you need to hit this
button
This will cause several versions of your project to be
created (each one optimised for a different browser)
To access these JavaScript files in Visual Studio, the
easiest way to copy them over is to use a simple batch file e.g.
|
REM Release environment copy
rmdir /S /Q
D:\Work\NavWin\MVP\NavWin.MVP.TestJavascript\NavWin.MVP.TestJavascript.Web\navwinclient\
xcopy /Y /S
D:\Work\GoogleWebToolkit\NavWinClient\war\*.PNG
D:\Work\NavWin\WebSite\NavWin.WebSite\NavWin.WebSite\
xcopy /Y /S
D:\Work\GoogleWebToolkit\NavWinClient\war\navwinclient\*.*
D:\Work\NavWin\WebSite\NavWin.WebSite\NavWin.WebSite\navwinclient\
xcopy /Y /S
D:\Work\GoogleWebToolkit\NavWinClient\war\navwinclient.css
D:\Work\NavWin\WebSite\NavWin.WebSite\NavWin.WebSite\navwinclient\
|
Creating a Compile Report
A compile report is important in order to start code
splitting your application. This means you only load the JavaScript when it is
needed. It is still only loaded once, but not all at the same time. It can be
pretty slow for someone visiting your site for the first time (or after you
upgrade the JavaScript application). After pressing the .Compile’ button, go to
the Advanced options and set the compileReport flag
The compile report is written to the ‘Extras’ output folder
and the compiler will write the location at the end of the process. Load the
file in
|
toplevelprojectfolder\extras\navwinclient\soycReport\compile-report\index.html
|
Create Split Points to reduce the start-up JavaScript size
The start-up size of your JavaScript project determines the
loading time of your web page for new users, or when your upgrade your
JavaScript project and an existing user opens your web page. My JavaScript is
primarily used to manage the Google Web Toolkit Widgets. I have wrapped a lot
of widgets but I only want a few of these to be available when the project
starts. For all other controls I load them on demand only, using
split points like the one below. Using split points I have reduced my start-up
JavaScript size by half (187 KB reduced to 90KB). In addition, because most of
the new controls I add are not needed at start-up, this means the overall
loading size of the project remains fairly constant.
|
else if
(controlType.equals(NavWinWidgetCanvas.CONTROL_TYPE))
{
GWT.runAsync(new
RunAsyncCallback() {
public void
onFailure(Throwable caught) {
NavWinClient.Client.DisplayError("Code
download failed - Canvas");
}
public void onSuccess() {
_asynchControl = new
NavWinWidgetCanvas();
}
});
}
|
Although I cannot say exactly what the restrictions are
active for split points, the way I use them, which seems to work fine, is to
obey the following restrictions (there may be others).
1) You
can declare the underlying type without forcing the class to be loaded
2) You
can access static constants without forcing the class to be loaded
You must definitely not create the class instance
outside the split point and probably not access any instance members. For
example, suppose you are using the Popup class. You can use the following code
structure will not cause the underlying PopupPanel or NavWinPopupPanel to load
for example.
|
public class NavWinPopupPanel extends PopupPanel
{
// Declaring and accessing a static variable is fine
public static String CONTROL_TYPE = "NavWinPopupPanel";
...
}
public class SomeClass
{
// Declaring the type is fine
private NavWinGridPopupPanel _popup = null;
public void someButtonClickHandler(ClickHandler e)
{
final ClickEvent final_e = e;
GWT.runAsync(new
RunAsyncCallback() {
public void onSuccess() {
_popupPanel = new NavWinPopupPanel();
_popup.setPopupPosition(
final_e.getClientX() + 20,
final_e.getClientY());
}
});
}
}
|