I’m making a small app to communicate between an iOS device and a MacOS computer, using TCP.
The logic works, but not the timing. For instance, just sending 20 bytes from the iOS device may take up to 30 seconds (on my local network). Usually, it suddenly works when I lose patience and stimulate the iOS device (like clicking somewhere multiple times, albeit it’s far from being consistent). This reminds me of a flushing issue, like if the application is sleeping too much while there’s no event (hard to describe, as I’m not a native english speaker; however, this was a common issue when RS started to be Cocoa compatible).
I’d like to use a Flush method like the regular TCPSocket, that’d be the ideal call. However, Xojo.Net.TCPSocket doesn’t have it. It’s also unclear how a WriteData call works (is it actually flushed and my issue lies somewhere else?); the documentation is lacking something here.
Curiously, I’ve not found something related in this forum; I’d have thought it would be a common problem
Any idea welcome.
What is your iOS app doing while it should be sending? What you describe sounds a lot like its not really idling, so the main loop is not run and therefore the socket will not continue to send.
That’s the weird part. My app does nothing but waiting. It’s an app I just started; it has no thread nor timer. Here’s the Connected method:
[code]dim m As MemoryBlock
dim t As TextEncoding
dim x As Text
x=Text.FromUnicodeCodepoint(0)+“tkss”+text.FromUnicodeCodepoint(1)+ScreenIndex.ToText
t=TextEncoding.UTF8
m=t.ConvertTextToData(x)
me.WriteData m[/code]
And then it sits there
I don’t know whether you used Xojo (RS) when Cocoa was in its early stage, but you may remember similar bugs. For example, after choosing the Quit menu item, a Cocoa app would do nothing until an extra event occurred; so, the user chose Quit, the app just sat until the user moved the mouse or pressed a key. This sounds like the same problem.
Thanks.
this manual is very confusing with duplicated classes.[/quote]
Yes, it is.
On iOS, Xojo.Net.TCPSocket is available, but TCPSocket is not. Do you have some trick to use TCPSocket’s methods for a Xojo.Net.TCPSocket object? (that’d surprise me, at the very least)
Thanks.
I see. So what does an iOS app do when it does nothing?
Did you try to call a thread that just monitors a property for 100 % where the Sendprogress event reported into, and have it yield to other threads while this is not true (or an error occurred)? Maybe that could serve as a workaround if it is iOS (or Xojo) not triggering the main loop.
Because iOS currently uses the Xojo framework exclusively.
Sounds like 2020r2 could fix this by introducing API 2.0 to iOS, according to the current roadmap.
Mathematically, the answer to your question would be nothing.
Well, for event driven applications, I bet an app would theoretically uses 0% of CPU when no event is triggered/being executed (because no thread has to do anything).
I don’t quite see the point, if I get your idea right. You mean I put a property in the SendProgress event storing the current percentage of data sent? Well, if the SendProgress event isn’t firing because of this bug (the app just waits), the property wouldn’t help.
Thanks.
The regular TCPSocket isn’t part of the Xojo framework? Granted, it represents an OS socket under the hood, but so does a Xojo.Net.TCPSocket.
I thought the Xojo.Net.TCPSocket was more recent than the regular TCPSocket. Introducing API 2.0 would more likely mean introducing the most recent one, or I’m missing something?
[quote=473914:@Christian Schmitz]The desktop Flush method was something like
while socket.HasBytesToSend
// wait
wend
wasting CPU time while waiting for bytes to be sent by underlaying OS.
But the new socket class has not even a property for the bytes to be sent.[/quote]
I’d better call this a missing functionality rather than a feature.
Unless it’s technically not doable with the new class, but then, it’s a serious lack not motivating to go forward
Thanks.
If you would do only that, Id agree. I meant to install a thread additionally that just keeps your app a bit busy and yields to the main thread while sending has not been done. If you are right with your assumption that basically a DoEvents (the main event loop) is missing, this could possibly keep the app from sleeping too quietly.
Usually, an app is not fully idle but will keep the event loop running. But I dont know what Apple might do on iOS where battery level is important.
When Xojo iOS was created, it introduced the Xojo framework which at this time was supposed to become the new official framework API 1.5 Not only with Text and Auto, but with most of the controls being renamed too. So yes, under the hood thats possibly the same.
For a time, that was true. But then the Xojo framework was deprecated, while iOS has not yet been updated to API 2. Which basically is meant to make xplatform development easier. The only reason to use the Xojo framework nowadays is iOS (or when you need features like UnicodeCodePoint that have no API 2.0 equivalent )
Not sure but if the iOS tcp socket is based on CFStream (which I suspect it is) then there is no “flush” on a cfstream - hence no flush on a Xojo TCPSocket on iOS
POSIX style sockets exist on iOS BUT - and this is a big deal - Apple notes