Re: Synchronized code after a service call

Hi Jens,

Thanks for extensive answers, there are several things for me to learn.

My application is a bit different, I am not loading data from db, rather I have a list of db which
I want to check db connection, and the service will return a pair <db,bool> per each database.

I want to show the user how this process is progressing and user sees which db has been already tested, that
is why I want to call service per db.

With this explanation, how do I solve my problem?

Best,
Al


On Saturday, May 2, 2015 at 1:46:32 PM UTC+2, Jens wrote:

Ok here are some points to make your code better:

1.) First something to understand: Whenever you must provide a callback you can be sure that the method requiring the callback is executed asynchronous. In fact literally all web APIs that need to wait for something are asynchronous because the browser itself only has a single thread to execute JavaScript and that thread should never block. If it would block then the browser tab would be unusable for the user. So JavaScript uses asynchronous APIs and processes work using an event dispatch thread. 

2.) You should never really do server requests in a loop unless you really know what you do. Server requests are slow and costly (think of mobile) and it is always better to fetch the whole list of data in a single request. So given your example you would do configurationService.testStrs(allStrings, callback) . Also keep in mind because of 1.) there is no guarantee of ordering. That means if your for loop does execute your testStr() method for "A", "B", "C" in order then the server might get these requests in order "B", "A", "C" and the browser get the server results in order "C", "A", "B".

3.) If you do 2.) and request all strings at once you only have a single result and thus you could move your finalizeDialogBox() into the onSuccess() method of your callback. So it would look like

initDialogBox();
// optional: show some loading indicator
configurationService.testStrings(allStrings, new AsyncCallback<ArrayList<Boolean>>() {

  public void onSuccess(ArrayList<Boolean> allResults) {
    updateDialogBox(db, allResults);
    finalizeDialogBox();
    // optional: hide loading indicator
  }

  ....
}

Also note that I have used ArrayList instead of List. The reason is that you are using GWT-RPC which generates serializer classes for everything that might be transferred between client and server. If I would use List then GWT-RPC will generate serializers for all implementations of List even though your app might only use ArrayList. That makes the app larger than it should. Luckily the List interface does not have that much implementations and overhead isn't that much but it is still something to be aware of, especially if you use lots of libraries that might have additional List implementations.

GWT-RPC generates a file of the form <hash>.gwt.rpc in your output folder which contains all classes that GWT-RPC has detected and generated serializers for. It is handy to look into that file from time to time to check if lots of unwanted things are detected. Also the GWT compile report gives you insight about the final JavaScript size of serializers.

4.) From a user perspective you should make sure to have some loading indicator while the table data loads in case the network is slow.

-- J.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.