Basically if you have a UDPSocket, it works great until the device is locked. If you attempt to use the UDPSocket after the device is unlocked, the app will crash hard. Exception handling doesn’t catch it. Calling UDPSocket.Write is what triggers the crash.
And this has to be on an actual device. The simulator doesn’t show this behavior.
I’ve never added anything to any plist file. I would assume Xojo should be doing all that. The app requests access to connect to devices on my network and I give it permission. So that should not be the problem. And the socket works fine when the app is open and the screen unlocked. It’s after locking and then unlocking that the problem occurs.
And I don’t think it’s entitlements either. When I tried to access photos without the entitlement enabled, the app would hard crash. But iOS would generate a crash report with the message that I was trying to access photos. I’m not seeing any crash reports from iOS here.
Xojo is not doing every plist entry. If you want you can add a feedback request to add all required plist entries for the classes.
I’m sure apple closes the socket when the screen locks. They do all kinds of stuff to keep the battery level up as much as they can. Keeping sockets open is a thing that you must be careful with. You can use the App.Deactivated event to close sockets. Then reopen/connect or bind on App.Activate
Problem is, the socket is not closed - at least not what Xojo sees. Here’s some of my code in a write method of a subclass:
If Not MyUDPSocket.IsConnected Then
System.DebugLog "UDPSocket not connected - Connecting."
If Not MyUDPSocket.JoinMulticastGroup(UDPGroupIP) Then
System.DebugLog "Could not join the UDP group - Leaving."
UDPSent = True
system.debuglog("UDP - Writing to UDP Socket: "+txt)
If MyUDPSocket = Nil Then
System.DebugLog "UDPSocket is NIL"
If Not MyUDPSocket.IsConnected Then
System.DebugLog "UDPSocket is not connected."
System.DebugLog "UDP Group: "+UDPGroupIP
System.DebugLog "Exception - Trying again"
System.DebugLog "Trying the write again."
System.DebugLog "Second Exception."
UDPSent = False
The DebugLog statements and several IF/Then blocks are all in there trying to figure out where things go awry. Xojo never sees the socket as closed. And the Try/Catch blocks don’t catch the exception/crash. As soon as the write method is called the app crashes.
So I agree that something is being shut down. I can see it happening in the console. Problem is I don’t want it shut down. I still want the app to be able to receive UDP packets when the screen is locked. Minimizing the app by switching back to Springboard and opening another app and then going back into the app doesn’t cause the same problem. It’s a lock that does.
You cannot just connect and expect it to work. Apple can stop port bindings if the port is already used or inaccessible (even if the batery is low etc). It’s best to check if the isconnected returns true and if the port is actually set only if these conditions are valid, you can join the group and/or write.
Uh, I think you missed a lot of my code. See below. There’s also code I didn’t show where I set the port, etc. I’ve used this code without issues for years on the desktop It does work and works fine UNTIL THE SCREEN IS LOCKED AND THEN UNLOCKED. Xojo thinks the socket is still connected. So it does me no good to check if the socket is connected as it is connected! And the port has been set back when the socket is first setup.
The socket definitely seems to be torn down when the phone is locked. Xojo just doesn’t know it. I was exchanging my UDP data between the iOS and desktop app. Then after locking the phone, I tried sending data from the desktop app to the iOS app. After unlocking the phone, nothing was updated.
I’m kinda disappointed as that was part of the whole reason I was excited about having a UDP socket. I do have a protocol where I can request updates. Maybe I’ll have to do as you say and destroy and rebuild the connection.
Xojo can enable background tasks but there’s no entitlement for UDP sockets or networking in general. Just things like VoIP, Notifications, etc.
Now, Xojo should still not crash with this. The odd part is I use TCPSockets a lot as well and those don’t have this problem. They seem to stay connected or at least Xojo can detect that the TCPSocket is disconnected. With UDP, there’s problems.
Are you doing anything that could use a lot of memory? Some limited googling seems to say that if you run out of memory while in the background the app can crash when it comes back to the foreground and leave no crash log. Maybe you have an old iOS device with less RAM?
When your app is active but off screen, your socket is downed by apple to keep the battery alive. The only way to keep it active is register for mDns (bonjour) use and add a backgroundTask but that’s not possible in xojo. You can however add background pushnotification. That works in xojo now. So if you use a http or tcpsocket you could send data after the background push notification is received. (You’ll have 30 sec before the app shuts the background push notification again).
As far as i know streaming tcp/udp is not possible when the app is in the background normally.