Create custom callbacks to achieve synchronous code execution

[Alexander Orlov]

It seems that Dev Mode code runs synchronously... Otherwise I can't explain a bug that occurs only in production mode where the results are already there before a table has been cleaned to receive those new results and still has its outdated results. So both are mixed, although I call "cleanView()" before "getResults()". But this doesn't matter because JS runs asynchronously. So getResults() is executed before cleanView(). What I need is synchronous code execution, I need a callback.

How can achieve that getResults() will be only executed once clearView() has done its job? Basically I need to call getResults() in a clearView() callback.

[Alexander Orlov]

Use code like:

    RunAsyncCallback getResourceItems = new RunAsyncCallback() {

        @Override

        public void onFailure(Throwable reason) {

            GWT.log(reason.getMessage());

        }

        @Override

        public void onSuccess() {

            System.out.println("THIRD");

            System.out.println("==============");

            getSlotsOfDate();

            getSessionsOfUserAndDate();

        }

    };

    RunAsyncCallback clearView = new RunAsyncCallback() {

        @Override

        public void onFailure(Throwable reason) {

            GWT.log(reason.getMessage());

        }

        @Override

        public void onSuccess() {

            Common.clearView(mainPanel);

            System.out.println("SECOND");

            GWT.runAsync(getResourceItems);

        }

    };

    private void refreshView() {

        System.out.println("FIRST");

        GWT.runAsync(clearView);

        System.out.println("LAST");

    }

[Ashton Thomas]

Hey Alexander, I am not sure you are going about this the correct way. Dev Mode is NOT synchronous and it functions just like production mode. There is another reason why you are getting your results. It may be because the requests take longer in Dev Mode and your client has time to send the request, then clear, the load. 

The Solution you posted is creating a split point which will download the code the first time possible solving the timing problem but does it work if you keep loading? (not refreshing but keep loading the activity without a refresh?)

You should try clearing the table and then creating a request to the server. 

I may not understand you question so please let me know if I am misunderstanding you somewhere

[Alexander Orlov]

On Tue, Oct 4, 2011 at 5:59 PM, Ashton Thomas <ash...@acrinta.com> wrote:

Hey Alexander, I am not sure you are going about this the correct way. Dev Mode is NOT synchronous and it functions just like production mode. There is another reason why you are getting your results. It may be because the requests take longer in Dev Mode and your client has time to send the request, then clear, the load. 

Yep, that could be a reason too.

 

The Solution you posted is creating a split point which will download the code the first time possible solving the timing problem but does it work if you keep loading? (not refreshing but keep loading the activity without a refresh?)

That's the point. It works "most of the time" but sometimes it stalls and hangs. 

You should try clearing the table and then creating a request to the server. 

That's what clearView() does. Afterwards getResourceItems is called.

I may not understand you question so please let me know if I am misunderstanding you somewhere

I want to clearView()  and only when this method finishes, I want to call getResourceItems(). Is the approach I've mentioned the right one? Basically I want to execute A and after A has done its job I want to do B and all of these synchronously.

[Jens]

You shouldn't use this solution. GWT.runAsync is used to create a code split point and not to execute things asynchronously. As far as I know these code split points act synchronously in dev mode but asynchronous in production/compiled mode. I think this is because in dev mode there are no .js files (each code split point will result in a separate .js file when you compile your app) that can be downloaded asynchronously using GWT.runAsync. So in dev mode GWT.runAsync gets somehow (synchronously) emulated.

Do you really want to code split these single methods?

[Alexander Orlov]

On Tue, Oct 4, 2011 at 6:37 PM, Jens <jens.ne...@gmail.com> wrote:

You shouldn't use this solution. GWT.runAsync is used to create a code split point and not to execute things asynchronously.

I don't want to execute things asynchronously. I want to execute things synchronously.

 

As far as I know these code split points act synchronously in dev mode but asynchronous in production/compiled mode. I think this is because in dev mode there are no .js files (each code split point will result in a separate .js file when you compile your app) that can be downloaded asynchronously using GWT.runAsync. So in dev mode GWT.runAsync gets somehow (synchronously) emulated.

Do you really want to code split these single methods?

That's not I primary want to do but how can I achieve what I want to do? 

I want to be sure that first() is executed before second() and that second() is executed exactly when first() has finished its job.

[Ashton Thomas]

My understanding is that the simple solution below would work. Is this correct?

service.getStuff(new AsyncCallback<ThisThat>(){

  public void onSuccess(result){

    updateStuff(result);

  }

}

public void updateStuff(ThisThat obj){

  //execute A

  //execute B

}

[Jens]

Yeah ok maybe I missunderstood your solution example. But your general idea is correct:

1.) do the first async request

2.) in the callbacks onSuccess method of the first request execute the second async request.

So basically you are chaining async requests. Thats the way to go, or try to fix your code in a way that its not dependent on the order of async request results.

[Alexander Orlov]

I don't use GWT-RPC but RequestFactory. My case is the following:

     void getStuff() {

        final SessionRequest proxyReq = Common.mainRequestFactory.sessionRequest();

        final Request<List<SessionProxy>> req = proxyReq.getSessionsOfUserAndDate(userId, Common.getNow());

        req.fire(new Receiver<List<SessionProxy>>() {

            @Override

            public void onSuccess(List<SessionProxy> response) {

               doCompletelyOtherStuff();

            }

        });

    }

    void doStuff(AbsolutePanel mainPanel) {

    }

void executeAllTheseStuff() {

   doStuff(); // this should be necessarily executed first, and only if this method has been executed...

   getStuff(); // ...I want getStuff() being executed

}

...it's that "simple".

[Alexander Orlov]

On Tue, Oct 4, 2011 at 7:53 PM, Jens <jens.ne...@gmail.com> wrote:

Yeah ok maybe I missunderstood your solution example. But your general idea is correct:

1.) do the first async request

2.) in the callbacks onSuccess method of the first request execute the second async request.

So basically you are chaining async requests.

Yep, by chaining async reqs I want to enforce a strict order of execution.

 

Thats the way to go, or try to fix your code in a way that its not dependent on the order of async request results.

I think that's the way to go ...kind of. Somehow I should make every non-RPC/RequestFactory method capable of being executed inside a callback and not vice versa (as I'm [trying] to do it now). In fact my code sample works but on each 10th request or so, I get a client-side "UmbreallaException", could be anything ... :(

[Jens]

What I sometimes do is to provide a callback parameter for methods that do async requests if I want to be notified once the async request finishes.

So basically:

void executeAllTheseStuff() {

   doAsyncStuff(new Callback() {

      @Override

      public void onSuccess() {

         doStuffWhenAsyncIsDone();

      }

   });

}

void doAsyncStuff(final Callback cb) {

   // ...

   request.fire(new Receiver() {

      public void onSuccess() {

        doOtherThings();

        if(cb != null) {

          cb.onSuccess();

        }

      }

   }

}

[Alexander Orlov]

Thx a lot! Pretty much what I've looked for!