I had initially imagined that there would be cases of long request waits (due to slow connection, slow processing on server, whatever). In practice, I haven't really seen that yet. If the server is well behaved (in terms of prompt updates and proper async task implementation) and the client is connected at all, things seem snappy.
That being said, if there was a case where a request was pending for more than say 500-750ms, we might want to show an hourglass (and maybe stop allowing input, to avoid constant button mashing that backs up even more requests). After a slightly longer timeout, maybe 5-10 seconds, we might want to let the user have the option to force-refresh, possible by popping up a message box explaining the situation, with a "Refresh" or "Retry" button. If the response comes in while the dialog is up, it should dismiss the dialog and continue.
This is a fair chunk of work, and I'm not sure how necessary it is going to be, so I think we'll wait and see.
I had initially imagined that there would be cases of long request waits (due to slow connection, slow processing on server, whatever). In practice, I haven't really seen that yet. If the server is well behaved (in terms of prompt updates and proper async task implementation) and the client is connected at all, things seem snappy.
That being said, if there was a case where a request was pending for more than say 500-750ms, we might want to show an hourglass (and maybe stop allowing input, to avoid constant button mashing that backs up even more requests). After a slightly longer timeout, maybe 5-10 seconds, we might want to let the user have the option to force-refresh, possible by popping up a message box explaining the situation, with a "Refresh" or "Retry" button. If the response comes in while the dialog is up, it should dismiss the dialog and continue.
This is a fair chunk of work, and I'm not sure how necessary it is going to be, so I think we'll wait and see.