Evolution?

[pranjalsatija]

@flovilmart I'm really interested in helping to make this a thing, and I'd love to take on some tasks (major ones, too!) to get this up to feature parity with the Objective C version. Are there any evolution guidelines, or a list of long and short term goals and features? If so, could you please point me to them so I can begin to get to try implementing some of the features that are planned? If not, could you just give me some general advice on some of the things that are planned? I'd love to have an active role in the development of this framework.

[flovilmart]

Hi @pranjalsatija ! Thanks for the interest!

The guidelines are quite simple, I want to make the SDK as less intrusive as possible, as you may have noticed, pretty much every functionality is coded as protocols. I want to leverage as much as possible the Codable type introduced in Swift 4.

For now, we have queries, and bare objects. The UserType is also exposed, need some work for archival / surviving the app restarts etc... This could be ported from the Obj-C SDK, leveraging the Keychain as it is for storing sensitive data.
Anonymous users as well as 3rd party login / signup is not implemented, and could be worked on as well.

Installation is the next big one, with the same features as the Obj-C counterpart as well.
Probably we could have a nice way to retrieve the installationID from and existing app, so users have a migration forward.

• Backwards compatibility/in-place replacement is not a goal, this is a new SDK with a new philosophy.
• Prefer value types and immutability, this helps making thread safe code.
• Prefer protocols over objects, for the en developer to add the required keys is provided by the compiler (objectId etc...)
• 0 dependencies, the orignal SDK heavily relies on Bolts (actually bolts was written for the purpose of those SDK's), I'd like to keep it dependency free. Nowadays, Foundation's networking stack is powerful enough to provide caching downloading etc...
• Server-side, I'd love to see that SDK strive server-side, and I believe it could really shine in a micro services architecture, that would help developers reuse their models on iOS and the server, and perhaps, in the future Android if Swift's android support starts growing.
• LocalDataStore? That's a tough one, perhaps the default SDK only provides hooks for a local datastore and extensions over popular datastore can be provided by 3rd parties. There is a big challenge not in storing object but effectively retrieving them as described in the iOS SDK.
• TEST, TEST, TEST, something I didn'T started, but we need to have strong unit/functional tests

What I had in mind:

• For now we use the Result enum to convey success/errors, this should be ripped off in favour of try
• RESTCommand is not to my taste, I'd prefer having a mutating value type instead
• RESTCommand + API is quite redundant, not the right abstraction, perhaps we can think of something better.
• I'M twisted between user support and Installation support, because in a server side environment, they don't make much sense. I'm not sure how to prioritize those features.

Also, I'm/we're very open adding collaborators to this project, to get it off the ground as fast as possible!

[pranjalsatija]

Hey Florent! Thanks for the reply. I'd love to be a collaborator on this project. I think it would be a really cool project to work on.

So, I've been looking at the code and I agree with a lot of the things that you think should be changed. I think that if we plan on making any major changes to core functionality such as REST API stuff, it should be done early on. That being said, I don't like the current approach. I think it's a little confusing to have the API and RESTCommand structures existing together. I think a better idea would be to eliminate RESTCommand and go with a more powerful API, which would make calls like this possible (just a potential idea of what we could try to do):

let request = API.Endpoint.signUp.makeRequest(body: data)
request.execute {(response, error) in

}

I do actually like the Result enum. I use a similar enumeration in my apps, so I personally like that approach, but I feel that we should remove the unknown case. The beauty of Result, to me, is how "black and white" it is. A result either succeeds or fails, and there needs to be a sensible default as to which one is correct if neither is inherently obvious. If you're against this, there's nothing really wrong with Swift's native error handling.

On the other hand, I'm not a huge fan of the way encoding is done right now. I think it's a complex approach that could be simplified greatly by creating a protocol called ParseEncodable or something, and implementing extensions on objects so that calls like try myObject.jsonEncoded() are possible. I like this approach more than the existing one because it's a lot simpler and many types won't even need an implementation, because we will be able to provide a good default implementation via protocol extensions. Some types will need their own encoding strategies, such as Date, in which case, we would provide a separate implementation.

Finally, should we consider renaming ObjectType and UserType to Object and User? It seems like the Standard Library has done something similar and dropped the "type" suffix from protocols.

Let me know what you think about these things! As I said, I think we should tackle these issues before we move onto implementing more functionality because it's much easier to change these things early on.

[flovilmart]

The beauty of Result, to me, is how "black and white" it is.

Yeah and throws encapsulates this as well, thinking forward async await implementation in swift 5, this will make things even better. I actually started with throws, then moved back, etc..

try myObject.jsonEncoded()

This would basically be:

extension Object {
  func parseEncoded() throws -> Data {
   return parseEncoder.encode(self)
  }
}

not sure it's worth formalizing into an extension, note that some keys have to be skipped, and if you use a default JSON encoder this won't work.

This is the whole point of Codable, and it provides Compile time encoder instead of runtime encoder which is way better.

the encoder on the other hand, is the ParseEncoder, dumped / modified from the date.

I would not change that at the moment, it simplifies all aspects of object mirroring to discover the keys to encode etc....

Finally, should we consider renaming ObjectType and UserType to Object and User

I'm not against, I was concerned it would feel weird at consumption time:

import Parse
struct Installation: Installation {}  // not possible
struct Installation: Parse.Installation {} // why not.. 

Hope that helps!

[pranjalsatija]

Yes, that's great! You're OK with my proposed changes to API and RESTCommand, right?

[flovilmart]

yep I had the feeling for a while RESTCommand and API should be merged (the more I started adding enum based endpoints to API) everything started to be redundant.

Also perhaps keep in mind that we may want LocalDataStore, in that case, having a front on top of API isn't BAD, but we may need 2 API abstractions or I dunno.

[pranjalsatija]

@flovilmart Can you take a look at the commit I just added to my fork of the repository? Result is gone, and has been replaced with do try catch and regular callbacks for async functions. Is there anything else I should change about what I just committed, or do you think that's good to go? In addition, I'm noticing a pattern here that might need some attention. REST API requests look like this:

API.Endpoint.someEndpoint.makeRequest {(data: Data?, error: Error?) in
  if let data = data {
    do {
      let decoded = try getDecoder().decode(Something, from: data)
      callback(decoded, nil)
    } catch {
      callback(nil, error)
    } 

  else if let error = error {
    callback(nil, error)
  }  else {
    fatalError()
  }
}

It's not totally gross, but I do think we could do something to clean that up a bit. Do you think that's necessary? One thing that bugs me the most is the fatalError(). I think we could replace that with some sort of catch all error that reads "unknown error occurred" or something. Let me know what you think!

[flovilmart]

Unknown / internal error would be nice, actually we know what happens, neither data nor error was set.

[pranjalsatija]

Got it.

[flovilmart]

Also fatalError could help us in unit tests to make sure we cover all bases

[pranjalsatija]

Which one should we have then?

[flovilmart]

Internally, we should never reach that state, so that’s a good candidate for fatalError. We can guarantee as SDK developers that it is never reached!

…

On Sep 10, 2017, 19:02 -0400, Pranjal Satija ***@***.***>, wrote: Which one should we have then? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[pranjalsatija]

@flovilmart, do you have any advice on how to implement User.current's persistence between launches? I want to do that next, and then implement Installation.

[flovilmart]

Have a look at the original SDK, that will help a lot. It involves disk serialization and keychain for sensitive info like sessionTokens

[pranjalsatija]

@flovilmart I have a quick question, and it may just be caused by me not understanding something.

I found this in PFUserController.logInCurrentUserAsyncWithUsername:

PFCurrentUserController *controller = self.coreDataSource.currentUserController;
return [[controller saveCurrentObjectAsync:user] continueWithBlock:^id(BFTask *task) {
    return user;
}];

I then headed to PFCurrentUserController, where I found this under the "Sensitive Data" pragma:

- (BFTask *)_saveSensitiveUserDataAsync:(PFUser *)user toKeychainItemWithName:(NSString *)itemName {
    return [BFTask taskFromExecutor:[BFExecutor defaultPriorityBackgroundExecutor] withBlock:^id{
        NSMutableDictionary *userData = [NSMutableDictionary dictionaryWithCapacity:2];
        @synchronized (user.lock) {
            if (user.sessionToken) {
                userData[PFUserSessionTokenRESTKey] = [user.sessionToken copy];
            }
            if (user.authData.count) {
                userData[PFUserAuthDataRESTKey] = [user.authData copy];
            }
        }
        self.commonDataSource.keychainStore[itemName] = userData;

        return nil;
    }];
}

Finally, I went to PFKeychainStore, which seems to be doing pretty regular keychain wrapping stuff.

The only thing I'm confused about in all this is that it seems like the currentUser itself is being saved in the Parse Local Datastore, and the user's sensitive info (auth data and session token), are being saved in the keychain. What should I do about this in the Swift SDK? Since there's no local datastore, where should I save the rest of the user object?

Additionally, do I have the right idea here? Is this how users are actually persisted in the Objective C version of the SDK? I'm not familiar with it, as I never made any code level changes to it, but I think I'm seeing how the user object is persisted. Could you correct me if I'm wrong?

[flovilmart]

You are 💯 right about the objective C SDK. For now we could have a file based local data store as it’s not provided yet by the SDK!