Yfactorial ObjectiveResource

Comments and changes to this ticket

• 

  Joshua Vickery December 19th, 2008 @ 07:18 AM

  Thanks greenisus!

  This is good, something I've been meaning to add in some way.

  I'm not wild about the amount of HTTP logic it places on the hands of the calling code though.

  I had a few thoughts on how to handle this in a more abstracted way.

  1. Throw exceptions (blech, I know, but perhaps it's better than having to pass another variable by reference. we could make it configurable)

  2. Display iPhone alert messages (this would have to be configurable)

  In the same code, a status code of "0" is checked for. This is what happens if an NSError is returned, so it would make sense to check on that as well.

  This is functionality that we don't have, shall we pull it in, or try to abstract it a bit more?

• 

  Joshua Vickery December 19th, 2008 @ 07:24 AM

  One more comment, the way that we currently handle connection errors in our code is to check for a nil response to the finders, and the BOOL response to the create/delete messages.

• You flagged this item as spam.
  

  jjburka December 19th, 2008 @ 09:52 AM

  I'm not a big fan of passing parameters by reference , but like you said its functionality we don't have. I guess my question is what do we plan on using this functionality for? Is it for error checking or just to send an alert to the user? If its the later, I would think something like notifications or a delegate protocol would feel more objective-c.

• You flagged this item as spam.
  

  Mike Mayo December 19th, 2008 @ 12:19 PM

  Thanks guys! I'm not crazy about passing by reference either, but that seems to be the pattern followed by Cocoa for using NSError. In fact, you're doing it in Connection.m and doing nothing with the NSError. When I started this change, I was doing it with NSError first, but I'm still pretty new to Cocoa (I'm more of a Ruby guy), but since I don't know much about NSError, I went with what I know: HTTP status codes.

  As for throwing an Exception, that would seem natural to me, but I kind of went with Apple's recommendations on error handling with is return a BOOL and pass an NSError object by reference :\

  As for showing the alert automatically, that's exactly what I did in the Connection class as a quick fix so I could resubmit my app to the App Store. But I'm doing lots of requests, so it really can't work that way in the long run (at least in my case).

• 

  Joshua Vickery December 19th, 2008 @ 05:54 PM

  My reading of Apple's Cocoa docs do suggest that returning an NSError indirectly would be preferable to throwing exceptions.

  Mike, would you be willing to update your branch to indirectly return NSErrors instead of the Response objects that it returns now?

  Maybe you could add the logic needed to determine if a Response is an error to Response.m? The start of that is already there on line 27:

  - (BOOL)isSuccess {
    return statusCode >= 200 && statusCode < 400;
  }
  
  

  http://github.com/greenisus/obje...

  Finally, if you do make that change, would you mind updating the methods that don't accept an indirect return NSError to call those that do? Something like:

  + (id)find:(NSString *)elementId {
     NSError *error;
     return [self find:elementId withResponse:&error];
  }
  
  
  + (id)find:(NSString *)elementId withResponse:(NSError **)error {
      Response *res = [Connection get:[self elementPath:elementId] withUser:[[self class] getUser] andPassword:[[self class] getPassword]];
      if ([res isError]) {
        error = [res error];
      }
      return [self fromXMLData:[*res body]];
  }
  
  

  This would cut down on duplicate code.

  I think with the above changes this would be a great addition to the project.

• You flagged this item as spam.
  

  Mike Mayo December 19th, 2008 @ 06:48 PM

  I agree with you. I would have done NSError in the first place, but I was just in such a rush to resubmit to Apple.
  

  I'll add that some time this weekend :)

• 

  Ryan Daigle December 29th, 2008 @ 11:18 AM

  (from [04b7eb658df5a7e315a4baf0ac78f4c16480ee81]) [#6] NSError added to response http://github.com/yfactorial/obj...

• 

  Ryan Daigle December 29th, 2008 @ 03:49 PM

  (from [bbb148dbd8e3294f1f7dacd39a92aaab65bdd581]) [#6] handle 401 http://github.com/yfactorial/obj...

• You flagged this item as spam.
  

  jjburka January 12th, 2009 @ 04:41 PM

  • State changed from “new” to “resolved”

  implemented