I added a managedObjectContext save to my applicationDidReceiveMemoryWarning method in the app delegate. The app seems to crash on some devices when I receive a memory warning now.
It seems that the save pushes the app over the memory limit, as it is already low.
The reason I have this save in that method is to catch anything that may not have been saved during normal app operation.
Can someone tell me if this is bad practice?
Thanks.
Related
When an app crashes does either the 'applicationWillTerminate' or 'applicationDidEnterBackground' get called or am I hoping for too much?
Apple's documentation states "This [applicationWillTerminate] method lets your application know that it is about to be terminated and purged from memory entirely". When an app crashes it gets "terminated and purged from memory" right? So does that mean it gets called?
This is all in relation to the iPhone and iOS just to be stupidly clear.
When an app crashes, it usually gets killed immediately.
No delegates or methods or delegate methods get called after that, since the being-killed app is probably in a really bad state and whatever data you might want to write out could be corrupted and non-usable.
So, I have an app that runs an HKObserverQuery in the background. We take data from HealthKit and push it up to our server for further analysis.
When we do an app update, however, we usually see a spike in requests made to our server. It usually times from when the app becomes available in the store, and usually dies down a few days later.
My question is - when an app is updated, does it try to resume a particular state or something after the installation occurs? Our data fetch/upload process is called in applicationDidFinishLaunching, and my only hunch is that after the update occurs it tries to resume a state, thus invoking that function.
Any insight in to this would be real helpful. Thanks!
EDIT: my curiosity exists because I can't imagine all of our users opening the app after an update occurs, especially the auto-updaters. So my question revolves around if iOS attempts to load the app after installing an update to verify it, henceforth calling applicationDidFinishLaunching, but without bringing the app to the foreground.
I have implemented iOS App, In that if we get any unknown crash i want to show one message like "sorry some thing went wrong". Meanwhile the App did not close. It still open if we get crash. Its a requirement from client.
Short answer: This is not a good idea and should be avoided at all cost. Convince the person who provided that requirement that this should not be done.
Long answer: When your app crashes, this means something went horribly wrong. It got into a state where nothing can be guaranteed any longer and it is better (even for the app user) to quit the app right away. The reasons for a crash could be:
an unhandled error
you are trying to access some memory that you don't have access to
accessing memory that is already de-allocated, but your app code thinks it is still allocated to a specific object
and many many more reasons
For the first case you could setup unhandled error handlers across your app or globally; this is what crash reporting SDKs do. For the other reasons you need to set up signal handlers (or even Mach exception handlers) to get those. One rule in those cases is that at crash time you should NOT allocate new memory, simply because you have no guarantee that will work or would not overwrite memory used by other parts of your app which then could cause major corruption of the user's data, or deadlock the device which means the device owner has to restart it.
Not being allowed to allocate any memory at crash time means you can't use any Swift or Objective-C code, because allocating a new object WILL allocate new memory. And showing an alert will just do that as having the app continue to run will do as well. You can only use a subset of (async-safe) C methods at crash time!
So the end of the story is:
detecting a crash is hard
not causing possible damage to user data after a crash is even harder
guaranteeing the app will continue to run without causing damage to user data or being usable to the user at all without more problems is in the area of luck
If the operating system decides that your app should exit (crash) because of such an unsafe scenario, you as an app developer should not decide otherwise.
Likewise that have functions in Objective-C to know when the screen will Appear, or When the User exit the app, or receive memory warning, I believe there is a way to know when the device will give crash.
If this function exists, I could create an alert will notify the user that the application has an error and the logs would be sent to my email, I wonder if this Possibility exists?.
Grateful.
like every POSIX process, iOS apps receive signals when they're crashing. thats how test flight works.
a) for exceptions use the function NSSetUncaughtExceptionHandler
b) for a signal handler (other crashes then exception) use signal
I won't write all the code here but for further info Ill refer to:
http://www.cocoawithlove.com/2010/05/handling-unhandled-exceptions-and.html
BUT
I would just try to avoid crashing because a handler often isn't really useful and it can very well be tricky to implement a signal handler because everything CAN be in a corrupt state. For example it may well corrupt your CoreData database or user defaults.
Don't ship it I'd say :)
When I save a single datum to the iCloud, it works fine and when I need to save number of data to iCloud, I put the same code steps to save inside the for loop.
When I tried saving number of data to iCloud, the following signal is received and the app is hanging infinitely. The signal received area is in the below image.
and the crash area points at
How I can debug this crash? Can someone help me with explantion ASAP
The documentation for that method says, "Important: Do not call this method from your app’s main thread." The warning goes on to say that doing so may cause a deadlock. It sounds as if that's the condition you have.