Does the new URLConnection class use WinHTTP and require the windows update that Xojo.Net.HTTPSocket does? What’s being used on the backend?
Oh, and while I think it’s safe to assume, I’d rather just be clear. This class is not yet available to iOS, right?
William will want to confirm, but my understanding is that URLConnection uses the WinHTTP C/C++ API with support for TLS 1.2. I don’t believe it requires the Windows update needed by Xojo.Net.HTTPSocket.
And because URLConnection uses String, which is not yet available for iOS, URLConnection is not available yet for iOS.
ok.
Yeah, I figured as much. Just wanted to be explicit.
That is correct.
i must say the URLConnection is so much easier to use without the “old-new-framework” less conversion, instant using JSONItems again. And when it’s really needed sychronous calls!
Thanks xojo…
this helps, it does.
This to me is a major disappointment.
Why? You don’t have to use that way if you don’t want to
- karen
Ugh, the forum delete without being able to undo is a pain. I misclicked and now my detailed thought out explanation is gone.
I’m not rewriting it, so I’ll leave it at “it’s a really bad idea.”
Edit: I will readd that I was very excited that the namespaced framework was guiding Xojo users toward thought out and professional approaches to software development. There was no requirement to use the namespaced framework, you could stick to the classic one should you want to. But implementing a new framework with the toxicity of the classic framework just solidifies the bad behavior for the next 20 years.
In the classic HTTPSocket, synchronous mode was handled by App.DoEvents. So the advice was really “don’t use DoEvents unless we do it ourselves.” However, I have no idea how this new socket handles things behind the scenes. There are a number of ways Xojo could have handled this to be less evil.
Wether or not it’s a good idea is up for debate. I don’t think locking your UI during a request is a good idea, given that it could be up to 60 seconds of your app being non-responsive. On the other hand, if this plays nicely with threads, it would be perfectly acceptable to use a synchronous socket inside a thread.
Like any tool it can be used and abused. But we don’t know much about this class yet.
[quote=414676:@Tim Parnell]There was no requirement to use the namespaced framework, you could stick to the classic one should you want to.
[/quote]
Actually under teh original plan that was not really really the case because the classic framework was not going to keep up with the times… and protocol support in the classic HTTP socket was a case in point.
As one knew (back then) That it’s capabilities were not going to get updated, that strongly discouraged using it (or would have if the now deprecated new framework had been ready for prime time)
I found coding with it much more of chore and a lot less enjoyable than the classic…
[quote]
But implementing a new framework with the toxicity of the classic framework just solidifies the bad behavior for the next 20 years.[/quote]
Well I think the degree of “toxicity” is a matter of opinion… Sometimes one needs to code quickly to solve a problem with code that is not meant to last for years , and sometime one needs to have things very structured… and its nice that Xojo can be used productively for both, with both approaches on equal footing.
The Classic framework did not stop you from making extensive use of namespaces in your code (BTW I do use them now more than I used to) and using the degree of code discipline that was appropriate for the task or to meet your preference… hopefully new framework 2 will follow that philosophy as well.
- Karen
Well in my case I am compiling information for a report based on large volume of data from an instrument for a single sample… because of the nature of that the code has to do, it can’t do the the next thing until it gets the current info…
It might be possible to do a little in parallel but the the websites where i get the data from only allow so many queries per unit time… if you want to keep using the service…
So the app really has nothing else to productively do then… But the user can still use other apps in this multi-core world… Sometimes when It’s running I check the forum! 
Beside the only users besides me would be people who report to me, so I think they will be fine with it!
A thought here; this goes for anything that can be asynchronous or synchronous. I personally like the cleaness of Thom’s suggestion, where you have multiple requests that have to be fired in order. A single thread can handle these nicely and compactly (and in theory without blocking the main thread).
I recently had to implement a function that uses asynchronous objects, but the process must be fired in a specific order. It became a bit of mess and I’m sure when I come back to it in the future, I’m going to wonder what I was smoking. It fires the first process and then doesn’t do anything until the asynchronous object signals it’s finished. It then collects the data, updates the step integer and fires a timer. Because I run into problems trying to re-use the object from the completed event. It seemed it needed to wind down before it be used again, then the timer will signal the next step, which reads the integer and fires the asynchronous object. Rinse and repeat.
If I’d gone the thread routine, which I might change to in the near future while I remember, it will save the toing and frowing between async objects and timers while not hogging the event loop.
makes perfect sense to be able to do it sync under some conditions. Like in a console app… If you can stack them up in a thread then that is equally terrific. Simplifies doing a list of things without having to build a little state machine to handle the replies and fire off the next request. I can do that if necessary But there really are times when this is useful!
Yeah. Personally, I would like to see it fire an exception if a synchronous request is made on the main thread of a desktop or mobile app. I can see the argument that if people want to write crappy apps, they should be allowed to. On the other hand, I prefer not to let them, which protects those who dont know any better and defends the reputation of Xojo itself.
[quote=414766:@Thom McGrath]Yeah. Personally, I would like to see it fire an exception if a synchronous request is made on the main thread of a desktop or mobile app. I can see the argument that if people want to write crappy apps, they should be allowed to.
[/quote]
I think that is a narrow view for general purpose tool.
Not all apps are for general public consumption. Some are used for very specific narrowly focused task oriented applications. For the app I mentioned I considered using async queries, but as far as I could see, it upped the complexity without a real benefit as I couldn’t do parallel queries because of the web service involved.
All kidding aside, there really was not anything else for the app to do but put up a modal progress dialog until all the processing was done (which I did), so locking the UI for that app while it is waiting for a response (which actually is very quick) is not a significant issue.
Doing async it would have looked to the end user exactly the same, except that the cancel button (which is rarely- and so far never- used) could respond faster… It would have been significantly more work for minuscule (if any) return in productivity in the workflow.
That type of thing is why one size does not fit all and why “crappy” is not an absolute term when it comes to design… Fit (or not) for purpose IMO is.
[quote]
On the other hand, I prefer not to let them, which protects those who dont know any better and defends the reputation of Xojo itself.[/quote]
So you want to be the “Xojo Soup Nazi”?
BTW this recent Dilbert comes to mind (and yes I am joking)
- Karen
[quote=414770:@Karen Atkocius]I think that is a narrow view for general purpose tool.
Not all apps are for general public consumption. Some are used for very specific narrowly focused task oriented applications. For the app I mentioned I considered using async queries, but as far as I could see, it upped the complexity without a real benefit as I couldn’t do parallel queries because of the web service involved.
All kidding aside, there really was not anything else for the app to do but put up a modal progress dialog until all the processing was done (which I did), so locking the UI for that app while it is waiting for a response (which actually is very quick) is not a significant issue.
Doing async it would have looked to the end user exactly the same, except that the cancel button (which is rarely- and so far never- used) could respond faster… It would have been significantly more work for minuscule (if any) return in productivity in the workflow.
That type of thing is why one size does not fit all and why “crappy” is not an absolute term when it comes to design… Fit (or not) for purpose IMO is.
So you want to be the “Xojo Soup Nazi”?
BTW this recent Dilbert comes to mind (and yes I am joking)
- Karen[/quote]
Even though there is not something better for your app to be doing, its still bad form to lock the UI while waiting. On Windows, the app is not responding dialog will show up. On Mac, it beach balls and lists the app as not responding. On iOS, your app is terminated. None of these things are desirable. Your requests may normally finish quickly and the delay not matter, but they COULD stall your app for up to 60 seconds.
So yes, I do believe you should be doing these steps in a thread, even for an in-house app. You could offload most of the process to a single thread and not change much, but make your app a much better citizen.
Agreed. Blocking the UI, even for just a few seconds, always looks like something is going (or already has gone) wrong.
Any experiences so far how thread-nicely URLConnection behaves when used synchronously in a thread? A synchronous command in a Xojo thread can still stall the UI if the thread scheduler finds no place to yield.
And just to follow up on this, even though I know it was in jest. I’d be ok with that. Remember, my opinion is skewed by the fact that I worked for years at Xojo. So much of our time was spent on support, in Feedback and otherwise, helping people who were misusing their tools. Like the “update a progress bar in a tight loop” question that comes up here every so often. It gets sooo draining answering the same questions over and over again. “Why does my app beachball when making an HTTP request” is a question I would like to avoid ever being asked. People don’t read documentation, so the API must guide the user as best as possible into making the right decisions.
This is why the old new framework was designed in much the way it was. I never agreed with replacing the whole framework, but I absolutely agree with the motivations behind it. Things like making dates immutable, having the databases and folder items fire exceptions, no synchronous http requests… all good things.
So yes, I’m ok with taking away your ability to make synchronous http requests on the main thread if it means protecting countless others from bad designs that will end up wasting support time and reflecting badly on the product. I know you are aware of the pitfalls and can accept the risk, but that’s not universally true.
problem is some APIs require SYNC calls and not ASYNC.