Need smart insights to properly design my software

[Richard_Altenburg]

As a developer I should know this myself, but lets call me Rusty Richard who needs some help…

My application will do a lot of API calls to the webserver of a game, and these calls will be made from various parts of my user interface, probably with lots of Timers involved. These calls are HTTP(S) requests that will be handled asynchronously, so I basically never know when an answer to one of the many requests will come in.

What would be a general good design practice to create my application as clean as possible, sending out lots of requests and having the user interface just go on and handling all the incoming answers, whether they are succesful or errors. I have a hard time wrapping my head around this design issue, and try to make a clean design that will be easier to debug in the future.,

Any pointers?

[Sam_Rowlands]

It really depends on how the user interacts with the application, if the user has to wait for the informaiton, even in a small panel you should provide some indication that the application has processed their click and is doing something. So I would suggest including progresswheels tied to each visual element and it’s socket. This way when the socket is engaged and doing its thang, the progress wheel is displayed and the user can see that this element is busy updating.

[Tim_Hare]

Will you have multiple simultaneous api calls? Is there enough information in the results to identify what the call was? If so, you can maintain a list of pending calls and match the result you get back to the call and act accordingly. Otherwise, you’ve got a mess on your hands and may need to handle the calls from a thread: make the call synchronous, but set the flag to release time back to the UI.

[Greg_O_Lone]

@315022:@Tim Hare

Will you have multiple simultaneous api calls? Is there enough information in the results to identify what the call was? If so, you can maintain a list of pending calls and match the result you get back to the call and act accordingly. Otherwise, you’ve got a mess on your hands and may need to handle the calls from a thread: make the call synchronous, but set the flag to release time back to the UI.

Another possibility is to subclass the socket and add one or more metadata properties. That way, when the response comes, you’ve got an idea of what was sent.

[Richard_Altenburg]

@314996:@Sam Rowlands

So I would suggest including progresswheels tied to each visual element and it’s socket. This way when the socket is engaged and doing its thang, the progress wheel is displayed and the user can see that this element is busy updating.

Yes, I could and should indeed make a visual cue on every UI element that is currently requesting new information from the API.

[Richard_Altenburg]

@315022:@Tim Hare

Will you have multiple simultaneous api calls? Is there enough information in the results to identify what the call was?

There can be a LOT of different API calls going on, depending on when their Timers fire, and on when a user presses certain buttons. The results do not contain any data from which I can identify where they belong to. I try to picture it in my head, and it is a mess. I need to actually draw this on paper to be able to see it.

[Richard_Altenburg]

@315023:@Greg O'Lone

Another possibility is to subclass the socket and add one or more metadata properties. That way, when the response comes, you’ve got an idea of what was sent.

That sounds like part of the solution, I will do this. Also I need to store which Timer or Method I should fire/call once I get a certain result, this will be spaghetti, but thanks for this idea.