I have a URLconnection method that uses send(“GET”,URL) to put data into a TextArea. On the ContentReceived event, I am able to process this data. Works great. But I’m not sure how to handle multiple of these in sequence. We obviously want the first to complete before we launch the next. I could bury launching the next GET at the end of the prior ContentReceived event (to avoid collisions) but that seems like a hack.
I could also create a Global FLAG that indicates status of each GET/ContentReceived and check that with a timer before launching the next GET. But Global Flags tell me I’m thinking about this wrong. I also worry about unintended race conditions with this approach.
What is the right way to deal with multiple asynchronous interactions with server data using URLconnection?
Putting it into ContentReceived is the way I’d do it.
Depending on how many you mean, and if order is important, you could also create an array of URLConnection and send them simultaneously. Or create a class that handles that for you with X simultaneous requests at a time.
Have in mid that Xojo is very limited in this matter because of its single thread nature. So, fancy ways will not add a lot of speed. What yo sugested is perfectly valid.
If you want to look like less like a hack, you can make a URLconnection subclass with a new event “AllDone” or anything else and use it to call the next GET
Thanks. I’ve implemented the URLConnection.error event and tested that with the internet disconnected. Works fine. But what I have not been able to figure out is what happens when the URL just does not respond. I’ve not located a Timeout variable I can adjust. I also am not sure if the error event is thrown when that timeout is reached or something else occurs. Thoughts?
And one MAJOR issue to look out for is sending a request when the prior request hasn’t completed. This will throw an UnsupportedOperationException “A request is already in progress”.
@Kem_Tekinay: Thanks for confirming the error event. @William_Reynolds: Thank you. Yep, not launching a new event until the previous one completes is my original worry. I keep thinking of the song by the Police, Synchronicity …
I now see the timeout and error questions documented in the URLConnection.Send method. I was looking only at the parent control in the docs. Thanks for pointing me in the right direction.
See here too:
Multiple asynchronous interactions are best handled with multiple asynchronous sockets.
I found the best way to not run into issues as described above (or their often complex handlings) is to have a custom class that creates URLConnections by demand, keeps them alive and does their event handling. And it’s very easy to keep track of sequential server operations when you attach a custom content tag property to that subclass.
IMHO, Xojo using the same metaphor for stationary sockets like serials for asynchronous sockets too is a bit misleading, at least when you use asynchronous operations. You will always feel the need to subclass it (or risk running into send attempts while still sending and the like).
A while ago I had a similar need to download multiple files at once. After making a queue I got not-reproducible crashes. Instead I implemented CURLSMultiMBS in a fraction of the time I needed for the HTTPSocket queue. I have 2 classes: a queue class which initiates everything and a class for getting information when a download has finished.
Apparently I started to get this while working with an api and the only way to fix it was to add the next call in the ContentReceived event but it would be nice to be able to send multiple calls and the socket to handle those automatically and once it got a reply to fire ContentReceived.
I assume the second option would be to use the socket as property and call is as a separate instance and handle all separate .
I’ve tried this, but instead of firing the Error event when the request timed out, it threw some kind of runtime exception (sorry, I didn’t capture exactly what it was). Seems to defeat the point of the Error event
In general, I really dislike Xojo’s recent trend toward handling a variety of conditions with exceptions rather than error codes, it tends to clutter everything with lots of Try-Catch structures instead of the old way of just checking an error property.
