RPC that returns void, how to type the callback?

[Patrick Ratelband]

Hey everyone,

I am working on a bit of RPC and I have a simple method that does not
return any data, now with normal data returning methods I can type the
raw callback to callback<String> for instance. However, when I do not
return data, I have no idea how to type the callback. Adding a boolean
succesfull is not nessescary as the method succeeds or throws an
exception.

So in short, how to type the raw callback (GWT 1.5 ofcourse) when the
return type of the RPC call is void?

Thanks for your help, Patrick

[DanielK]

My workaround to this was to use the class "Void" as the type
parameter of asynccallback / the return value of the method.

I dont know if this is a good thing, though. Only Joshua Bloch or Bob
Lee could answer that.

[Isaac Truett]

AsyncCallback<Void>

[alberthendriks]

You guys must have access to the solution of my problem. I want to get
data from the server. How? It must be something simple but I can't
figure it out. I have some class "Model" which implements
IsSerializable and I want to fetch it from the server. I can send it
to the server but not back :(.

public interface HandleModelAsync {
public void loadFromDB(AsyncCallback<Model> callback); // this is
correct?
}
public class HandleModelImpl extends RemoteServiceServlet implements
HandleModel {
public void loadFromDB() {
Model model = new Model();
??? how do I specify that "model" must be the "m" in
"onSuccess(Model m)" ?
}
}

[elliot]

...do you mean this?

public interface HandleModelAsync {
public void loadFromDB(AsyncCallback<Model> callback);
}

public interface HandleModel {
public Model loadFromDB();

}
public class HandleModelImpl
extends RemoteServiceServlet
implements HandleModel {

public Model loadFromDB() {
return new Model();
}
}

[alberthendriks]

Ah yes, thanks :D.

Albert

[elliot]

Felt like removing 'Void result's. Doesn't add much, but feels less
cluttered.

Anyone have an opinion on the way I did this? Like? Disapprove? Waste
of time?
Let me know.


public abstract class VoidAsyncCallback
implements com.google.gwt.user.client.rpc.AsyncCallback<Void> {

@Deprecated
public final void onSuccess(Void voidObject) {
onSuccess();
}

/**
* Called when an asynchronous call completes successfully.
* Has no returned parameter. Servlet method should
* return void, and client asynchronous method should have
* as its final argument AsyncCallback&lt;Void&gt;,
* NOT VoidAsyncCallback.
* <pre>
* ex:
* public interface MyService extends RemoteService{
* public doSomething(String thing);
* }
* public interface ServiceAsync{
* public doSomething(String thing, AsyncCallback<Void> callback);
* }
* public class MyServiceImpl extends RemoteServiceServlet
implements MyService{
* public void doSomething(String thing){
* log("did a thing: " + thing);
* }
* }
*
* public class ClientClass{
* public void test(){
* MyServiceAsync s = GWT.create(MyService.class);
* s.doSomething("dance", new VoidAsyncCallback(){
* public void onSuccess(){
* Window.alert("did something");
* }
* public void onFailure(Throwable caught){
* Window.alert("did something wrong: " +
caught.getMessage());
* }
* });
* }
* }
* </pre>
*/
public abstract void onSuccess();

}

[Patrick Ratelband]

Thank you Daniel,

I never thought of using void with a capital V (silly me... slaps
himself), even though it might not be very... well... clean code, at
least it makes Eclipse happy for the moment.

Patrick

[Matt Bishop]

I think your method should return Boolean at the very least. Every
server call has the potential to fail it's task and throwing an
exception may not be the best action. You should return something for
every call so the client knows it went OK.

OnFailure is for transport errors not business rule errors.

[walden]

On Aug 3, 12:41 pm, Matt Bishop <mbis...@gmail.com> wrote:
> I think your method should return Boolean at the very least. Every
> server call has the potential to fail it's task and throwing an
> exception may not be the best action.

Can you please be specific about when you think throwing an exception
is the wrong action in response to failure? You may be right, but I
don't think so. Adding a Boolean indicator of success seems to me to
add a second channel for communicating success/failure, and clouds the
design. My rule would be (and I don't think I'm the inventor, btw)
"service methods should return values only when the value IS the
service, otherwise not". Custom exceptions are in the language for a
reason.

Walden

[Patrick Ratelband]

I am not using the onFailure to report the error. That is not what it
is for, I agree.

However, you can simply use a try catch in your onSuccess block to
deal with any type of (serializable of course) exception.

Patrick

On Aug 3, 6:41 pm, Matt Bishop <mbis...@gmail.com> wrote:
> I think your method should return Boolean at the very least. Every
> server call has the potential to fail it's task and throwing an
> exception may not be the best action. You should return something for
> every call so the client knows it went OK.
>
> OnFailure is for transport errors not business rule errors.
>

[thlaitina]

hi Patrick,

Did you try? I got "Unable to recognize 'java.lang.Void
java.lang.Void' as a type name (is it fully qualified?)" when I put
Void as the return type!

Tina

On Aug 3, 3:01 pm, Patrick Ratelband <ratelb...@gmail.com> wrote:
> Thank you Daniel,
>

> I never thought of usingvoidwith a capital V (silly me... slaps

[Patrick Ratelband]

I have tried and I am afraid that I cannot get it to work either. It
really seems like you have to return something, and you have to type
it, otherwise the GWT compiler will generalize the callback to handle
anything and your code will bloat. Too bad, maybe an idea for the next
GWT release?

Patrick

[Ohad Kravchick]

AsyncCallback<Void> should work.

Pay attention though that you do need to call it with a valid Void object, for which null is appropriate. Not the clearest API, but it works.

void fn(final AsyncCallback<Void> callback) {

  callback.onSuccess(null);