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 :)
Related
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.
I'm writing an app using Parse which saves data to the server over a connection with unknown stability. As such I'm using saveEventually.
I'm trying to deal with the situation where the app is minimised, and then terminated by the system before a save is complete. The trouble is, when
opening the app afresh, I issue a logout command, since users are required to log in. It appears that this logout command can overtake the save commands, removing the session from the server, causing the queued save commands to fail. (I also can't see any way of handling these failures after an app restart, since I don't see any delegate based handlers, and blocks are cleared.)
I can't see any user-facing solutions to this either, since there is no guarantee when saveEventually might decide to run, and I can't block the user indefinitely.
Has anybody dealt with this? Any suggestions are most welcome.
I am working on an app that, among other things, provides alarms in emergencies. Users can toggle a setting to have alarms be put through even if their iPhone is muted, but this service has another hurdle to leap: when the app has been force quit, it cannot receive (content-available) notifications until the app is relaunched by the user.
There is a geofencing event in place which buys me some processing time even if the app has been force quit, and in that time, I would like to check if such a block is in place, and if so, request the user to open their app again, and not aggressively force-quit in the future. (Many people still think it's just a way to keep things clean, even though it actually costs you battery life to not just leave apps in the background)
SO THE CORE OF THE PROBLEM: I need an (API call? Something else?) that will tell me whether the app is in such a 'force quit, cannot receive notifications' state, assuming that I do have processing time to do this check.
Anything is welcome, I have not been able to find proper Apple documentation on the notifications block.
Thank you very much.
While there is no API I am aware of to find state after, you can infer the state just before the application is terminated, and record that.
Code
applicationDidEnterBackground
will be called when an app has received a terminate signal.
More Info
This question describes what lifecycle functions to use, and
i have database in my app and i want to delete all information from database when user force quit from app. I looked this question Which Event When i close app in iOS? , but when the user click home button, app has force quit in applicationWillTerminate.I don't want to close my app. I just want to catch close event in my app.
Sorry for my bad english.
Thanks for advice and interest.
the OBJC runtime will shut down without any final notification
BUT
you can write a posix signal handler to get the signal. but note that since the runtime is already shutting down it is unsafe to do much work here.
see e.g.:
http://chaosinmotion.com/blog/?p=423
You can't. The last notification you get that you can be sure of is a didEnterBackground when you get switched to the background. After that, you will likely be killed silently, either from memory pressure or from the user force-quitting you.
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.