Add better, more flexible APIs for SDK initialization.

[richardjrossiii]

This PR includes public API Changes

Old initialization looked somewhat outdated, our new APIs allow a usage similar to this:

ObjC

[Parse initializeWithConfiguration:[ParseClientConfiguration configurationWithBlock:^(ParseClientConfiguration *configuration) {
    configuration.applicationId = ...;
    configuration.clientKey = ...;
    configuration.localDatastoreEnabled = ... ;

    // Data sharing config, etc.
}];

Swift

Parse.initializeWithConfiguration(ParseClientConfiguration() {
    $0.applicationId = ""
    $0.clientKey = ""
    $0.localDatastoreEnabled = true
    // etc.
})

We believe that this provides a much cleaner interface for initialization. Please feel free to comment below on any feedback that you may have on this

---

Our current SDK initialization is lackluster in that it's split across multiple classes, files, and method calls.

This PR hopes to unify some of these initialization settings int o a single 'configuration' class that can be easily used to intialize parse in a much cleaner way, especially as we add even more initialization options.

[nlutsenko]

Nullability annotate, pretty please. 😁

[nlutsenko]

Nit: Space before BOOL

[nlutsenko]

I don't think we need these, simply due to the fact that you can't init it anyway after allocating... 2 less methods polluting the name space?

[richardjrossiii]

Hey all, just added some preliminary APIs for configuring URL sessions & retry attempts that we use in the SDK. Any feedback would be great!

[facebook-github-bot]

@richardjrossiii updated the pull request.

[oferRounds]

Hi @richardjrossiii
Thanks for your very detailed and answer and for your very quick respond!
The changes you've added look great! That will suit exactly what I'm looking for.

When do you think this PR could be merged into master?

[grantland]

I never realized that iOS uses set instead of initialize. I do like moving towards initialize since it's not exactly a setter, but is it weird to have it be named differently?

Also, if we keep initialize, we should probably update the abstract of it from Sets the configuration to be used for parse to Initialize Parse with a configuration or something

[richardjrossiii]

My best guess for the reason that we use set instead of initialize on iOS - +initialize is a method declared by NSObject, equivalent to a static contractor in java-land.

It would have caused some ambiguity for developers if we had a method call like [Parse initialize:@"appKey" clientKey:@"ck"], but we can get around that now by marking +initialize as unavailable for use (which wasn't possible when Parse was first created).

[grantland]

Ah that makes sense, SGTM!

[grantland]

Somewhat nitpicky, but ParseClientConfiguration seems super long. Would ParseConfiguration be confusing with ParseConfig?

[nlutsenko]

Somewhat nitpicky, but ParseClientConfiguration seems super long. Would ParseConfiguration be confusing with ParseConfig?

Yup, it's definitely confusing. It's ObjC anyway, so long names are expected...
Plus - this way lets us name the class in the same way across multiple platforms (there is ParseConfig already on the Java).

Another potential name that could work is ParseClientConfig, but then it's still somewhat confusing compared to ParseConfig.

[nlutsenko]

Rename to initWithBlock:, as you don't have it in the static constructor.

[facebook-github-bot]

@richardjrossiii updated the pull request.

[nlutsenko]

Not sure if this is the appropriate place for it, as startManaging doesn't quite relate to Offline Store only.

[facebook-github-bot]

@richardjrossiii updated the pull request.

[facebook-github-bot]

@richardjrossiii updated the pull request.

[nlutsenko]

Maybe invoke -initEmpty here and declare that as internal designated initializer (class extension in the .m file). Don't feel strongly about it, tho.

[nlutsenko]

One small nit, otherwise - it's perfect!

[facebook-github-bot]

@richardjrossiii updated the pull request.

[oferRounds]

Hi @richardjrossiii
Sorry for the question, I'm just not completely sure - if I update my Parse SDK using CocoaPods, will this branch be included?

[nlutsenko]

@oferRounds No, not yet, this is going to be included in 1.12.0 release (per milestone on the Pull Request).

[oferRounds]

@richardjrossiii - cool, thanks!

[facebook-github-bot]

@richardjrossiii updated the pull request.

[parse-github-assistant]

The label type:feature cannot be used here.