An Interesting Approach to handling NSNulls in JSON objects

I was the lead developer of the Lot18 app – Lot18 is an e-commerce wine marketplace. In that role, I used the web REST interface to retrieve product, inventory, and reviews.  While processing thousands of different objects I’d occasionally stumble on a crash or UI anomaly caused by a NSNull null object buried deep in some dictionary or array.

My first approach to deal with this was to created mutable arrays and dictionaries, and walk the full tree, looking for dictionaries. It worked, but just kept getting more and more complex, and at some point you realize you’ve taken the wrong approach.

The light bulb went on, and I found a method that really worked well: add a category to NSNull. Thinking about it, the issue wasn’t the NSNull null per se, but the methods that my UITableView code would throw it at: asking for a count, or a property, or a value. A prime example of this was inventoryCount. If a product had entered stock, the number could be anywhere from negative (yeah! had to deal with that in a crash!), zero, or some large positive number. However, if the product had not been stocked at least once, the return was a NSNull null object.

So, my approach was to create a NSNull category and essentially deal with any odd method, and return a sane value:

@implementation NSNull (JSON)
- (NSUInteger)length { return 0; }
- (NSInteger)integerValue { return 0; };
- (CGFloat)floatValue { return 0; };
- (NSString *)description { return @"0(null)"; }
- (NSArray *)componentsSeparatedByString:(NSString *)separator { return @[]; }
- (id)objectForKey:(id)key { return nil; }
- (BOOL)boolValue { return NO; }

There well may be other methods that need to be added to this list, but the above was sufficient for me. Note the returned description string – it makes it clear when NSLogging objects that the value was NSNull null.

[ Note that this post was extracted from an earlier StackOverFlow answer.]

5 thoughts on “An Interesting Approach to handling NSNulls in JSON objects

  1. Interesting! But messing with the NSNull class perhaps could lead to other libraries or other part’s of your code to behave in a different manner it should, couldn’t it?

    I haven’t tested it, but at least I assume that this implementation would still respond correctly to the test: [object isKindOfClass:[NSNull class]]

    the “common” NSNull verification, right?

    So it’s not that dangerous (i think).

    Nice approach, will try to use that sometime.

    • It would only lead to other changes in the since that if another class tried to get the “integerValue” of the NSNull singleton, where as before it would cause an exception, now it would silently work. This is IMHO an extremely unlikely scenario. If you were really concerned about that, create a new class method that turns on and off some static flag, and if the flag is set, work, otherwise fail. You could probably do this in “respondToSelector” – not sure have to think about it.

      In response to your second question, the object will still declare itself a NSNull instance, so that test will still work properly.

      I’ve posted this same code to StackOverflow, lots of people have adopted it, no reported problems yet.

  2. Pingback: ios4 (useful links today) |

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s