Updated nullability annotations and return types for synchronous methods on PFObject.

[nlutsenko]

If these methods fail - they will return nil, which makes them nullable - annotate accordingly.
Also - replace more instances of direct class names with instancetype.
Thank you @adonoho for noticing!

[grantland]

LGTM

[adonoho]

One question: do the headers and the implementation have to match? All of this pull's fixes relate to the headers and not the implementations. For example, I've had repeated problems subclassing PFUser. I no longer try to do so. Could the change just committed to the header returning an instancetype instead of a PFUser * contribute to solving this difficulty?

[nlutsenko]

I think PFUser in a good state now, but would love to hear what specific problems you are running into.
Most of these are already using self or self class as a reference, but you are right - we need to change the implementation declaration as well here.

[adonoho]

Here's how I use PFUser. Because Swift is still wonky with both Parse's PFUser/PFObject and Core Data's NSManagedObject, all of my model classes are defined in Objective-C. My Swift code is an extension on the Objective-C class. Every time I start a new Parse project, I try to subclass PFUser to my own User class. Until something weird happens with my User class, then I just revert to using PFUser as a dictionary-like object. I spoke with some of your staff at F8 in March. They copped to the fact that PFUser was difficult to subclass. As a result, in my latest project, I don't subclass PFUser. This is regrettable for such a simple subclass. I only put a single relation on PFUser.

For your edification, here is the header for my User subclass:

#import <Parse/Parse.h>

extern NSString *const kUserEntity;

extern NSString *const kUsername;
extern NSString *const kPassword;
extern NSString *const kEmail;
extern NSString *const kSessionToken;
extern NSString *const kObjectId;
extern NSString *const kUpdatedAt;
extern NSString *const kCreatedAt;
extern NSString *const kACL;

// User properties.
extern NSString *const kLocations;

//@interface User : PFUser <PFSubclassing>
//
//@property (nonatomic) PFRelation *locations;
//
//@end

Implementation:

#import "User.h"

NSString *const kUserEntity = @"User";

NSString *const kUsername = @"username";
NSString *const kPassword = @"password";
NSString *const kEmail = @"email";
NSString *const kSessionToken = @"sessionToken";
NSString *const kObjectId = @"objectId";
NSString *const kUpdatedAt = @"updatedAt";
NSString *const kCreatedAt = @"createdAt";
NSString *const kACL = @"ACL";

// User properties.
NSString *const kLocations = @"locations";

//@implementation User
//
//@dynamic locations;
//
//+ (NSString *) parseClassName {
//
//    return @"User";
//
//} // parseClassName()
//
//@end

It doesn't get much simpler than the above subclass. As I use Parse as my "cloud truth DB" and not my operational/UI DB, not having a proper subclass doesn't affect me in many places in my code. I can live with it; but it annoys me to not have a uniform pattern to access my cloud object model.

The above doesn't answer your question. Frankly, this decision occurred at the beginning of the year after I ran into some login difficulty. I don't remember exactly. Reverting to the dictionary form eliminated the problem. IIRC, this was in the v1.6.x version era. I did not try with either v1.7.x or v1.8.x. Now, if you've really done things to improve the situation, I'm willing to try to subclass PFUser again?

[nlutsenko]

It was improved constantly and should work and is definitely a supported use case. The only piece of feedback that I have about the code above - don't overwrite parseClassName on a subclass of PFUser. PFUser already implements that method, since it conforms to PFSubclassing. And overwriting this piece here would potentially break a lot of things.

Last piece to note, though I think you are aware of this: any subclass of PFObject should be explicitly registered by calling [User registerSubclass] anywhere in your app before you want to use that class. This is required until #5 is merged in, which automatically registers subclasses but can break few edge case scenarios.

[adonoho]

Thank you for your clarification.

My use is as documented in the Parse subclassing guide. The docs need to be updated to specifically call out the exception of creating a custom subclass of PFUser. Here is a particularly useful place to document special requirements on PFUser. Is there a place for me to raise an issue to the documentation team?

I assume that when I call in Swift let user = User.currentUser() I get a real User, a subclass of PFUser. Not knowing how you resolve the subclass of a subclass of PFObject, I have concerns. Your claim that I should NOT override parseClassName does give me pause.

I will explore subclassing PFUser when [redacted] v7 goes GM and Parse SDK v1.8.3 is released. I'll keep you posted.