- Launch the application
- Minimize the application
- Turn airplane mode on
- Return to the app
- The app crashes
If this is happening to your application you may be wondering what exactly is going on here. How do you check for Airplane mode?
Well in that statement we just asked a mouthful – so let’s start breaking it down and looking for fixes. First let’s discuss the root cause.
In this case the root cause is that you are performing a network call or operation when the network is severed. There are several things that come to mind here.
When an application goes into the Pause mode – what exactly are you doing with any open or pending network calls. Theoretically you should be stopping or putting these calls into a waiting mode. When the application resumes or starts, you should always recheck the current connectivity state of the application. This will ensure that if any changes were made between the pause and resume states, your app will be able to handle them gracefully. Occasionally I have seen examples where the Start function will check the network connectivity, however the resume functionality will not.
This leads us to the next segment… how do you check the network availability. The preferred was is to use the Apple Reachability library. That library can be found here: https://developer.apple.com/library/IOs/samplecode/Reachability/Introduction/Intro.html
With that library is a really nice reachability demo. They have sample code to enable you to check against 3G, Wifi, etc.
Using the library add appropriate routines into the start and resume events for your application. Just to re-iterate, we like to treat a resume activity almost as if the user is completely restarting any network calls… but that is up to you.
The last segment to touch upon is error catching. There may be a case where you are interacting with a network connection and the user simply looses connectivity. What then do you do? Will your application hang waiting for a response?
Keep in mind that if a process hangs for 20 seconds, apple will kill it. So if your thread is waiting on a network call for more then 20 seconds then it is subject to getting killed. Good design will suggest that you should send any long network calls to the background so as to make them asynchronously and not synchronous.