When I first heard of iOS 5 and applications like News Stand, that could download books in the background, I was well pleased and assumed like many others that my applications could do the same. I was naturally disappointed when reading the Apple Developer documentation that this is not the case and my applications will still be relegated to second class citizens when going into the background and suspended. Apple obviously still values the users experience of smooth scrolling high above the utility of background processing.
As a second-class citizen my app has no rights! Its network connections can be cut, its resources constrained to a trickle, peripheral systems will be informed of its demise and in worst case scenarios will be removed from memory completely. Yes, from iOS 4 onwards I can request some extra background time before being suspended, however this has to be a finite period, the hardware must support it and ultimately my app will be cut off.
This poses a problem for persistent network connections, like those use by the SUP Object API for objective C. If an SUP app gets suspended and network connections cut, the Application object is not informed that it has lost connection to the server so when the app resumes the Application object will think it has a connection when it doesn’t!
The best way to prevent this from happening is following the method described in the SUP documentation Managing the Background State.
Who knows what iOS 6.x and the multi-core ARM processes will bring to the mix, but for now handling the background state elegantly with the above method will ensure your SUP iOS apps behave.
