I have a timer app, it counts up for an indefinite amount of time (until the user stops the timer). It works much like the default iOS clock stopwatch.
I have read the articles about being a responsible background app. I don't have any UI changes happening and stop the timer when the app goes in the background and resume the timer upon returning to foreground. The app does send a local notification every 30 minutes or so to remind the user to take a break.
Problem: Without fail my app is terminated after a few hours (between 2-6 or so hours) and the current timer and info is lost.
Things I've tried:
-As aforementioned I changed my app to follow the guidelines of being a responsible background app (before I had the timer UI counting up and also the timer running, even while in background). I thought this would solve the problem since my app isn't using up much memory or doing any intensive tasks.
-I also have tried saving out the data of the current timer (to NSUserDefaults) in ApplicationWillTerminate and then restore it on DidFinishLaunchingWithOptions. It doesn't seem to work. It's almost like my app is force quit or something because if ApplicationWillTerminate was being called then it would save the data and restore it upon the app launching again. Mystery.
-Currently I'm saving an NSDate of the start time of the NSTimer on ApplicationDidEnterBackground, invalidating the timer, and starting the timer and restoring the start time upon ApplicationWillEnterForeground. Still no luck.
The thing is this is affecting a very small percentage of my users--so it's not like it's a problem for everyone, which makes it more confusing. I still want to fix it of course because it's a pretty lame bug--and I've encountered it myself (on an iPhone 5), so it's not necessarily an old iPhone low memory somethingorother problem.
This has really boggled me, I've done my research and also scoured fairly well the stack overflow questions and don't seem to find much of anything to help me.
Any help would be appreciated, feel free to ask more questions or tell me to clarify.
applicationWillTerminate is basically never called. It will not be called when your app is in the background and it gets removed from memory. You should expect your app to be removed from memory if it hasn't been used for a while. How long "a while" is depends on what else the device is doing at the time... Best to use applicationDidEnterBackground: or applicationWillResignActive:.
When your app goes into the background, record your timer's elapsed time (eg: in NSUserDefaults or however you prefer). Also record the current time. When the app comes back into the foreground, look at the two values you recorded and update the elapsed time accordingly, ie:
elapsedTime = savedElapsedTime + (currentTime - timeWentIntoBackground)
There's really no reason your app needs to remain active in the background burning the user's battery just to keep track of seconds ticking by.
Also, don't rely on applicationWillTerminate. Use applicationWillEnterBackground.
Related
In a cocos2D powered iphone app, I use the CCRepeatForever action to make the background pass by. It works fine when I debug the app (build and run via XCode). Even if I quit the app and resume it, no problem.
However when I bundle the app into an .ipa for beta testing I get a weird problem :
At launch the background passes by nicely. But if I quit the app and resume the game later, the app takes me back where I left it, with everything working but the moving background. And after a time (roughly proportional to the time since I quitted the app) the background starts moving again as it should, without me doing anything particular.
Is this a know issue ?
Thanks
OH, I had a very similar problem a little while ago. I would pause the game, then on resume nothing would happen, then it would suddenly jump and I'd be swarmed with monsters.
I can't tell you precisely where to look, but here's what I was doing:
I had a timer that was not using the (ccTime)dt to calculate time, but was using an NSDate timestamp. The problem was that I had an event to be scheduled at a certain time based on the date, but was using the dt to figure out when to trigger the event.
As far as I could tell, pausing the game was halting the scheduled events, so the "dt" wasn't incrementing at all, but the system clock kept ticking, so what ended up happening is that I would pause for say 10 seconds, the system clock ticked up and triggered, but the "dt" was adding into a float timeElapsed, and until that caught up, nothing happened.
What you probably need to look for is something inside a scheduled event that is using an NSDate or a unix timestamp or the iPad/iPod system clock. When you halt the simulator, the system clock doesn't seem to run the same way it does on an actual iPad.
Sorry, I don't know EXACTLY how this stuff works, but I also went through an agonizing time with a similar problem and it was based on the system timer. Just make sure you're pausing everything with the CCDirector properly and make sure you're not using any system clock stuff for game timing
I am doing the iOS timer application, but when I press the home button the timer will stop.
I would like to know if close the application, the program can keep working?
And go back the application can keep running.
I see some article How to write a background service in iphone application? said can't run in background.
Can some one help me?
Thank you.
If it's a timer you are doing, you can always keep the time when it started, through CACurrentMediaTime(), and if your application goes in the background, when it comes to the foreground again, in applicationDidBecomeActive:(UIApplication *)application, take another CACurrentMediaTime() poll, and display the difference between the numbers.
I believe this is how the Apple's bundled app works. No need to keep processing that number if the application is not used.
I have an app where I have 5 sets of animations that I'm storing in an array. The animations get picked to play randomly after a button touch. This is all working perfectly, however I noticed a bug when I quit the app and reopen immediately, I'll see my main view, then it'll jump to my second view that has the animation in it. (This shouldn't happen since you have to tap the main view in order for it to modally swap in the second view. If I interact with it everything works for a few seconds, then it closes with no crash log.
I finally realized that some of the objects must not be getting released fast enough, since if I close the app and wait three seconds, then reopen, everything executes fine.
I didn't want to put down code to show as this is more of a brainstorming question. I'd love any insight that could point me the right way. I changed a lot of my code to get rid of convenience methods and have all my variables defined and then released in my dealloc.
Is there a way to truly tell the app to kill everything on quit? It's not set to run in the background so this is a bit odd. Thanks for your help I'm still new to this and learning!
Alright, after working on this all weekend and doing more research comparing a barebones version of my app to my prerelease version, I traced memory leaks to the Flurry Analytics api that I am using. Apparently I was suffering from the same issue as the post here: App hangs on restart with latest Flurry SDK and ios4 . I resolved this by setting these optional methods to false, since they take extra time to send data after the app terminates, and depending on the connection it takes a few seconds.
FlurryAnalytics.h
/*
optional session settings that can be changed after start session
*/
+ (void)setSessionReportsOnCloseEnabled:(BOOL)sendSessionReportsOnClose; // default is YES
+ (void)setSessionReportsOnPauseEnabled:(BOOL)setSessionReportsOnPauseEnabled; // default is YES
Hope this helps anyone else who experienced something similar to me!
All apps can enter the background by default. Normally they do not do anything there, but they stay there in a frozen state and when you open them again, your program does not restart, it just picks up where it left off.
Anything that's set as an animation delegate might not get released, since it's retained for that purpose until the animation completes.
You can add an applicationDidEnterBackground: method to your app delegate to get informed when your app is going into the background, but exactly what you need to do depends on the design of your app. You can also add applicationWillEnterForeground: to do anything you need to do differently when restarting, as opposed to newly starting.
You might be able to force your animations to complete by starting a new animation with duration 0.0 (or very short if for some reason you can't do that).
If this happens only if your app goes to bkgnd and comes back AND you don't mind if the app restarts everytime it comes back then just put UIApplicationExitsOnSuspend in your app's plist. In all my cases where these and other bad things happen with apps going to and returning from bkgnd this helped.
While you might still see the app on the buttom when double tapping it is really stopped and will restart. Apps that show on the buttom do not always have to run or be stored in the bkgnd I learned.
ps. don't forget to set the value of UIApplicationExitsOnSuspend to YES
So I׳m trying to play some effects in my Cocos2D game using SimpleAudioEngine , but after I have added them my app crashes when it goes to background (multitasked).
I searched for this problem in the internet but all the solutions that I found didn't work for me. What I did find out is that this problem happens because my app is somehow trying to play sounds when backgrounded.
In console it shows me (which is the same error I found other people had):
sgx error (background gpu access not permitted):
And another thing, when I run my app on the simulator, or even on my device while debugging carefully (going line-by-line with XCode while the app is running) this doesn't happen.
I just had this issue. I resolved it by having a bool to check if the app is running or in background that I set to true when the app goes to foreground ( applicationWillEnterForeground ) and that I set to false when the app goes to background ( applicationDidEnterbackground ) . So using the bool you can tell if the app is in the background and if it is, I just exit out of drawView function in EAGLView (thus not doing any graphics rendering which was causing the error).
I am a very dodge programmer but that method has worked for me and I hope it works for someone else. I did not need to unload and reload my sounds or anything and my app now has Multitasking XD
I was experiencing this, on about 25% of the occasions that my application re-entered the foreground. Like you, when I removed the sounds, the problem went away. That is how I came across your question here.
I may have found a solution to this. I have made what appears to be an unrelated change, but the problem seems to have gone away. Now, when my app enters the background, I invalidate my main scheduled timer. When my app re-enters the foreground, I then re-schedule the timer (after reloading my sounds, which I completely shut down on entering background).
So far, the problem has not come back. I would be interested to know if this helps.
I just resolved this issue on my end. Here's what was wrong in my case and, from what I can tell from the other answers and comments on this page, many other people's case as well:
By default, when I started my project, CCDirector::sharedDirector()->pause(); and CCDirector::sharedDirector()->resume(); were both being called twice, once by (void)applicationWillResignActive:(UIApplication *) and (void)applicationDidBecomeActive:(UIApplication *) respectively in AppController.mm, and once by AppDelegate::applicationDidEnterBackground() and AppDelegate::applicationWillEnterForeground() respectively in AppDelegate.cpp.
Make absolutely sure that these methods are only being called once, in AppController.mm. In AppDelegate.cpp, instead make sure that you are calling CCDirector::sharedDirector()->stopAnimation(); in place of CCDirector::sharedDirector()->pause(); and CCDirector::sharedDirector()->startAnimation(); in place of CCDirector::sharedDirector()->resume();.
Hope that's helpful to anyone else stuck in this crappy situation!
Are you sure it's related to audio? "background gpu access" sounds like it's using OpenGL.
I had the same issue in my application and spent some 4 hours to find out. Going background was OK the first time, but crash application the second time. With a short error message related to OpenGL. I had the same questions: how audio can crash graphics. But it wasn't a question of audio, but a question of notifications...
I discovered that going foreground was creating 2 timers in my custom level meter class.
I had registered UIApplicationWillEnterForegroundNotification and UIApplicationWillResignActiveNotification. Then, going background invalidated only one, since I registered only on notification... That was it!
One need's count its notifications!
I'm doing performance testing on my iphone app and I'm noticing that sometimes a good 3-4 secs elapse at startup before I start seeing my NSLogs from applicationDidFinishLaunching. I've optimized what happens once the code enters applicationDidFinishLaunching but I'm not sure how to optimize what goes on before that. I'm using a Default.png splash screen so it basically just stalls on that screen before it enters applicationDidFinishLaunching and starts doing something.
Just to give you guys some context, I have no nib files and I'm using core animation, if that makes any difference. I have about 10 different controllers and my total bundle size is just under 2MBs.
Try running it without the debugger attached - one of the things it does on startup is wait to connect to your mac ;)
If you just run it in the device without your mac connected do you still see the delay?
I did some experimentation a little while back and found that default start time for most apps is 3 seconds or more.
I was annoyed that the voice memo apps took up to 10 seconds to launch by which time I had forgotten what I was going to say. I tried to write one that would launch faster and by using a default.png and starting the recording automatically I got a recorder that constantly launched in 1-1.5 seconds. To get that launch time, I had to start the recorder before the interface became active.
However, in this research I found that most apps e.g. an app compiled straight from an Xcode template without modifications, launched in 3-5 seconds.
Based on that fact, I would say you really don't have a problem. The startup time falls in the expected range. deanWombourne's observation about the debugger is most likely correct and it probably adds a second or two to your startup time.