I got an interesting bug report today from folks running a utility I ported to Juce on iOS today. A little testing found a related issue on Android.
The utility does a bunch of network interaction with external hardware/software. On iOS, when you press the Home button and an app goes in the background, it stops cold, but sockets remain open. So the app leaves the other ends of the connections tied up, waiting for inactivity timeouts, which is badly behaved.
On Android, the socket thread keeps running (until resources run low and it is abruptly killed, but this isn’t really user expectation. When the app can’t be seen, it shouldn’t be tying up the resources and killing the battery life.
So I added delegates for appDidEnterBackground (iOS), onPause (Android), WM_POWERBROADCAST (Windows), etc., and extended the application class to include suspend and resume methods that can be overridden in my app.
That was the quickest way to resolve the issue, but it struck me that this has probably come up before. Is there another mechanism that I have missed? I see a Process class, but it wasn’t clear to me how it would be used, and the plumbing didn’t seem to be there to get the information from the underlying platforms.
Thanks in advance!
On Android, if you intend to monitor a socket, you better run a service instead.
If you don’t do this, you’re in a “dark area”, that is, there is no way for your software to act reliably, since you’re not in control of what the OS do with your app.
In general, if you intend to do embedded networking code, the main rule is not to linger a connection, so close it as soon as you don’t need it (all OS have a way to give you a small amount of time for closing your stuff, before killing you).
So for embedded,
- Don’t linger on socket. The penalty for (re)opening a TCP connection is way better than sucking battery life (and it’s unreliable). I’m not speaking of roaming issues you might get when returning from background/freeze state.
- If you want to ignore 1, you’re on your own. Juce might provide a facility for this but since it’s a bad practise, I doubt Jules will be inclined to do that.
Thanks, but that’s the point. Sorry I wasn’t clear before. I’m a client, not a server, and I want to drop the resources as soon as the user isn’t expressly using them.
To do so, I picked up the Activity Methods on Android, added two JNI_CALLBACK methods to the library, extended the application base class, and let them migrate up. I did the same for iOS, etc. So when the user is done with the app, all sockets are released, even though it is technically open and running on Android. This works fine and is akin to what I did in the original native apps.
But I’m surprised this hasn’t come up before, so I’m asking if there is already a mechanism to detect ssuspend and resume in JUCE. Thanks for the answer though.
It’s a good request - no, I’ve not looked into doing that yet, the whole suspend/resume paradigm is pretty new, but will need to be done when I get chance!
FWIW, it was pretty simple (though I haven’t looked at Linux, and I’m treating going into the background on mobile platforms and suspending on desktops the same), and it would help you fill in some of the missing Process methods in Android. I just wanted to make sure that I was reinventing the wheel (it’s a big library, I’m still learning my way around it!)