Correct flow to log in user from iOS app to remote API

Question

Here's the logic flow I'm trying to code into my iPhone app:

I think I understand the technicalities to achieve this (using AFNetworking, connecting to a Rails API using Devise as authentication). The auth_token will be stored in the keychain once the login is successful. What I can't figure out is the best way to go about setting up my app to behave like above.

I want the experience to be good for the user of course, so maybe while it's checking for the token and attempting to login it shows a "loading" screen of some sort.

How would I go about achieving this? I don't know which view controller I should set as the rootviewcontroller in the AppDelegate or how I should set it after the user has logged in. I've tried this in the Facebook app and when I open it I see a blank navigation controller it seems, then my profile view is loaded. What are they doing behind the scenes and is this the best way to go?

I am not using Storyboards.

Answer 1

I have implemented a similar one, the RootViewController was a "SplashViewController" in a navigationController, showing a nice logo, activity indicator and gives user info about authentication status. It holds the logic for checking stored token there and authentication implementation. If authentication is successfull, ShowUserController is shown by pushing to navigationController stack.

If authentication is failure a LoginViewController is presented modally. SplashViewController implements the delegate of LoginViewController, which does nothing but passing the username and password to SplashViewController. On successfull login, LoginViewController is dismissed and user is directed to ShowUserController.

Answer 2

Start your app with the root controller as the one that the user will see after they have logged in successfully, then layer the login views/controllers on top, with modal calls. If the authentication is successful, your user will already be where they want to be, else you call the login layers modally on top. Once they're authenticated, you won't need the login views anymore.

Answer 3

To elaborate on @Owen Hartnett's answer since this text won't fit in a comment; This is how I've seen Facebook's SDK work. If you build an app that uses the Facebook iOS SDK as the only login mechanism, then the way it works is like this:

In my app delegate's didFinishLaunchingWithOptions method I first check for an "already on file" access token in say, NSUserDefaults . If not found, I need to get one and so have my app delegate immediately launch a modal login flow that finishes with a valid access token that is then saved to NSUserDefaults for use on next app open.

If I do already have an access token on file in my didFinishLaunchingWithOptions , then I assume the happy path and open a "logged in user session" asynchronously using the access token I found on file at time of app open. If the access token I have on file to open the session with is legit, then no UX is displayed. If the access token I have on file is an illegitimate access token (server says it's too old, for example), then my open session method in my app delegate, upon finding this out, will display the proper modal login flow.

Since this openSession method executes asynchronously, you might be wondering how your root view controller, which needs a logged in user, is going to function in the meantime.

The answer is that it should be written as if it does have a logged in user. It should assume. If it ever runs code that can't run or finish executing successfully because it doesn't have a valid access token then that code should trigger the login UI if it's not already presented (ie the access token check on app open, by this time, has already presented the modal login UI to the user).

Lastly, this is a translated version of the Facebook SDK login flow. For example, if you use only their SDK you wouldn't ever be interfacing with NSUserDefaults like I suggest. I've translated their flow to a "custom implementation" of logging in to a remote API.