I often use Laravel to build the API that support the apps I build, because I can quickly create something that just works without writing too much code. However, dealing with authentication has (in my opinion) always been a cumbersome task.

So it doesn’t come as a surprise that after seeing Taylor Otwell’s Tweet about Laravel Airlock I wanted to give this a try for authentication in a simple mobile application.

A quick introduction: Airlock is a package for Laravel. It’s supposed to be a featherweight alternative to existing authentication methods (like Laravel Passport) for use in SPAs and simple APIs.

I’m going to briefly walk you through installing Airlock, but if you run into any problems, please refer to the documentation. After installing Airlock and building a simple authentication system with it, I’ll show you how to use it in your iOS app. I’ll assume you have basic Swift knowledge, and I won’t go in depth on creating the interface I’ll show in my screenshots.

Installation

I created a new Laravel project to test this. I’ll assume you know how to do this, but for more information please refer to the Laravel documentation. cd into the project directory and execute the following commands in your terminal:

composer require laravel/airlock
php artisan vendor:publish
php artisan migrate

We’re now ready to dive into the Laravel project to finalise setting up Airlock.

In your User model, use the HasApiTokens trait as follows:

use Laravel\Airlock\HasApiTokens;
// Other imports omitted.
class User extends Authenticatable
{
    use HasApiTokens, Notifiable;

    // Class body omitted.
}

Routes

Now that we’ve finished setting up, let’s create some routes. Add the following routes to your routes/api.php file:

Route::prefix(‘airlock’)->namespace(‘API’)->group(function() {
    Route::post(‘register’, ‘AuthController@register’);
    Route::post(‘token’, ‘AuthController@token’);
});

The user will use these two routes to register an account and to request their token (basically, to log in). Let’s create the AuthController and write the implementation of these routes. Run the following line in your terminal:

php artisan make:controller API\AuthController

Open the app/Http/Controllers/API/AuthController.php file you just created and add the register function:

public function register(Request $request)
{ 
    $validator = Validator::make($request->all(), [
        ‘name’ => [‘required’, ‘string’, ‘max:255’],
        ‘email’ => [‘required’, ‘string’, ‘email’, ‘max:255’, ‘unique:users’],
        ‘password’ => [‘required’, ‘string’, ‘min:8’],
        ‘device_name’ => [‘required’, ‘string’]
    ]); 
    // 1

    if ($validator->fails()) {
        return response()->json([‘error’ => $validator->errors()], 422);
    }
    // 2

    $input = $request->all();
    $input[‘password’] = bcrypt($input[‘password’]);
    $user = User::create($input);
    // 3

    $token = $user->createToken($request->device_name)->plainTextToken;
    // 4

    return response()->json([‘token’ => $token], 200);
}

Here’s a step by step breakdown of what this code does:

1. We validate the incoming request.
2. Check the outcome of this validation. If it failed, return the errors in the response.
3. Hash the password and create the new User.
4. Create a token and save it so we can return it in the response.

As you can see, performing a successful request to this endpoint will return the generated token in the body of the response. However, to make sure our users don’t need to create a new account whenever they want to use the app on another device, let’s create the function to allow our users to request their token:

public function token(Request $request)
{
    $validator = Validator::make($request->all(), [
        ‘email’ => [‘required’, ‘string’, ‘email’, ‘max:255’],
        ‘password’ => [‘required’, ‘string’, ‘min:8’],
        ‘device_name’ => [‘required’, ‘string’]
    ]);

    if ($validator->fails()) {
        return response()->json([‘error’ => $validator->errors()], 422);
    }
    // 1
 
    $user = User::where(‘email’, $request->email)->first();
    // 2
 
    if (!$user || !Hash::check($request->password, $user->password) {
        return response()->json([‘error’ => ‘The provided credentials are incorrect.’], 422);
    ƒ}
    // 3
 
    return response()->json([‘token’ => $user->createToken($request->device_name)->plainTextToken]);
    // 4
}

Here’s what this code does:

1. We once again validate the request, and return the errors if validation fails.
2. We get the first User from our database for the submitted email address. The email is unique, so at most this will return one user.
3. If the user doesn’t exist (so the email was incorrect), or the password isn’t correct, we return an error the app can pick up.
4. We return the generated token.

The scaffolding of our authentication is now complete! Let’s quickly create a route that’ll allow us to get the name of the logged in user.

In your routes/api.php file, add the following code:

Route::middleware(‘auth:airlock’)->get(‘/name’, function (Request $request) {
    return response()->json([‘name’ => $request->user()->name]);
});

Here we use the ’auth:airlock’ middleware. This will make sure the api token is present in the headers of the request, and will return an error if it isn’t. When the request works, we can use $request->user() to get access to the user model.

There’s a lot more I’d like to write about the things we can easily do with Airlock, but I’ll refrain from doing so to keep this article short. If you want to learn more about the possibilities, like adding /abilities/ and revoking tokens, take a look at the documentation.

Let’s authenticate

It’s time to put our api to the test. Let’s open up Xcode and quickly whip up a login screen. After doing whatever client side validation you want to perform, pass the values from the fields in your register form to the function you’ll use to perform the HTTP request. To provide code that can be used regardless of your preferred architecture, I’ll simply show you how to construct the request to register a user. Make sure to include the application/json Content-Type header, or your requests won’t succeed.

var request = URLRequest(url: URL(string: “http://yourprojecturl.test/api/airlock/register")!)
request.httpMethod = “POST”
request.addValue(“application/json”, forHTTPHeaderField: “Content-Type”)
guard let body = try? jsonEncoder.encode([
    “name”: name,
    “password”: password,
    “email”: email,
    “device_name”: deviceName
]) else {
    return
}

request.httpBody = body

The request to log in is very similar, we simply replace the final url endpoint with /token and remove the name from the body. A successful request to any of these endpoints will result in the following response body:

{
 “token”: “<api token>”
}

After your user registers their account or logs in, make sure to store this token somewhere. We’ll use it in this next request to retrieve their name from the backend:

var request = URLRequest(url: URL(string: “http://yourprojecturl.test/api/name"))
request.httpMethod = “GET” 
request.addValue(“Bearer \(apiToken)”, forHTTPHeaderField: “Authorization”)

A quick recap

Let’s briefly go over the things I explained in this article, to make sure we’re on the same page.

• We set up some scaffolding with Laravel and Airlock to handle user authentication.
• We can create routes using the ’auth:airlock’ middleware that will validate the token sent in the headers, and gives us access to the corresponding user model.
• We can create the requests to consume our API.

Next steps

As I mentioned before, this just scratches the surface of what we can do with Airlock. You can create tokens with different abilities so some users can perform actions while others can’t. Or you can set the token to expire after a certain amount of time, so the user has to request a new one. Airlock is still in beta, so expect things to change and new features to be added.

Hopefully this article gave you some insights in how Airlock can be a simple alternative to other authorization methods. If you’re a mobile developer and you have never worked with Laravel before, I highly recommend spending some time with it. You’ll be able to build the backend for your apps in no time.

If you have any questions, the best way to reach out to me is through Twitter. If you like reading this, please let me know if you’d like to read more about Laravel, Swift, or a combination of the two.

This year’s WWDC had a great talk on designing fluid interfaces. My main takeaway from this talk was how important gesture driven animations are, but not just that: how important velocity is while designing an animation. As to why this talk motivated me to write this article; somewhere in the talk they show this image:

And this sparked my interest: “Could it really be this easy?”. Turns out it is, so in this article I’m going to try to shed some light on that subject, and help you to create animations that feel just right.

Let’s get started

As an example, I’m going to try to replicate the behaviour of PiP (picture in picture) view as seen in the FaceTime app. This view can be dragged and dropped in any of the corners of the screen, but when given a swipe it will take that velocity into account. Let’s get started on building that.

Note: I’m not going to show everything (like initialising the positions for the corners to snap to) since that would be a lot of boilerplate code. I’m just going to show what is necessary to put the pieces everything together and implement this principle in your own application(s).

The code shown below handles a naive way of dragging and dropping the view: when the drag gesture ends (so when the finger no longer touches the screen) the nearest corner is determined, and the view snaps to that position. All this code is placed in the UIView subclass of the PiP view, so properties like frame are readily available. The setupGestureRecognizer function is called when we initialise the View in the ViewController, the currentPosition property is used to save the corner the view is currently “snapped” to and the nearesCornerPosition function uses the current position of the view to determine the corner that is closest (and then returns that corner).

So there’s not too much magic going on over here. The only cool thing you’ll notice is that we’re using spring animations here. From the documentation:

Performs a view animation using a timing curve corresponding to the motion of a physical spring.

This has some properties, like duration, delay, dampingRatio and velocity that you can play around with a bit to get the right feel. These properties are explained in the WWDC talk mentioned above.

This is the result:

It works, but it doesn’t feel right. Let’s fix that.

Velocity and deceleration

Woo! Physics! Let’s make our PiP view less naive. Let’s scrap that; we’re going to make it smart. We’ll have it measure its own velocity, declare a deceleration rate and project the final position it will land in if it continues on that trajectory. Now we can use that position to determine to which corner to snap. Sounds good? Let’s get started!

Alright; let’s break this down. Dragging around the view is the same as it was before, but the real magic happens when the gesture.state == .ended block fires. We take the velocity from the gesture object, and we take the default decelerationRate from the UIScrollView class. We then project the final position with a function called project:

Instead of using the frame.origin property to determine which corner to snap to, we now instead use the projected position we just created.

And that’s it!

So we’ve now covered a way to take velocity into account when building animations. I really recommend watching the WWDC talk mentioned above, since it gives a great explanation about the inner workings of the spring damping used in these animations.

One more thing

If you test the animations as shown above on a bigger phone (say, and iPhone X) you might notice the the animation feels a bit weird. I often do some phone specific checks to create an animation that is tailored to the device. In this case, a simple check like:

can really make a huge difference. In this case, the animation will play for 0.5 seconds if the device is smaller than the iPhone X, and will play longer on the iPhone X and all iPads. You can also play around with the spring properties to get the animation just right.

If you liked this article, check out the other articles I wrote! If you’d like to get in touch, you can follow me on Twitter or shoot me a message on LinkedIn. Also, if you need any help with anything iOS Programming related, you can join this Discord server created for exactly that purpose :)

Making iOS animations feel just right was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

The past month I’ve been working for a customer that had some pretty specific requirements for their product; they wanted an application that used a particular map component, the same one they use in their web app. That meant two things: javascript 🙈 and trying to find out how to communicate between the native code and the webview that would house the map.

The Problem

Let’s take some more time to sketch out the problem. We’re dealing with two major components here: a WKWebView to house the map and the native user interface. We want to send messages both ways between these components. When the user interacts with certain objects on the map, we need to trigger events in our native code to perform actions, like show an interface element, or trigger a segue to a new view. We also need to send messages to the webview from our native code, so we can delegate all the heavy lifting to the native application to minimize the amount of calculations javascript has to make.

The Solution

Lucky for us, WKWebView offers everything we need. With a bit of tinkering, we can configure it to do exactly what we need! Setting up a webview is trivial and well-documented, so I’m not going to explain that here. You can either instantiate it through code or simply drag one in your view in Interface Builder and create an outlet for it. I chose to do the latter.

Let’s make our ViewController conform to WKScripMessageHandler and WKNavigationDelegate:

Alright, now we’ve got part of our webview setup. We’ll come back to this later, but first, we will dive into some javascript.

Javascript 🙈

A quick disclaimer: I am not a web developer. If you are a seasoned javascript professional, please shield your eyes from the code that follows.

All we need to do in javascript is create a few functions for handling incoming responses, and sending responses back to the webview. I expect you’re comfortable with setting up an index.html file, so I won’t show you how to do that.

Now, we probably want to do something else than just logging the values we receive, but for the sake of explaining the concept, this will do. Say we’re keeping a list of people in the webview, the addPerson function will be called from the native context to add it to the webview. The sendNameToNative function can be called to send a message back to the native code. Let’s add the last building blocks to get everything working!

The last few steps

We need to do some things in our loadView function, so we will override that. In here we’ll set some properties for our webview to listen to the callback from javascript when the sendNameToNative function is called.

You might need to fiddle with this a bit depending on how you set up your views. One thing you might to do is change the frame to be equal to view.frame, and another thing that might fix problems here is adding view = webview after the last line. This might create some other problems.

There’s only one thing left to do here, which is actually sending a message to the webview.

This is the final piece to our puzzle; actually sending the message to the webview. Calling this function allows us to execute javascript in the webview. As you can see in the example, when we want to send a String, we need to add ‘ ’ around it. We can now call functions like this in the webView(_:didFinish:) function to set up the webview on load, and call it after interaction with the native user interface to send more messages.

Keep in mind that when you’re handling properties entered by the user, you might want to validate it so you don’t execute malicious javascript in the webview.

What’s next?

Now that you’ve got the structure laid out, you can go wild:

• Actually handle the response to trigger certain actions in native code, like animations or segues.
• Add more handlers to handle different responses from the webview, creating a tightly-knit connection between the two

Congratulations! If you’re reading this you’ve created a connection between a WKWebView and the native context of your application. This opens a lot of possibilities, and you can take this as far as you want. If you created something awesome with this, please share it with me!

If you liked this article, check out the other articles I wrote! If you’d like to get in touch, you can follow me on Twitter or shoot me a message on LinkedIn. Also, if you need any help with anything iOS Programming related, you can join this Discord server created for exactly that purpose :)

What you see in the video above is the TabBar’s selectionIndicatorImage, a property of the TabBar to indicate that tab is currently selected. I then drew an image at the bottom of the TabBar. What happens now is that every tab has their own image, and it just shows and hides them depending on the state. This isn’t what I wanted and couldn’t possibly solve the problem I had, since they are all different images.

Lets subclass

The solution to our problem lies in subclassing UITabBarController. I made a class called TabBarController and added a UIImageView to it. I then tried to find a way to move this image to the right position whenever a tab was selected. Thanks to the delegate functions UITabBarController provides, this was a piece of cake.

Let’s break this down. We create an empty indicatorImage variable. This will be the line that we move around. We initialise it in the viewDidLoad method. For that we use the createSelectionIndicator function that takes a color, a size (the width we want our bar to be, and the heigh of the TabBar itself) and a lineheight. The function draws this into an image an returns it, and we then add that to the TabBar.

We can now move the image that we created around! I use the didSelect item delegate method to check for touches and I use some boilerplate to check for the location the image needs to move to. Wrapping this all in an UIView.animate block gives us a smooth animation between the two points.

When you’re done implementing all that, you can hook it up to Interface Builder by setting the custom class to your TabBarController.

I had to tinker with a few of the options in the Attributes inspector. For me, these settings did the job for all different devices. If it doesn’t work for you, try to fiddle with the Item Positioning and the Content Mode attributes.

The result

After walking through all these steps you’ve created an animated selectionIndicatorImage for the UITabBarController. This is simply a proof of concept to show how it can be done, and if you write a better implementation make sure to send it to me!

If you liked this article, check out the other articles I wrote! If you’d like to get in touch, you can follow me on Twitter or shoot me a message on LinkedIn. Also, if you need any help with anything iOS Programming related, you can join this Discord server created for exactly that purpose :)

A while ago I wrote an article regarding some of the differences between iOS and Android development I ran into. As a conclusion, I wrote that it’s important to understand that you need a completely different mindset doing both of them. The view lifecycle is different, the interface builder relies on some completely different principles (density independent pixels? What?), and last but not least: if you’re not using libraries, you’re missing out.

Libraries

Let’s kick this one off with an example: the app I built had to display images. Simple enough, lots of apps display images. In iOS I can just create UIImageViews and add UIImages to them whenever I please. I tried to do exactly that in my Android app; I had data classes with associated Bitmaps, and then I loaded them into ImageViews whenever necessary. The result: constant Out of Memory Exceptions resulting in hours upon hours of memory debugging because the Bitmaps weren’t being released!

I never had to deal with any memory management before (and technically, I still didn’t have to) so I started crawling through StackOverflow(SO) for a solution. At some point, I got my memory footprint down by calling the recycle function on the Bitmaps I wasn’t going to use, and by calling the System.GC function whenever I knew a garbage collection would free up some allocations. This resulted in the memory graph as shown above.

In my quest through the Android section of SO, I had seen the name Picasso dropped a lot. This is an image library that took care of the same problem I tried to fix and did more. After a while of struggling with doing my own memory management, I decided to jump the gun and import the dependency. I was amazed: not only did this manage my memory way better than I did by doing things like caching images that might be needed later instead of reloading them every time, it allowed me to remove all my networking code regarding images.

By using the Picasso library, I was able to remove the class shown above and all the code that took care of processing that image (resizing, scaling correctly, making it circular) and replace it with this single line of code:

This was my eye-opener. If I could make my life that much easier with this one library, how many other brilliant libraries were still out there, waiting for me to integrate them into my code? That same day I replaced all my networking code with the OkHttp library, further improving my memory footprint by not having countless strings allocated by a StringBuilder parsing a JSON file.

API Levels

This has been a hurdle, to say the least. It’s definitely just something you need to get used to, but it’s a hassle at first. We all know that great feeling of finding a solution to the exact problem you’re having on SO. Android developers know how that feeling can get crushed by looking up the specified methods in the documentation and finding out the required API level is higher than the lowest one they have to support. What follows is a scavenger hunt to find out the inner workings of the method, and to try to replicate its behaviour. An example of this is when I wanted to execute something after an AnimatorSet finished animating:

With API level 24 and up, we can use the getTotalDuration method and use its result in a postDelayed block. Sadly, my app had to support lower API levels so I wrote the above implementation.

Nice bonus: the extension function, as shown above, can also be called at points between animations while creating the AnimatorSet object, to fire code blocks at certain points during the animation! :-)

This taught me a valuable lesson: take some more time looking through SO. Answers from 2013 might not be relevant at all anymore, and new answer are often a lot further down the page! An example I’ve used earlier is JSON parsing. This was one of the first things I built into the app, as it had to communicate with the backend I made for it. The first Google results wrote about using BufferedReaders and StringBuilders; a lot of boilerplate that does something very simple, allocates a lot of Strings and clogs up memory debugger with them. If I had taken some more time to scroll down the page of SO I would’ve found the great suggestions on using the GSON library or the OkHttp library for network requests.

Wrap-up

I could try to write a section about the interface builder, but the truth is I suspect I just don’t grasp that fully yet. I’ve embraced Xcode’s interface builder, and Android Studio just uses a lot of different terms and principles.

The most valuable lesson I’ve learned is to keep an open mind at all times. It’s easy to turn on tunnel vision and to try and find a solution similar to what works on iOS, but often it just isn’t that simple. You shouldn’t think about refactoring what works on iOS to Android, you should try to find a solution that works for Android. Whether that is using a library or writing your own solution to a problem, you shouldn’t be afraid to try new things.

If you liked this article, check out the other articles I wrote! If you’d like to get in touch, you can follow me on Twitter or shoot me a message on LinkedIn. Also, if you need any help with anything iOS Programming related, you can join this Discord server created for exactly that purpose :)

Hey! My name is Jille van der Weerd. Recently I was asked to build the Android counterpart for an iOS app I made, so I had to dive into the rabbit hole that is Android development. Working with a new IDE, a new language and a whole new community of people to learn from, it was an eventful journey. The app is now nearly finished, and I decided to write down some of the important things to note when making the same leap from iOS to Android development.

Note: I don’t claim to know everything about the things I write about. These are just my findings, and I hope some people can learn from them. If you have any suggestions or criticism, please let me know.

A quick introduction

Just under a year ago I dropped out of my Computer Science (CS) education. That’s when I started teaching myself Swift and where my journey began. Since then I’ve built a series of apps that never saw the light of day and I’ve landed a job as an iOS developer. When making this Android application, I ran into a lot of issues because I got used to having certain features from Swift. This article is meant to give some clarity on how to do those things when migrating to Android, and hopefully give Android developers an insight in potential libraries to develop.

The Codable Protocol

We’ve only had it for a few months, but it saves so much time and makes my code so much more readable. I didn’t really get around to using it for a long time, but then a friend of mine told me about how awesome it is and now I try to use it whenever I can. In Swift, the code below is enough to decode a JSON string to an object, or even an array of objects.

I haven’t found an equivalent to this in Kotlin/Java. Undoubtedly, there is a library that allows me to do something similar to this, but I prefer to use as few libraries as possible. In my Android app, I’m stuck to converting the JSON string to a Map and retrieving all properties from it line by line, increasing the workload significantly when changes to the backend occur.

Grand Central Dispatch

I didn’t know I could miss Grand Central Dispatch since I haven’t even scratched the surface of multithreading, but when I wanted to do a simple asynchronous network request on Android, I ran into a lot of trouble.

Having to subclass something for a task so trivial doesn’t feel “Swifty” at all, mainly because executing a task asynchronously in Swift is achieved simply by writing this block around it:

Now, I’m sure there’s a better way to do this. My main annoyance hereis that I’d have to subclass AsyncTask for every different kind of request I want to make, whereas in Swift I can just execute whatever request I want in the above block and I’m set. It just feels like the logic approach.

Interface Builder

Love it or hate it, Xcode’s Interface Builder is a great tool for helping you visually layout views. Androids wildly different view structure (fragments? layouts? XML?) greatly contributes to this. I got the hang of building views in Xcode in under a week, and using constraints feels natural. If I want/need to add another layer of depth to this, I can use priorities. In Android Studio, the

Activity Designer(?) uses some sort of relative values for constraints, where setting all layout margins to 8dp can result in them being different distances from the edge of the screen. And building the layouts in Android with XML is a blessing and a curse. While it’s great to layout your views with code, and it gives you a lot of freedom as to what you can do, I had the option to do so in Xcode while also using the great Interface Builder system.

HTTP GET Requests

In Swift, the first application I built used GET requests from an API, so naturally, I assumed doing the same in Android would be a piece of cake. Right? That’s where I was wrong. In Swift, implementing the basic functionality of making a GET request and retrieving the JSON file can easily be achieved by doing this:

However, In Android things are very different, daunting even. This is the Kotlin code I currently use to make a GET request and retrieving the JSON:

…and this is just the subclass. When we actually want to perform the request, we still need to write this:

HttpGetRequest().execute("your api url here").get()

This isn’t necessarily all that complicated, but it’s a lot more difficult than the approach taken in Swift.

Sidenote: I’m sure there’s a better way to make these requests, be it with a library or otherwise. If you have any suggestions, please let me know.

That’s a wrap! For now.

I’ve been working with Kotlin and Android Studio for about two weeks now, and I’ve learnt a lot about how to use these technologies. Every hour I spend working on this project, I learn new things, and I find out new things I like better about Android, or things I miss, coming from Swift. Give it a few weeks, and I’ll probably have enough ideas to write another article on this subject.

If you liked this article, check out the other articles I wrote! If you’d like to get in touch, you can follow me on Twitter or shoot me a message on LinkedIn. Also, if you need any help with anything iOS Programming related, you can join this Discord server created for exactly that purpose :)