how to handle error in an iphone app ?
log and exit ? show an alert dialog and exit ?
for exemple, if an image is missing from the bundle..even though it should not ...
You are never supposed to exit the app programmatically. Advise the user there was a problem, offer to try it again, etc. But don't kill the app. This is explicit in the Apple HIG.
Let the user decide your app needs exiting. Don't do it for them.
Ideally, don't get yourself in this situation. : ) Easier said than done I know.
#Genericrich has it pretty spot on:
Advise the user there was a problem, offer to try it again, etc. But don't kill the app. This is explicit in the Apple HIG.
The only advice I would add is to expect the unexpected. Just make sure your app is ready for those little blowups. This might be things like: default information to fill in the blanks, adequate alerts to let users know what's happening/retry, saving state before attempting failure prone destructive actions, and any other defensive programming habits you can think of.
As an added note if you are wanting to test network errors you may want to check out Craig Hockenberry's excellent post Slow ride, make it easy on the subject.
Alert box and exit should be fine. Short and sweet with just enough communication with the user to let them know why your software is about to not work.
Related
I know quite a few questions have been asked around this topic; however, am penning this as they don't seem to specifically answer my question, & some don't have any correct answer listed.
What I want to do in my iPhone App
Fetch some data when the App is not running (basically, it's a prefetch, so as to quicken it when the user uses the App the next time). What's the best way to do this?
Some Potential Solutions
Those that I could think of & some from Stackoverflow & such resources:
Possibility 1 : Fetch the data at a specific time of the day (maybe after midnight ?). Am not seeing 'clearly' how to do this if this this possible in the first place. Some suggest using a NSTimer -> but the timer is put off when the application is suspended, right?
Possibility 2 : Using local notification (?) But I see that Apple's documentation specifically mentioning that notification is to be used to convey something to the user & so this would defy Apple's doc then, right?
Possibility 3 : Through applicationDidEnterBackground -> beginBackgroundTaskWithExpirationHandler . This wouldn't run the fetch at a specific time of the day though. However, it might serve its purpose of 'pre'-fetching. Is this better than the other two?
Any thoughts please?
as you already know that none of the option you have presented are not going to work with ios and user can always close the background applications anyway so I would suggest that it'd be a good idea to fetch the data for next calendar day whenever the app is running.
As samfisher is saying none of your specs. fit with the Apple active background requirements. The only thing that I can suggest you is to use the beginBackgroundTaskWithExpirationHandler I understand that is a "post fetching" instead of prefetching but I guess is the only way.
The other way, but is a little bit trickier, is masquerade your prefetching with some sort of geolocation, in this way you could opt for an active background. This involve a lot of aspects such as:
Appstore rejection
Battery consumption
There are plenty of app on the appstore that use this trick, I can remember one that calculate data traffic.
Say you are doing something critical to the app's usability at startup (like copying the SQLite DB or setting up CoreData) and something goes wrong that doesn't cause a crash but you don't want the user to continue. What can you do?
Currently my app has abort() and NSAssert(false,...) calls to make sure the app doesn't continue, obviously after the error has been logged. But somehow I think its not going to score points with Apple on the app store.
Anyone have any ideas what I can do in such situations? I understand for instance that if there is no connectivity you can put your app in 'offline' mode but lets say the DB couldn't be properly setup (for argument sake). There is no 'offline' for that and so the user cannot continue. The user needs to quit the app and try again or report the problem. Wouldn't you agree, or am I missing something?
I just decided to create a view that has a message on it explaining to the user that a critical error has occurred and explained some steps to follow to resolve it. It prevents the user from using the app until it is resolved. So if the DB is missing or the model schema doesn't match the DB schema it will bring up that view.
Its one way of doing it that I took. If anyone has a different way, I'd like to hear it.
I'm working in an application that loads a few remote jsons at startup. The application has been programmed to do certain tests on the incoming data to prevent invalid states and to detect possible human errors. However, I am not sure of how we should treat such situation at the GUI level - our initial idea was to display a "Oops there was an unexpected server error. We are working to solve this issue. Please, try again later." popup to quit the application when the user hits an "Ok" or "Exit" button.
Apple apparently discourages exiting the application from within your code: https://developer.apple.com/library/ios/#qa/qa2008/qa1561.html
What good alternatives are there to handle this situation?
Update: I updated the error message above, since it was misleading.
I encountered a similar issue. My app was useless unless it could establish a connection to a server.
There are two ways around this:
place holder text, this can hold the position until you can get your json arrays, or at least allow a back drop for popping an alert.
Load a view with all interaction disabled, with a small message box saying "connecting..."
Basically I have taken the first responding storyboard frame and disabled everything that the user could touch. I just allowed static interaction like pressing a button to get to the about screen.
Don't beat yourself up too much about it though. If you don't have any connectivity at all then none of the user's apps are going to be functioning properly. I think in this state, from a GUI perspective it is mostly about damage control and protecting the user experience.
It's tough to be graceful at startup. I suggest presenting UI modally while your app gets ready to run. I asked and answered this SO question which shows a clean way to do the UI, including nice transition effects.
As for exiting: Your app should never self-terminate (copyright Arnold Schwartzenegger circa 2003). The correct app behavior when it can't get something done that has to be done modally is to alert the user and give the option to retry. If the user wants to not retry, there's a hardware home button on the phone.
I've decided to integrate OpenFeint into my new game to have achievements and leaderboards.
The game is dynamic and I would like user to be rewarded immediately for some successful results, but as it seems for me, OpenFeint's achievements are a bit sluggish and it shows visual notification only when it receives confirmation from the server.
Is it possible to change something in settings or hack it a little bit to show notification immediately as soon as it checks only local database if the achievement has not been unlocked it?
Not sure if this relates to the Android version of the SDK (which seems even slower), but we couldn't figure out how to make it faster. It was so unacceptably slow that we started developing our own framework that fixes most of open feint's shortcomings and then some. Check out Swarm, it might fit your needs better.
There are several things you can do to more tightly control the timing of these notifications. I'll explain one approach and you can use this as a starting point to explore further on your own. These suggestions apply specifically to iOS apps. One caveat is that these suggestions refer to internal APIs in OFSDK 2.8 for iOS and not ordinarily recommended for high level use and subject to change in future versions.
The first thing I recommend is that you build the sample app with your own product key. Use the standard sample app to experiment before applying the result to your own code.
You are going to get the snappiest response by separating the notification pop-up UI from the process of submitting the achievement. This way you don't have to worry about getting wrapped up in the logic for deciding whether the submission is going just to the local db or is doing the full confirmation on an async network transaction.
See the declaration of "showAchievementNotice" in "OFNotification.h". Performing a search in the sample app, you will see that this is the internal API used for displaying the achievement pop-up when an achievement is earned. It does not actually submit the achievement. You can call this method directly as it is called from "OFAchievementService.mm" to directly control when the message appears. You can then use the following article to disable the pop-up from being called when the actual submission occurs:
http://support.openfeint.com/dev/notification-pop-ups-in-ios/
This gives you complete freedom to call the submission at a later time provided you keep track of the need to do so. For example, you could locally serialize a flag to take care of the actual submission either after the level is done or the next time the app starts up. Don't forget that the user could quit out of a game without cleanly finishing a level.
I'm trying to make a general error handler for an iPhone app that brings the user to a recovery screen whenever any general error is thrown in the application without putting a try/catch block around every single method in the application.
Using NSSetUncaughtExceptionHandler doesn't work because the application terminates after the handler is run.
Is there any way to change this behavior, or use any other handler that will catch exceptions in general and not cause the application to exit afterward?
And please, no non-answers about whether it's a good or bad idea.
The original poster has probably solved his problem by now. However, for anyone who comes across this in the future...
Matt Gallagher wrote an excellent post on catching unhandled exceptions and signals a few months after this question was posted. I find it to be much more informative than the answer referenced above by Scott.
In particular, Matt's post describes how to attempt a recovery (if appropriate) that allows your app to keep running, and even displays a UIAlertView with error information if you want (hint: it involves creating a new run loop).
This was answered here. You can read more about the responder chain and catching the exceptions here. The write up from 1 is really good and explains how to deal with what you are doing.