In in my app, say it count downs to something and at the end just beeps forever until the user quits the app, is it safe to say have an NSTimer and never release (or in NSTimer's case, invalidate it) it, since it will need to stay until the user quits the app?
Technically, yes, but I've found two things to be true:
This is an easy habit to get in to, convincing yourself that X doesn't need to be released because you've convinced yourself it needs to live forever when it doesn't and leaks, or
At some point in the future you'll realize you really want to be able to control that timer after all, and setting up the ivar now will save you a heap of trouble down the road (no pun intended)
Yes you can! If I were you though, I would initialize it in the app delegate, in applicationDidFinishLoading and invalidate it in applicationWillTerminate.
Related
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.
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
In my Universal-App i have some issues where the app crashes. I could not reproduce the cause of the crash so i want at least make the app "save" so that it can restart again if it has crashed.
Problem is, if my app crashes, it can happen that it cannot be started again due to some messed up user defaults.
So, if i could delete my user defaults after my app has crashed while starting, the user could at least use the app furthermore.
So far for my goals. Now i only need to know how i can detect and save it, when my app has crashed during starting.
My first intention was to set a flag in user defaults when the app crashes and then ,if the flag is set, to reset the user defaults. But i don't know if - (void)applicationWillTerminate:(UIApplication *)application
will be called when my app crashes. And even if it is called. How can i detect if it crashed during starting?
Any suggestions would be welcome.
Greetings and thx in advance
Maverick1st
What about setting a flag every time your app starts up and unsetting it when it terminates normally? That way you know if it is already set when the app starts, it crashed last time.
One of the things about abnormal exit is that is going to be, well, abnormal. It's usually not a great idea to rely on being able to do anything sensible in such cases.
Instead of trying to set a flag when you crash, which will at best be unreliable, how about instead setting it when you start and then unsetting it when you exit normally? That way it'll be left set if you haven't cleaned things up and you'll know next time you start.
One thought... wrap your main starting code in your app delegate in a #Try #Catch block to handle the exception causing the crash. Perform any last minute code there (like setting your flag).
In my app user can take as may picture from camera, so after three time taking the picture it crashed. I can't resize the image (its requirement). So is there any other way to avoid memory leak.
Thanks
There is a know issue with the uiimagepickercontroller with memory leaks.
Apple recommend that you only allocate and instantiate only one instance and store it somewhere for the life of the application (whilst running that is).
Don't create a new one, use it and deallocate it each time you want to
use the control. If you do, your memory usage will keep increasing
until it crashes your app.
Personally I store it as a property in the appDelegate, but there may be a better way of doing it.
Edited: Thanks to CharlieMezak. Yes, such a leak might cause a crash. You'd better do some checking based on CharlieMezak's suggestions.
What may also cause crash is your code trying to access a piece of memory that was deallocated already.
I suggest you first check your code to see if there is any autorelease object that was not taken care of.
Second, turn on NSZombieEnabled, and test your app. If it's indeed trying to access something that was already deallocated (Zombie), the console will show you.
Third, and most importantly, post your crash report and part of the code that might be responsible for such a crash. Your description is somewhat vague, we need to see the report.
It sounds like your app is able to handle the photos correctly (from the user's perspective) two times, but on the third time it crashes. Sounds to me like a memory leak.
If it were a logical error in the code, or an attempt to access a deallocated object, the crash would probably occur the first time you take a photo.
It sounds like you're leaving the images in memory, so by the time you take your third photo, you're out of memory because the first two are still sitting there. Make sure you're releasing what you retain, and if you continue to have trouble, post your code!
Occasionally in low-memory conditions the UIImagePickerController I use gets 'stuck' with the shutter closed. Generally when this the WatchDog is allready jettisoning other background apps so within a second or two the low memory condition is over, yet the UIImagePicker controller is still stuck.
Has anyone else encountered this and implemented any sort of workaround or found a way to detect when the picker is in this state, so that it can be removed and a new one put in its place.
Thoughts / Ideas / Solutions??
Have you tried allocating (and then freeing) a megabyte or two of memory using malloc() before starting the UIImagePicker? Or claim it slightly earlier in your app, and then release it when you want to show the picker.
I guess you should be able to see roughly the amount of memory UIImagePicker needs to run successfully by running your app inside of instruments.
Whilst not ideal, it should cause other apps to be given memory warnings earlier on and hence the UIImagePicker should then have enough memory to run.
That's a known behavior of the camera application too. I guess you can't do anything to it except freeing as much memory as you can before starting it. You could raise a memoryWarning yourself so every application will receive it and start freeing memory but I have no idea how I can do that. I started investigate sending the notification myself (UIApplicationDidReceiveMemoryWarningNotification) without success. I guess we need to send an object along the notification to define the warning level but I'm really not sure.