When it came to building an app with a login screen I got a bunch of questions. And I found some answers to them scattered all over the Internet. It might seem an obvious task, but I really wanted to find a guide with some clarifications. I wasn’t lucky enough to do that so I decided to describe my way of building a [first] login view myself.
First of all, you can find the final sources for this post at https://github.com/ssidelnikov/iOSLoginView. That is actually a part of the pull request to a great Hacker News Reader App by Ryan Nystorm. I would highly recommend you to check out the whole repository as there are a lot of great things there.
Building UI
The first question I came across was how they build those great UI with two fields and a button in the right way. Something like this:
At first I thought it was a UITableView as a central part of the view. There were also an image or label for “Facebook” above it. And something in the footer. This StackOverflow answer pointed to the same solution as well. The UITableView has two static cells with input fields. But that’s impossible if you place it into a UIViewController, not a UIViewTableViewController. My point was to build it completely in a xib file without any extra code or usage of a storyboard and a container view.
So I looked further for another real-life examples and found a LastFM iOS app repository. It used another approach to the problem. The developer put two images under the input fields as a background so they appeared to be a table view. Using some constraints, you could achieve nice results. This approach seems a bit hackery to me, but if LastFM uses it, that might be not that bad after all. In my case, the final view somehow like this:
Networking
Another challenge in building a login feature in the iOS app is, well, login feature itself. That is how you send the request, store the session key and use it in future requests to the server. If you are working with an API, everything is fine. You send a request according to the documentation. Then you receive the response with the session key and store it to the database or user preferences. All the future requests contain that key in their headers. This seems easy and straightforward.
The project I was working on dealt with a website that offered no API for login or logout. You send a POST request to the server, and then receive a redirect response with a cookie called “user”. All future requests should contain that cookie.
Working with cookies had always pictured to me as a brittle thing. But it turned out to be a quite easy and safe task on iOS. You basically make a request using NSURLSession with the defaultSessionConfiguration. Some custom delegate is also set for the session to prevent redirection. You shouldn’t worry about the cookies in the sharedCookiesStorage. If their expiration date is set correctly, they persist between app relaunches.
