SITUATION I am trying to figure out the best practices for error handling with the parse.com iOS SDK. I have read the parse docs and they do a great job of documenting how to check for connectivity to parse and if objects can be found, but my question would be what do I do then?
EXAMPLE
[object saveInBackgroundWithBlock:^(BOOL succeeded, NSError *error) {
if ([error code] == kPFErrorConnectionFailed) {
//COULD NOT REACH PARSE
//SO WHAT NOW?
}
else {
//EVERYTHINGS COOL
}
}];
SO WHAT NOW? Am I supposed to have this on an NSTimer and fire this off again in 5 minutes to see if we can reach parse then?
If saving objects is as important as it seems to be for your case, then this could be a solution, instead of using an NSTimer:
In the SO WHAT NOW? block, just call the method that saves this object recursively. If you ever get an error other than ConnectionFailed you could handle that appropriately, but if you're just worried about saving this even if the first attempt fails, this could be a way.
Related
Avoiding data loss is a critical issue in my application. So I need to save early and often to ensure minimal loss and immediate notification if anything goes wrong.
Unfortunately this results in a lot of if (![context save:&error]) { handling all over the place. To clean this up in a more centralised way I thought to implement an NSManagedObjectContext category with a method such as this:
- (BOOL)saveNotify:(NSError **)error
{
NSError *saveError;
if (![self save:&saveError]) {
NSDictionary *userInfo = #{#"error" : saveError};
[NSNotificationCenter.defaultCenter postNotificationName:NSManagedObjectContextSaveErrorNotification object:self userInfo:userInfo];
if (error != NULL) *error = saveError;
return NO;
}
return YES;
}
Now I can listen for the notification in a more general way and throw up an alert to the user if the save has failed for some reason.
Is this a good approach or is there a better way to deal with this?
A secondary issue is what to actually do when this does occur. Asking the user to exit the app and restart is a bit convoluted these days as they need to close the app through the task switcher.
That'll work for notifying users of save errors. But there are a couple of things to keep in mind:
The message in saveError may not be comprehensible to users. You probably shouldn't present it. Instead, look at the error code and domain and try to present something that makes more sense.
You'll need to try and work out potential errors and likely solutions. Telling users to force-quit the app is unlikely to help if, for example, the persistent store has become corrupted or if the device is out of space. Most save errors will be things that come up during development, if you're testing thoroughly. Things like validation failures or missing required values.
I am trying to find out whether my core data database is accessible in the background when I try to perform some operations.
For this,I am trying to call the saveContext and checking the error object.
[[PersistantStoreManager sharedInstance] saveContext:^(NSError *error) {
if (error) {
NSLog(#"Error is %#",error);
}
}];
But I am not sure about the exact error code that system throws when the database is not accessible?
Can anyone please help me proper error code for this?
Is there any other way to know whether data database is accessible or not?
I am developing an iOS application with Rubymotion which worked pretty fine until i added a new UIViewController. I have added the controller via xcode and have got just a UITextField as an element in it. On running the simulator and on displaying this particular scene, I get an instance of NSError. I also dont see the UITextField element in my screen.
Can any one please explain as to what it is and how do i handle the NSError and make sense out of it?
Any help at this point would be of great help.
UPDATE: I am getting the NSError instance every time my app is launched first, no matter what the controller is. I had upgraded to Xcode 5.1 yesterday. Wonder if that has something to do with the error.
UPDATE 2: This was result of a confusion on my part. I had assumed the NSError to have been raised after upgrading to Xcode 5.1 and thought it was some bug. The reason being was that I had had started using push notifications at the same time as I had upgraded to 5.1. As push notifications don't work in simulators, the NSError was being returned by the simulator. Messed it up big time and spent quite a few hours trying to debug this problem.
NSError is a class and it is used as the preferred way to handle errors in objective-c. Usually it works like this:
You declare a NSError pointer and sends the address to that one in as a parameter to a method that might fail. If something goes wrong in the method a NSError object is created and populated with info about the error and when the methods returns you can check the error object to se if anything went wrong.
NSError *error;
[someObject someFunctionWithParam:paramOne andError:&error];
if ( error ) {
// Here you can inspect the error and act accordingly
NSLog(#"%#", [error localizedDescription]);
}
If you are the one implementing a method it usually looks something like this.
- (void)someFunctionWithParameter:(NSString *)argOne andError:(NSError **)error {
// something goes wrong
*error = [NSError errorWithDomain:#"SomeDomain" code:500 userInfo:#{#"infoKey": #"some info"}];
}
So about the title of your question. There is no catching NSError's since they are not thrown. Only exceptions are thrown.
I am using the following:
Firebase *fb =[[Firebase alloc] initWithUrl:url];
[fb setValue:d withCompletionBlock:^(NSError *error, Firebase *ref) {
if (error) {
// bad news
} else {
}
}];
This seems to work great IF you have a connection, if not it seems the callback is never called. If that is the case do I then need to wrap this whole thing in a connectedRef? Seems like alot of extra work when I would guess the completion block would just fail with an error status of not online.
Anyone else having this issue?
The idea behind Firebase is it synchronizes data for you. It's more than just a simple request / response system. So if you do a setValue while offline, Firebase will hold onto that data until you are online, and then it'll do the setValue at that time (and then the completion block will be called).
So the behavior you're seeing is expected. If you only want to do the setValue if you're online, then yes, you'll need to use a .info/connected observer. But you could still run into issues if for instance you go offline at the moment you try to do the setValue or something along those lines. In general it's better to just do the setValue and let Firebase take care of it for you.
I'm building a turn based game kit application and I'm saving and retrieving data using:
saveCurrentTurnWithMatchData:jsonData completionHandler:^(NSError *error)
loadMatchDataWithCompletionHandler:^(NSData *matchData, NSError *error)
I Get all the matches using this:
[GKTurnBasedMatch loadMatchesWithCompletionHandler:^(NSArray *matches, NSError *error) {
and save each of the matches to an array and call the laodMatchData method when I need it. The problem is that the completion handler never returns anything. I guess it's stuck gettings the data and never gets back to me. It loads sometimes but more often than not, it just keeps loading.
Am I missing something?
The problem was with iOS7 beta 1. The problem is solved now.