Android Question HTTP requests synchronous queue

peacemaker

Expert
Licensed User
Longtime User
HI, All

If we have an app client (on lots of devices) that works with HTTP API on a server with non-stable Internet connection - it's very important to make all correct that:
1) not to lose the unsent data
2) not to send unconfirmed data many times
3) not to overload the server by tons of requests (if many clients - it's easy possible)
4) sometimes during HTTP-reply parsing it needs to send another HTTP-request - confirmation or additional info getting
5) HTTP requests for CRUD: SAVE (create), LOAD (read), UPDATE and DELETE from a server database
6) some file upload or download is needed periodically, file may be big, and whole Internet connection bandwidth is occupied
7) and sure, all must wait for Internet connection restore, if missed.

I guess, all HTTP-requests must be in a one queue, fully synchronous sending. And it looks like that a STACK queue is needed here, not FIFO.
How to do it all together correctly, any suggestions?
 
Last edited:

mcqueccu

Well-Known Member
Licensed User
Longtime User
 
Upvote 0

peacemaker

Expert
Licensed User
Longtime User
@mcqueccu, thanks, but what did you mean exactly ? How to use it ?
HTTP requests are made from any point of app code, result of each request is unknown, time of execution finish - also unknown. How to use SQL with waiting for this ?
 
Upvote 0

peacemaker

Expert
Licensed User
Longtime User
No task to change server part, it needs to make up the Android app that works with ready server's API.
So, question is how to make global HTTP requests sync queue... for all points of the app.
 
Upvote 0

KMatle

Expert
Licensed User
Longtime User
It's all about app and api design to handle this. A http request is just one function. If it fails, repeat it, no need for a "native" queue. Add some logic when a "task" is completed or not. If several requests are needed, just store one were successful. Then the next one until all are finished. Short: Don't store or queue requests, mark the data if it is sent/processed or not. Use e.g. a SQlite DB to handle the process. A simple list will do, to.
 
Upvote 0

peacemaker

Expert
Licensed User
Longtime User
Yes ! That is the question which logic is to be used, if
1) many points (subs) where HTTP-requests should be done
2) each replay must be checked, sending data are marked as sent
3) sometimes a reply parsing must make a second HTTP-request, slave one
4) any time any network error may interrupt all
5) server can reply 5xx error also, if overloaded. And next HTTP-requests will overload it further, if requesting is not stopped

So, how to handle all these...
 
Upvote 0

OliverA

Expert
Licensed User
Longtime User
Then just do one request at a time only. Use a global flag to indicate if a request is currently made, and if so, don't perform the request.
 
Upvote 0
Top