Hi, 

 

I had some questions of my own regarding post-suspend and post-exit cleanup needs of my app so I wrote a little test app that does nothing but alert me (on console) when these states occur. I had some interesting observations & questions which in some cases don't make sense. I'd like to open this up for some discussion to see what you all think. Here goes : 

 

1) for IOS we can specify UIApplicationExitsOnSuspend = true in build settings. Is there an Android equivalent if we want this behavior consistent on both platforms?

 

2) With UIApplicationExitsOnSuspend = true my demo app sure enough exits when I click home button. However, when hit the power button on my IOS device the demo app does not exit but instead goes into suspended mode.

 

3) Very similar to the case above, if I let the app run on foreground and do nothing, eventually my IOS device goes into powersave mode and shuts screen down and sleeps. Again my app does not exit but goes into suspend mode. When I hit home or power to wake the device up my app resumes from suspend state. 

 

So #2 & #3 proves that checking for ApplicationExit state and doing things like closing db etc might be of little use if you can't even force your app to exit on suspension UIApplicationExitsOnSuspend = true may lead you to believe. Developer beware!

 

4) Using either UIApplicationExitsOnSuspend = true or false states another potential pitfall is when a user kills your app. I placed my app in suspended state and then double clicked the Home button. Using the new IOS7 gesture of flicking the app upwards, I forced my app to stop running. I would have expected to see Application Exit event firing off first but sadly this was not the case. So once again if your app needs to take care of business before exiting you will miss the boat when your user gives your app the flick. 

 

5) I observed a very similar outcome on Android. Using Settings / Applications / Manage Applications - I was able to "Force Stop" my app to see which application state messages I would get. Unsurprisingly I got none. Same comment as above. Perhaps you need to do the cleanup (if its crucial) at suspend rather than wait for exit which may never come... 

 

I would very much welcome thoughts and feedback on how you cope with the lack of an authoritative Exit state on IOS & Android platforms when using the Corona SDK. Many thanks in advance. 

 

Code snippet used to get application state info printed on console included below :

 

local function onSystemEvent( event )
    
    if (event.type == "applicationStart") then
        
        print("Application started")

    elseif (event.type == "applicationExit") then 
    
        print("Application exited")
        
    elseif ( event.type == "applicationSuspend" ) then
        
        print("Application suspended")        
    
    elseif event.type == "applicationResume" then
        
        print("Application resumed from suspension")              

    end

end

--setup the system listener to catch applicationExit etc
Runtime:addEventListener( "system", onSystemEvent )

 

 

Any thoughts on these observations? Especially #2 & #3? Any strategies to cope with these challenges? Thank you. 

First, Apple will reject your app if you exit.

On iOS, you can in your "suspend" handler call os.exit().  Again this is not advised.

For Android,  you can do a native.requestExit() call in your suspend handler.  This is acceptable in the Android world.

 

As for no events when your app is killed, I'm pretty sure that's by OS design.

 

Rob

Hi Rob, thanks for chiming in. I think you misunderstood my point. I don't necessarily want to exit but I want to catch the exit action for cleanup actions on a reliable manner. It appears that either due to OS design or due to Corona SDK design right now we have few gaps in our abilities in this regard. How do you handle the app exit cleanup chores in your apps? Thanks for sharing.

As a rule, there shouldn't me much clean up to do.  Like when I make a change to settings that needs saved, I save it immediately.  I don't keep things in memory and wait until I get an exit event and then flush things.  I'm guessing this could create a potential issue with SQLite, but I don't use it very often and I don't know how often it flushes it's writes.  But realistically there shouldn't be much else to do if you save state when you change state.

 

Rob

this was some of the issues I have with my blackBox module. also on android if you send an email from your app it generates a suspend event and then a resume event afterwards but on iOS it doesn't

Android seems to have more suspend/resume events.  For instance, I've seen trying to play a splash screen video, Android tries and suspend and resume on the video play.  I suspect this is how Android handles various activities where on iOS it's more OS dialogs that are popping up (i.e they are compiled into your app).  <--- speculating.

 

Rob

I'm guessing this could create a potential issue with SQLite, but I don't use it very often and I don't know how often it flushes it's writes.  

 

This is exactly where my questions are aimed at. Currently I place a db:close() in my applicationExit catcher thingy. Perhaps I should place it in the applicationSuspend to be perfectly safe and then simply reopen db at applicationResume. Should add little overhead.

That's probably the best practice. 

 

Rob

Hi guys,

I only have one app that uses SQL Lite for storage and retrieval and it isn't large. I have 3 tables that only contain about a dozen records in each (settings, statistics and achievements).

I have placed my required db functions for creating tables, inserting data, updating data and retrieving data into a separate dbfunctions.lua file. In my main.lua file I call another file called loading.lua which acts as a loading screen and retrieves the values into local LUA tables (and does the default setup for first time users). I then pass these local LUA tables around as params in the storyboard so I never have to touch SQL Lite again for retrieval, only updating (e.g. if settings are changed in the options screen, in which I update the settings in the local LUA table in realtime, and update the underlying database when the user hits the save button).

I know this isn't the point of the question (of how to manage exits) but thought I'd share as it is how I avoid needing to worry about data loss due to exits.

Obviously this wouldn't be possible for huge datasets or business applications but for games it works great for me.

Cheers
Glenn

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.