Discussion on Application Suspend/Resume & Exit system events

Important findings on this this topic by @FearTec … See - http://forums.coronalabs.com/topic/45665-system-event-applicationresume-and-applicationsuspend-bug-fixed/#entry237827

I notice images show up corrupted (almost like re-arranged messy jigsaw puzzle, as if bits and pieces of the images are taken from the wrong location) when resuming a suspended android app (regardless of whether i’m using snapshots), the corrupt images are either jpeg images or images from an image sheet. So question is, in the applicationResume event phase, do i need to set a delay before allowing the game to continue or something? I understand if using snapshots that you need to invalidate the snapshot at this time but even when using snapshots they also show up the same corrupted way.

I have seen the same issue of corrupted images on appresume in Android. Anyone else had problems like this?

Yes exactly, possibly its large images (either normal type or image sheet) that get corrupted when reloading after app resume as most of the images load back fine. Not sure what corona/we can do about this or if they are even aware of this.

I’m curious if there are any limits on what kind of things we can do on applicationSuspend. If the operation takes too long will it be killed? For example could I safely do a vacuume command on a 100,000 row sqlite database on suspend?

As a rule, you have time to close files and stop timers/animations.  I don’t know the exact amount of time and I don’t know for certain about Android, but for iOS, if you don’t get done quickly, it’s going to exit on you.

My main resume-related problems thus far are on Android. Since I was using snapshots, I ended up recreating the entire screen on the resume event. This also solved the on-screen corruption of non-snapshot images. However, I found I had to use a delayed recreate (using timer.performWithDelay with 1 sec) since the resume event handler was executing during a period during which the underlying corona system had not settled down. Without the delay timer, the snapshots recreated from within the resume handler are not visible.

I notice images show up corrupted (almost like re-arranged messy jigsaw puzzle, as if bits and pieces of the images are taken from the wrong location) when resuming a suspended android app (regardless of whether i’m using snapshots), the corrupt images are either jpeg images or images from an image sheet. So question is, in the applicationResume event phase, do i need to set a delay before allowing the game to continue or something? I understand if using snapshots that you need to invalidate the snapshot at this time but even when using snapshots they also show up the same corrupted way.

I have seen the same issue of corrupted images on appresume in Android. Anyone else had problems like this?

Yes exactly, possibly its large images (either normal type or image sheet) that get corrupted when reloading after app resume as most of the images load back fine. Not sure what corona/we can do about this or if they are even aware of this.

I’m curious if there are any limits on what kind of things we can do on applicationSuspend. If the operation takes too long will it be killed? For example could I safely do a vacuume command on a 100,000 row sqlite database on suspend?

As a rule, you have time to close files and stop timers/animations.  I don’t know the exact amount of time and I don’t know for certain about Android, but for iOS, if you don’t get done quickly, it’s going to exit on you.

My main resume-related problems thus far are on Android. Since I was using snapshots, I ended up recreating the entire screen on the resume event. This also solved the on-screen corruption of non-snapshot images. However, I found I had to use a delayed recreate (using timer.performWithDelay with 1 sec) since the resume event handler was executing during a period during which the underlying corona system had not settled down. Without the delay timer, the snapshots recreated from within the resume handler are not visible.