Forum Archive

Here's two things, one follows from the other:
1. It seems that a bound socket currently being listened to for incoming UDP data via select.select() by a thread I'm running, no longer receives anything if the device I'm running on goes to sleep or is locked (basically if the lock-screen shows up, the socket stops receiving). Has anyone else observed behavior like that in pythonista? If I simply recreate the socket once the device is unlocked, things work fine again until the next time I lock the device or let it lock itself by going to sleep.

1. Because of this, assuming this isn't a bug on my end, is there an easy way to detect when my pythonista script returns from "sleep" or whatever it is called when the app resumes from the lock screen? This doesn't happen when the app is backgrounded for a bit...though I haven't seen what happens when I leave it sitting in the background for a long time.

Thanks for any ideas!

@shinyformica, these answers have various ideas: stackoverflow. Does not look like there is an officially documented method, but could be ok options if you are just looking to make this work, for yourself, for now.

Perhaps the simplest approach is just to look for socket failures!

You can swizzle some of the AppDelegate methods, like ApplicationWillResume, or maybe applicationDidResumeFromUnderLock. There are also applicationWillSuspend, etc that happen before you get suspended.

Another approach: it seems that if a script is not actively running (i.e X is available), ui.Views update method only gets called in the foreground. Though if the main script is still running, it seems the view does get updated at least for a while. So you could basically have your own heartbeat using ui.View update. not sure reliable that is though.

Finally, you know you can use console.set_idle_timer_disabled() to disable the idle timeout (auto lock). obviously, if the user locks the screen or switches the app, that wont help.

Thanks @mikael and @JonB! I'll take a look at those options...using the notification center to register for the lock-related notifications seems like a decent solution.

Has anyone noticed anything of this nature? I haven't had a chance to try making some simple tests to see if it is "normal" behavior for a socket to become disconnected when the device is locked/sleeps.