well something did change, we suspect a subtle change to how the Android keyboard gets activated, but the real cuprit was the 'end' command.
Yes, I got bitten by this:
https://forum.thegamecreators.com/thread/227351
Here is why...
In my main loop I call the socket handler, which handles getting a connection and passing incoming data off to be parsed and dealt with.
If there is no IP address, it asks the user for an IP address.
Some weeks ago I noticed that after ending my program, the socket on the other side was still open. I checked my code and decided that even after closing the connection, and terminating , the socket handler managed to reconnect. I thought that somehow the main loop was running, so in my termination code I simply cleared the IP address, so that it could not connect again. This all seemed to work until the Android change this week.
After my son and I dug into what was going on, he found the forum post above, and we learned that the 'end' command, on Android, no longer does what we thought it did. It minimizes the program and pauses it. It does not terminate the program on Android. So what was happening was the socket handler was about to prompt for the IP address, when the program got paused. When we 'launched' the program again, it was not in fact starting the program, it was just resuming the existing one, and for some reason the keyboard was not being activated like before. This is probably due to a subtle timing issue, something happens a bit faster or a bit slower than before, and without the keyboard activation, nothing could be entered into the IP prompt and the app was effectively hung.
Once we found out that 'end' only pauses execution, this explained why the connection was being remade weeks ago and what was going on.
When I am no longer using my app on the Android phone, I don't want it to keep a the TCPIP connection open, as I am often connecting to small ESP8266 processors where I am limited to just 4 connections. So we now disconnect when we are minimized and then auto connect again when we are activated. Here is our new function to handle this:
Function CloseDownApp()
// Android does not end, so we only end on Windows
// on Android it disconnects and minimizes until it is resumed, at which point it auto reconnects
if GetDeviceNetworkType() = -1 // only implemented on android/iOS !!!!!
// windows
Disconnect()
end
else
//non windows so Android or iOS
Disconnect()
MinimizeApp() // since we dont really terminate on android
// pauses here until no longer minimized (LCS solution!)
while GetResumed() = 0
endwhile
endif
EndFunction
Since we needed to know if the code was running on Android and not Windows, we wanted to know what platform we are on. Sadly the documentation for the function GetDevicePlatform() states that everything will return a zero except an Amazon device which will return a 1. It is therefore pretty much useless to determine the platform. So we looked at GetDeviceType(), sadly what that does is return the version of whatever OS is being used and the values are open ended so we would have to maintain list of versions and hope that Windows and Android never get to to have overlapping versions. Then we found a function that has not been implemented on Windows....
GetDeviceNetworkType() will return -1 on Windows so we use that to know if we are on Windows. This is kind of kludgy as it relies on AppGameKit not implementing it on Windows.
Understanding that 'end' does not end allowed us to get back to an app that gets paused and continues again when used again! What a learning experience.
TL;DR;
end does not (Doc need to be updated)
No good function to determine OS type see GetDeviceBaseName()
