Stable branch? Develop currently can't call startWithAppID

[agiletortoise]

I'm a bit behind, and I'm trying to update my Simperium code.

Is "develop" considered stable? I'm running into a lot of issues with it.

The current checked in version of "startAppWithID:APIKey:model:context:coordinator" is not runnable. It assert both that the "persistentCoordinator" param is present and not present.

I commented out the nil assertion and then get into errors in validateObjects ("Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: '+entityForName: could not locate an NSManagedObjectModel for entity name 'Draft''"), when it's a valid entity on the model passed in.

Is this stuff in progress? Is there a current stable branch that I'm missing?

Thanks.

[jleandroperez]

@agiletortoise hello there!,

The current 'develop' is considered stable (we're using it to power up Simplenote iOS / OSX app).

The reason you're getting an assertion, is because the CoreData architecture was updated. (The docs will be updated shortly).

In order to fix it, please, try the following:

• Your main NSManagedObjectContext should be initialized with NSMainQueueConcurrencyType parameter.
• Don't set the persistentStoreCoordinator yourself. Simperium's CoreData manager will create a background writer MOC, and will wire everything for you.

If you're still having any issues, please, just let us know.

Thanks!

[agiletortoise]

OK, I think I'm making sense of the changes now, thanks.

I was using a custom SPLoginViewController. I get the name changes, updated my class, but it appears you no longer init that with a nib.

Really, I'm not sure I need the custom controller anymore, but also can't see where I can cleanly intervene and handle the house keeping I need to do on auth/deauth.

The SPAuthenticatorDelegate isn't exposed (it your own Simperium object) and it doesn't seem to fire any notifications that I'm seeing.

Also the SPAuthenticationViewController doesn't expose itself in such a way that you could subclass it and make callbacks.

Ideas? Surely I'm missing something.

[jleandroperez]

@agiletortoise great!.

Unless you need to do custom tasks (or tweak the login screen's UI), you can use the stock login viewController.
If you'd like, you can always subclass 'SPAuthenticationViewController'. That's the new login/signup ViewController, and it's 100% code (no nib's needed).

Once you subclass it, you'd need to set the 'Simperium :: authenticationViewControllerClass' property, so the framework knows which class should be instantiated, to handle the login/signup UI.

Regarding exposure of 'signed in / up / logged out', if it's useful, we can add a ticket to expose those events.

Thanks!

[mikejohnstn]

Jorge speaks the truth. Subclassing is the intended mechanism and we ditched the need to mess with a .xib file (unless you really want). Let us know if you have any feedback...we can keep tweaking.

We'll also (finally) be switching to tagged versions in the master branch soon so you know when the build is stable.

[agiletortoise]

I get the subclassing, though I think it could be refactored to be cleaner. If you subclass SPAuthenticationViewController, there are no good entry points to do minor modifications, or hook into the process, you basically have to completely rewrite it in your subclass (i.e. the fields are not exposed to the subclass).

For testing, I'm using the stock SPAuthenticationViewController, and I inited my Simperium instance with a custom SPAuthenticator that has my own delegate, so I can tap into the cancel/fail/successed loop. My delegate methods are then calling the Simperium objects versions of those delegate methods to complete the loop, but that's pretty clumsy.

Would you consider moving the optional auth delegate methods up to the SimperiumDelegate level? That would expose them more cleanly.

Also, SPAuthenticationViewController could make it's fields public properties to they could be modified/access in a subclass – and/or provide properties for optional success/fail/cancel block callbacks that could be set to prevent having to override the entire "createLogin" and other methods.

Mostly I'm happy with the default auth view, but need to be able to add a "Forgot my password" button/action that are custom to my app – it doesn't look like you've provide a more generic means of handling that yet.

[prvnl]

Hi All,

Must say I have to agree with Greg. I had the same questions about the develop branch.

Now I have to create my own version of the framework to get everything the way I like, but this makes upgrading to newer versions harder. That’s the issue I’m facing now to upgrade my current apps to the newest develop branch.

If you want the integration of Simperium simple and easy for all users, subclassing is not an option unless good examples are available. (B.t.w. at the moment the SimpletodoFinal app from the develop branch is not working without some modifications).

I think the new sign-in/sign-up interface is cool, but really needs some default customizable options:

• Terms of service (TOS) text is not localized
• Set a custom TOS URL (maybe using localization?)
• Option to make the displaying of the TOS link optional
• Option to add the Forget password link
• Option to set the color of the Navigation controller (when authenticationOptional is active)
• Option to change the sign-in button colors
• Option to set the font type & size for the texts (especially for the UITextFields)
• The logo should not be hidden on an iPad, there is enough space to show all content

Issues in SimpletodoFinal:

• Update ‘mainContext’ to ‘context’ in the ‘startWithAppID’ initialization of Simperium
• Logo not visible in sign-in/sign-up interface
• Wrong reference ‘detailDescriptionLabel’ in iPad Storyboard.

Thanks!

[jleandroperez]

@agiletortoise thanks for the feedback!. I'll add a couple tickets to cleanly expose auth callback methods, plus, ease the SPAuthenticationViewController subclassing process.

@prvnl thanks for reporting the demo app glitches!. I've just pushed fixes for both of them. Regarding the 'Logo Image not appearing', please, check the following:

• SPAuthenticationViewController line 129.
• Logo image is loaded with the contents of: [SPAuthenticationConfiguration sharedInstance].logoImageName

In order to get it working, you'd need to add a logo image in your app's resources, and tweak (if needed) the logoImageName string.

[mikejohnstn]

The original issues seems addressed, so going to close it, but...

I also added an issue to better document the various authentication options: #161

And a more detailed issue for @prvnl's very good suggestions: #162