Stay Classy, Objective-C: Introducing Native Subclasses for Parse Objects

jawngee · on March 22, 2013

slaps forehead repeatedly

I love Parse, but their iOS devs ... I don't know what the hell they were smoking when they designed their iOS SDK. It's so poorly designed, that they've now introduced this horrible kludge to do something that it should have done out of the gate. A protocol for subclassing? Are you kidding?

ModelKit (http://github.com/jawngee/ModelKit) is an alternative Parse SDK I wrote out of frustration with Parse's offering, with the added bonus of having a swappable backend or no backend at all. I've used it on four shipping projects already. It has the additional benefit of working disconnected as well.

_tggb · on March 22, 2013

You can easily do without a protocol[1] -- NSKeyValueCoding doesn't require a protocol to be implemented anywhere. For example:

  @interface MYObject : NSObject
  @property (nonatomic, copy) NSString *foo;
  @property (nonatomic, copy) NSString *bar;
  @end

  @implementation MYObject
  @end

And somewhere else in your code:

  - (MYObject *) buildMYObject {
      MYObject *object = [[MYObject alloc] init];
      [object setValuesForKeysWithDictionary:@{ @"foo": @"purple", @"bar": @"elephant" }];
      return object;
  }

Then you can access it like a regular property:

  - (void) useMYObject {
      MYObject *builtObject = [self buildMYObject];
      NSLog(@"value: %@", builtObject.foo); // will print "value: purple"
      NSLog(@"value: %@", builtObject.bar); // will print "value: elephant"
  }

There are some gotchas to be aware of here (that Parse likely takes care of, since you're subclassing PFObject), such as setting nil values, or attempting to set the value from a key that doesn't have a corresponding property on your object.

1. It looks like the main benefit to the protocol is compatibility with the existing design of -[PFObject objectWithClassName:], and, I don't know enough about Parse to say what that does. But, I bet its nifty.