1

I am working with an app that is powered by data fetched from a server. The fetching logic is fairly robust and fault tolerant; most connectivity errors are automatically retried, which usually works great. However, given a very rare set of circumstances (which include a race condition involving network latency and the backend database), it is possible for the app/server to get into a inconsistant state which cannot be recovered from.

What I would like to do is have the app, when in this state, simply terminate the next time the user presses the home button (instead of going to the background). The app, when relaunched, would re-sync with the server and the user would go about his/her merry way.

My first thought is to call exit() from applicationDidEnterBackground when the inconsistant state is detected. Does anybody have any experience with this sort of thing or know of another way to disable backgrounding on a conditional basis? I understand this is frowned upon, does anybody have experience with Apple explicitly rejecting an app by detecting the use of exit()? UIApplicationExitsOnSuspend = YES isn't an option since multitasking needs to work as expected the other 99.999% of the time.

Note: my apologies for the lack of specifics. The ideal solution is to come up with a way to recover from the inconsistent state; trust me when I say much time and effort has gone into figuring out a way to do so.

James J
  • 6,428
  • 6
  • 35
  • 45

1 Answers1

2

Using exit() is highly discouraged by Apple, per their Technical Q&A QA1561:

WARNING: It is possible to quit the application by calling exit. Applications calling exit will appear to the user to have crashed, rather than performing a graceful termination and animating back to the Home screen. Such usage provides a negative experience and is strongly discouraged.

Use of exit() should show up as a crash, like a failure in an assertion would. If a reviewer hit this condition while testing your application, odds are that it would be rejected.

However, if this is a very infrequent case you could roll the dice and hope that the reviewer would never encounter it. It's a gamble, and you may be able to get away with that, but I don't know if that's the best plan of attack.

If you can identify this inconsistency, I can't see why you couldn't wipe all in-memory stores and effectively start things from scratch, as you would on a fresh boot of the application. I had a rare case where my Core Data database would become inconsistent due to an undo / redo / undo cycle, and this is what I did to recover from that.

Brad Larson
  • 170,088
  • 45
  • 397
  • 571
  • Unfortunately it's not just the data on the device, but a combination of data on the device and server that is the culprit. There are other clients of our backend, making changing the API a tricky proposition. The tech Q&A you posted pretty much echoes the HIG regarding the use of exit(). Ours is an interesting case, however, since we want to use exit() after the user has hit the home button - they expect the app to close and it would. – James J Dec 31 '10 at 22:36
  • 1
    @jenningj - If the inconsistency develops both between the client and the server, why would restarting the application from scratch fix the issue? If restarting makes this go away, it would seem that you could replicate that effect within the application when an inconsistency was detected. As far as the exit goes, even though the application appears to exit as normal, I believe a crash log would be generated, which might raise a flag with the reviewers. Again, they may not notice this, so you might be able to gamble and see if it gets through. – Brad Larson Jan 01 '11 at 03:19