Chris’ Musings

For our internally developed application framework for GWT apps, we want to use RunAsync heavily. We have pushed as much common code to the framework as possible (that’s what frameworks are there for). So developing new screens is really a breeze. Anyway, we wanted to push the RunAsync into the framework so that developers don’t have to think or even now about it.

However, this doesn’t seem possible with the current implementation. Basically, the split point is where the physicaly code split occurs. Which is logical. We were hoping that a class hierarchy would be taken into account. For example:

public abstract class AbstractClass {
 
  public abstract void doActualWork(Callback cb);
 
  public void doAsyncCall(final Callback cb){
      GWT.runAsync(new RunAsyncCallback(){
         public void onFailure(Throwable err){
            Window.alert("code download failure");
         }
 
         public void onSuccess(){
            doActualWork(cb);
         }
      });
  }
 
}
 
public class FirstClass extends AbstractClass{
   public void doActualWork(Callback cb){
     //does actually work and calls Callback
   }
 
}
 
public class SecondClass extends AbstractClass{
   public void doActualWork(Callback cb){
     //does some other actually work and calls Callback
   }
 
}

When I have the concrete implementation of doAsyncCall(Callback cb) in
AbstractClass, I get 1 split point. When I move the implementation to
each of the sub classes (making the method abstract in AbstractClass),
I get two split points.

Don’t get me wrong, we love the new feature. Here’s hoping for a future enhancement So for now, I guess every developer will need to know about split points. Not a big deal, just one more thing to remember.