Tomasz Szulc

Add fireworks and sparks to a UIView

Thu, 20 Sep 2018 08:00:00 +0000

Do you like a little things that happens in apps you’re using? I looked at dribbble for inspirations and found a beautiful design of onboarding process where fireworks exploded (!) around important view when user changes settings or something. I wondered how difficult it is to implement, and some time later I finished it :)

Fireworks in details

Here is a detailed description of the effect. Fireworks should explode on a specific position around a view - presumably a button reacting on tap event. When it is tapped fireworks should explode close to the corners of the button and explosion should shift sparks from the explosion origin on their own trajectories.

Love it! Makes my eyes happy and makes me want to tap the button all the time :) 🎉

Now let’s take a look at the animation. Behaviour of firework as a whole is similar for every generated firework. There are also small differencies in the trajectories and scale of sparks. Let’s break it down.

There are two fireworks on each button tap,
Each of them consists of 8 sparks,
Each spark follow its own trajectory,
Trajectories look similar but they’re not identical. Few goes to the right, few to the left, others to up and down looking from the explode origin standpoint.

Sparks distribution

This firework has a simple spark distribution. Two sparks on each “view quarter” around the explosion origin. Two sparks in the top right, bottom right, bottom left and top left quarters.

Spark trajectory

Spark has a trajectory it is moving on. There is 8 sparks in a single firework so there is 8 trajectories needed at least. Ideally there should be more trajectories so we can random, so consecutive fireworks don’t look exactly as previous ones.

I’ve created 4 trajectories for each quarter to add some randomness - twice more than sparks. For simplicity of calculations I normalized position of points creating trajectories. Presented trajectories differs a bit from what I finished with because I’ve used different tool to visualize implemented trajectories - but you can get the idea :)

Implementation

Enough theory. Let’s put all the pieces together.

protocol SparkTrajectory {

    /// Stores all points that defines a trajectory.
    var points: [CGPoint] { get set }

    /// A path representing trajectory.
    var path: UIBezierPath { get }
}

Here is a protocol representing spark trajectory. Sharing common interface will make it easier to create various types of trajectories. I’ve decided to go with trajectories based on Cubic Bézier curve and added an init method so I can make it one line call. Path of this type must consists of four points. First and last points specifies start and finish position and two middle points are points to control a curvature of a path. You can use [demos] online math tool to play with Bézier curve.

/// Bezier path with two control points.
struct CubicBezierTrajectory: SparkTrajectory {

    var points = [CGPoint]()

    init(_ x0: CGFloat, _ y0: CGFloat,
         _ x1: CGFloat, _ y1: CGFloat,
         _ x2: CGFloat, _ y2: CGFloat,
         _ x3: CGFloat, _ y3: CGFloat) {
        self.points.append(CGPoint(x: x0, y: y0))
        self.points.append(CGPoint(x: x1, y: y1))
        self.points.append(CGPoint(x: x2, y: y2))
        self.points.append(CGPoint(x: x3, y: y3))
    }

    var path: UIBezierPath {
        guard self.points.count == 4 else { fatalError("4 points required") }

        let path = UIBezierPath()
        path.move(to: self.points[0])
        path.addCurve(to: self.points[3], controlPoint1: self.points[1], controlPoint2: self.points[2])
        return path
    }
}

Moving on. Next thing to implement is a factory that can random a trajectory. On the drawing above you can see trajectories grouped by color. I’ve only created top right and bottom right trajectories and mirror them. This is fine for a firework we’re about to launch 🚀

protocol SparkTrajectoryFactory {}

protocol ClassicSparkTrajectoryFactoryProtocol: SparkTrajectoryFactory {

    func randomTopRight() -> SparkTrajectory
    func randomBottomRight() -> SparkTrajectory
}

final class ClassicSparkTrajectoryFactory: ClassicSparkTrajectoryFactoryProtocol {

    private lazy var topRight: [SparkTrajectory] = {
        return [
            CubicBezierTrajectory(0.00, 0.00, 0.31, -0.46, 0.74, -0.29, 0.99, 0.12),
            CubicBezierTrajectory(0.00, 0.00, 0.31, -0.46, 0.62, -0.49, 0.88, -0.19),
            CubicBezierTrajectory(0.00, 0.00, 0.10, -0.54, 0.44, -0.53, 0.66, -0.30),
            CubicBezierTrajectory(0.00, 0.00, 0.19, -0.46, 0.41, -0.53, 0.65, -0.45),
        ]
    }()

    private lazy var bottomRight: [SparkTrajectory] = {
        return [
            CubicBezierTrajectory(0.00, 0.00, 0.42, -0.01, 0.68, 0.11, 0.87, 0.44),
            CubicBezierTrajectory(0.00, 0.00, 0.35, 0.00, 0.55, 0.12, 0.62, 0.45),
            CubicBezierTrajectory(0.00, 0.00, 0.21, 0.05, 0.31, 0.19, 0.32, 0.45),
            CubicBezierTrajectory(0.00, 0.00, 0.18, 0.00, 0.31, 0.11, 0.35, 0.25),
        ]
    }()

    func randomTopRight() -> SparkTrajectory {
        return self.topRight[Int(arc4random_uniform(UInt32(self.topRight.count)))]
    }

    func randomBottomRight() -> SparkTrajectory {
        return self.bottomRight[Int(arc4random_uniform(UInt32(self.bottomRight.count)))]
    }
}

I’ve named this firework a classic firework. Added a protocol for abstract spark trajectory factory, and a protocol for classic spark trajectory factory to be able to replace the classic factory with another factory.

As I mentioned before there are trajectories for two quarters I’ve created using desmos tool, and later on we’ll ask for a trajectory in a specific quarter top or bottom right.

Important notice: The y-axis* values are flipped, so if desmos tool presents positive value on Y-axis you should flip it to negative because of coordinates system in iOS - lower value closer the top of the screen.

Also it is worth to mention that for simplicity of later calculation each trajectory starts at (0, 0).

We have trajectories now. Let’s create a visual representation of a spark. Spark for classic firework will be a circle that has a color. Keeping the implementation more abstract will allow to create different spark views, e.g. with ducks images, or with pusheen cats in no time :)

class SparkView: UIView {}

final class CircleColorSparkView: SparkView {

    init(color: UIColor, size: CGSize) {
        super.init(frame: CGRect(origin: .zero, size: size))
        self.backgroundColor = color
        self.layer.cornerRadius = self.frame.width / 2.0
    }

    required init?(coder aDecoder: NSCoder) {
        super.init(coder: aDecoder)
    }
}

extension UIColor {

    static var sparkColorSet1: [UIColor] = {
        return [
            UIColor(red:0.89, green:0.58, blue:0.70, alpha:1.00),
            UIColor(red:0.96, green:0.87, blue:0.62, alpha:1.00),
            UIColor(red:0.67, green:0.82, blue:0.94, alpha:1.00),
            UIColor(red:0.54, green:0.56, blue:0.94, alpha:1.00),
        ]
    }()
}

To create a spark view we need a factory and a data to fill a factory with. Basic data is a size of a spark and a index of a spark which defines what spark it is in a firework (for randomness).

protocol SparkViewFactoryData {

    var size: CGSize { get }
    var index: Int { get }
}

protocol SparkViewFactory {

    func create(with data: SparkViewFactoryData) -> SparkView
}

class CircleColorSparkViewFactory: SparkViewFactory {

    var colors: [UIColor] {
        return UIColor.sparkColorSet1
    }

    func create(with data: SparkViewFactoryData) -> SparkView {
        let color = self.colors[data.index % self.colors.count]
        return CircleColorSparkView(color: color, size: data.size)
    }
}

You can see that implementation of spark that look like pusheen cat should be easy. Let’s build a classic firework.

typealias FireworkSpark = (sparkView: SparkView, trajectory: SparkTrajectory)

protocol Firework {

    /// Defines origin of firework.
    var origin: CGPoint { get set }

    /// Defines trajectory scale. Trajectory is normalized so it needs to be scaled up
    /// before presenting on screen.
    var scale: CGFloat { get set }

    /// Defines size of a single spark.
    var sparkSize: CGSize { get set }

    /// Returns trajectories
    var trajectoryFactory: SparkTrajectoryFactory { get }

    /// Returns spark views
    var sparkViewFactory: SparkViewFactory { get }

    func sparkViewFactoryData(at index: Int) -> SparkViewFactoryData
    func sparkView(at index: Int) -> SparkView
    func trajectory(at index: Int) -> SparkTrajectory
}

extension Firework {

    /// Helper method that return spark view and corresponding trajectory.
    func spark(at index: Int) -> FireworkSpark {
        return FireworkSpark(self.sparkView(at: index), self.trajectory(at: index))
    }
}

Here is a abstract of a firework. To instantiate a firework what it needs:

origin,
scale,
sparkSize
trajectoryFactory
sparkViewFactory

Before we go to classic implementation there is this concept of scaling trajectory that I didn’t mention before. As a spark trajectory is normalized and values of their points are close to <-1, 1> or similar, we want them to be proper size when spark is following the path. We have to scale the path up to cover bigger part of a screen. Also, we need to be able to flip a path horizontally so we can get trajectories for a left part of a classic spark, and be able to shift entire path a bit in specified direction (just for randomness and better control). Here are two methods that help us achieve the goal. I believe it’s self-explanatory.

extension SparkTrajectory {

    /// Scales a trajectory so it fits to a UI requirements in terms of size of a trajectory.
    /// Use it after all other transforms have been applied and before `shift`.
    func scale(by value: CGFloat) -> SparkTrajectory {
        var copy = self
        (0..<self.points.count).forEach { copy.points[$0].multiply(by: value) }
        return copy
    }

    /// Flips trajectory horizontally
    func flip() -> SparkTrajectory {
        var copy = self
        (0..<self.points.count).forEach { copy.points[$0].x *= -1 }
        return copy
    }

    /// Shifts a trajectory by (x, y). Applies to each point.
    /// Use it after all other transformations have been applied and after `scale`.
    func shift(to point: CGPoint) -> SparkTrajectory {
        var copy = self
        let vector = CGVector(dx: point.x, dy: point.y)
        (0..<self.points.count).forEach { copy.points[$0].add(vector: vector) }
        return copy
    }
}

Okay, classic firework then.

class ClassicFirework: Firework {

    /**
     x     |     x
        x  |   x
           |
     ---------------
         x |  x
       x   |
           |     x
     **/

    private struct FlipOptions: OptionSet {

        let rawValue: Int

        static let horizontally = FlipOptions(rawValue: 1 << 0)
        static let vertically = FlipOptions(rawValue: 1 << 1)
    }

    private enum Quarter {

        case topRight
        case bottomRight
        case bottomLeft
        case topLeft
    }

    var origin: CGPoint
    var scale: CGFloat
    var sparkSize: CGSize

    var maxChangeValue: Int {
        return 10
    }

    var trajectoryFactory: SparkTrajectoryFactory {
        return ClassicSparkTrajectoryFactory()
    }

    var classicTrajectoryFactory: ClassicSparkTrajectoryFactoryProtocol {
        return self.trajectoryFactory as! ClassicSparkTrajectoryFactoryProtocol
    }

    var sparkViewFactory: SparkViewFactory {
        return CircleColorSparkViewFactory()
    }

    private var quarters = [Quarter]()

    init(origin: CGPoint, sparkSize: CGSize, scale: CGFloat) {
        self.origin = origin
        self.scale = scale
        self.sparkSize = sparkSize
        self.quarters = self.shuffledQuarters()
    }

    func sparkViewFactoryData(at index: Int) -> SparkViewFactoryData {
        return DefaultSparkViewFactoryData(size: self.sparkSize, index: index)
    }

    func sparkView(at index: Int) -> SparkView {
        return self.sparkViewFactory.create(with: self.sparkViewFactoryData(at: index))
    }

    func trajectory(at index: Int) -> SparkTrajectory {
        let quarter = self.quarters[index]
        let flipOptions = self.flipOptions(for: quarter)
        let changeVector = self.randomChangeVector(flipOptions: flipOptions, maxValue: self.maxChangeValue)
        let sparkOrigin = self.origin.adding(vector: changeVector)
        return self.randomTrajectory(flipOptions: flipOptions).scale(by: self.scale).shift(to: sparkOrigin)
    }

    private func flipOptions(`for` quarter: Quarter) -> FlipOptions {
        var flipOptions: FlipOptions = []
        if quarter == .bottomLeft || quarter == .topLeft {
            flipOptions.insert(.horizontally)
        }

        if quarter == .bottomLeft || quarter == .bottomRight {
            flipOptions.insert(.vertically)
        }

        return flipOptions
    }

    private func shuffledQuarters() -> [Quarter] {
        var quarters: [Quarter] = [
            .topRight, .topRight,
            .bottomRight, .bottomRight,
            .bottomLeft, .bottomLeft,
            .topLeft, .topLeft
        ]

        var shuffled = [Quarter]()
        for _ in 0..<quarters.count {
            let idx = Int(arc4random_uniform(UInt32(quarters.count)))
            shuffled.append(quarters[idx])
            quarters.remove(at: idx)
        }

        return shuffled
    }

    private func randomTrajectory(flipOptions: FlipOptions) -> SparkTrajectory {
        var trajectory: SparkTrajectory

        if flipOptions.contains(.vertically) {
            trajectory = self.classicTrajectoryFactory.randomBottomRight()
        } else {
            trajectory = self.classicTrajectoryFactory.randomTopRight()
        }

        return flipOptions.contains(.horizontally) ? trajectory.flip() : trajectory
    }

    private func randomChangeVector(flipOptions: FlipOptions, maxValue: Int) -> CGVector {
        let values = (self.randomChange(maxValue), self.randomChange(maxValue))
        let changeX = flipOptions.contains(.horizontally) ? -values.0 : values.0
        let changeY = flipOptions.contains(.vertically) ? values.1 : -values.0
        return CGVector(dx: changeX, dy: changeY)
    }

    private func randomChange(_ maxValue: Int) -> CGFloat {
        return CGFloat(arc4random_uniform(UInt32(maxValue)))
    }
}

Most of the code is implementation of a Firework protocol so it should be easy to understand. We pass correct factories here and there and using additional enums we random a trajectory for each spark.

There are few methods to add some randomness in terms of origin of a firework and origin of a single spark.

Also there is a concept of a quarter. There is an array of these and it is shuffled to make sure we do not always create sparks in the same quarters in the same quantity.

Okay, we’ve got the firework. How can we animate sparks then? Here comes a concept of spark animator.

protocol SparkViewAnimator {

    func animate(spark: FireworkSpark, duration: TimeInterval)
}

What it does it takes a spark tuple which is a spark view and its trajectory as well as animation duration. Whatever happens in the method is up to us. My implementation is quite big but it just do three things: make the spark view follow the trajectory, scales it up and down (with some randomness), and finally changes it’s opacity. Simple. Also because of keeping this SparkViewAnimator abstract we can simply use different animators as we wish.

struct ClassicFireworkAnimator: SparkViewAnimator {

    func animate(spark: FireworkSpark, duration: TimeInterval) {
        spark.sparkView.isHidden = false // show previously hidden spark view

        CATransaction.begin()

        // Position
        let positionAnim = CAKeyframeAnimation(keyPath: "position")
        positionAnim.path = spark.trajectory.path.cgPath
        positionAnim.calculationMode = kCAAnimationLinear
        positionAnim.rotationMode = kCAAnimationRotateAuto
        positionAnim.duration = duration

        // Scale
        let randomMaxScale = 1.0 + CGFloat(arc4random_uniform(7)) / 10.0
        let randomMinScale = 0.5 + CGFloat(arc4random_uniform(3)) / 10.0

        let fromTransform = CATransform3DIdentity
        let byTransform = CATransform3DScale(fromTransform, randomMaxScale, randomMaxScale, randomMaxScale)
        let toTransform = CATransform3DScale(CATransform3DIdentity, randomMinScale, randomMinScale, randomMinScale)
        let transformAnim = CAKeyframeAnimation(keyPath: "transform")

        transformAnim.values = [
            NSValue(caTransform3D: fromTransform),
            NSValue(caTransform3D: byTransform),
            NSValue(caTransform3D: toTransform)
        ]

        transformAnim.duration = duration
        transformAnim.timingFunction = CAMediaTimingFunction(name: kCAMediaTimingFunctionEaseOut)
        spark.sparkView.layer.transform = toTransform

        // Opacity
        let opacityAnim = CAKeyframeAnimation(keyPath: "opacity")
        opacityAnim.values = [1.0, 0.0]
        opacityAnim.keyTimes = [0.95, 0.98]
        opacityAnim.duration = duration
        spark.sparkView.layer.opacity = 0.0

        // Group
        let groupAnimation = CAAnimationGroup()
        groupAnimation.animations = [positionAnim, transformAnim, opacityAnim]
        groupAnimation.duration = duration

        CATransaction.setCompletionBlock({
            spark.sparkView.removeFromSuperview()
        })

        spark.sparkView.layer.add(groupAnimation, forKey: "spark-animation")

        CATransaction.commit()
    }
}

With the code presented we should be able to present firework on a specific view. I took it one step further and created a ClassicFireworkController that will manage all the work and let us make a single call to launch a firework.

This firework controller do one more thing. It can change a zPosition of a firework, so if we have a button it can launch some sparks behind and ahead of it for better look.

class ClassicFireworkController {

    var sparkAnimator: SparkViewAnimator {
        return ClassicFireworkAnimator()
    }

    func createFirework(at origin: CGPoint, sparkSize: CGSize, scale: CGFloat) -> Firework {
        return ClassicFirework(origin: origin, sparkSize: sparkSize, scale: scale)
    }

    /// It allows fireworks to explodes in close range of corners of a source view
    func addFireworks(count fireworksCount: Int = 1,
                      sparks sparksCount: Int,
                      around sourceView: UIView,
                      sparkSize: CGSize = CGSize(width: 7, height: 7),
                      scale: CGFloat = 45.0,
                      maxVectorChange: CGFloat = 15.0,
                      animationDuration: TimeInterval = 0.4,
                      canChangeZIndex: Bool = true) {
        guard let superview = sourceView.superview else { fatalError() }

        let origins = [
            CGPoint(x: sourceView.frame.minX, y: sourceView.frame.minY),
            CGPoint(x: sourceView.frame.maxX, y: sourceView.frame.minY),
            CGPoint(x: sourceView.frame.minX, y: sourceView.frame.maxY),
            CGPoint(x: sourceView.frame.maxX, y: sourceView.frame.maxY),
            ]

        for _ in 0..<fireworksCount {
            let idx = Int(arc4random_uniform(UInt32(origins.count)))
            let origin = origins[idx].adding(vector: self.randomChangeVector(max: maxVectorChange))

            let firework = self.createFirework(at: origin, sparkSize: sparkSize, scale: scale)

            for sparkIndex in 0..<sparksCount {
                let spark = firework.spark(at: sparkIndex)
                spark.sparkView.isHidden = true
                superview.addSubview(spark.sparkView)

                if canChangeZIndex {
                    let zIndexChange: CGFloat = arc4random_uniform(2) == 0 ? -1 : +1
                    spark.sparkView.layer.zPosition = sourceView.layer.zPosition + zIndexChange
                } else {
                    spark.sparkView.layer.zPosition = sourceView.layer.zPosition
                }

                self.sparkAnimator.animate(spark: spark, duration: animationDuration)
            }
        }
    }

    private func randomChangeVector(max: CGFloat) -> CGVector {
        return CGVector(dx: self.randomChange(max: max), dy: self.randomChange(max: max))
    }

    private func randomChange(max: CGFloat) -> CGFloat {
        return CGFloat(arc4random_uniform(UInt32(max))) - (max / 2.0)
    }
}

This controller does few things. It random a corner of a button to present a firework at. It adds some randomness to firework origin and create requested number of fireworks and sparks. Then it adds sparks to a source view, adjusts zIndex if possible and run the animator.

Almost all parameters have default value so you don’t need to care about them. You can call the controller just with this:

self.fireworkController.addFireworks(count: 2, sparks: 8, around: button)

And voilà!

From this point it is easy to get a new type of firework that works like the following one. You just need to define new trajectories, create new firework and implement them to launch sparks as you wish. Putting all this code together in a controller simplifies launching fireworks wherever you want :) Or you can use a fountain firework I’ve included in tomkowz/fireworks on github.

Wrap up

Wasn’t easy but wasn’t difficult too. With proper analysis of the problem (or effect in that case) we can break it down to small pieces and put it together one piece at a time. Hopefully I’ll have a chance to use this effect in a future project 🎉

That’s it for today. Thanks for reading!

How do I build a Network Layer

Sat, 30 Jul 2016 19:00:00 +0000

Working and leading two projects at a time means a great opportunity to experiment with app architecture, and do experiments with other concepts I had in mind or just learned and wanted to try them out. One of topics I learned recently and I think you might find it useful if how I build a network layer now.

Nowadays mobile apps are client-server oriented, so pretty much there is a network layer somewhere in the app, smaller or bigger. I saw many implementations to date but every had some drawbacks. Not thinking the latest one I build has no drawbacks, but it seems to work very well in two projects I am working on currently. And has test coverage close to 100%.

In this article we’ll cover network layer that talks only with one backend, sending JSON encoded requests, so not that complex. The layer will talk with AWS later on and send some files there, but it should be easy to extend its functionality to do so.

Thinking process

Here are some questions I like to ask myself before building such a layer.

Where to put the code that have knowledge about the backend url?
Where to put the code that knows about the endpoints?
Where to put the code that knows how to build a request?
Where to keep all the code that cares about preparing parameters for a request?
Where should I store authentication token?
How to execute requests?
When and where to execute requests?
Do I care about cancelling requests?
Do I need to care about wrong backend responses? Some backend bugs?
Do I need to use 3rd party frameworks? What frameworks should I use?
Is there any core data stuff passing around?
How to test the solution?

Storing backend url

First of all, where should I put the backend url? How other piece of the system will know where to send requests? I prefer to create a BackendConfiguration class that stores such information.

import Foundation

public final class BackendConfiguration {

    let baseURL: NSURL

    public init(baseURL: NSURL) {
        self.baseURL = baseURL
    }

    public static var shared: BackendConfiguration!
}

Easy to test, easy to configure. You can set the shared static variable and access it wherever you want in your network layer, no need to pass it everywhere.

let backendURL = NSURL(string: "https://szulctomasz.com")!
BackendConfiguration.shared = BackendConfiguration(baseURL: backendURL)

Endpoints

That’s the topic I experimented with for a while before I found a ready-to-go solution. Tried hardcoding endpoints while configuring NSURLSession, tried some dummy Resource-like objects that knows about the endpoint and can be easily instantiated and injected, but it was still not what I was looking for.

I came up with idea to create *Request object that knows which endpoint to hit, what method to use, should it be GET, POST, PUT or different, how to configure the body of a request and what headers to pass.

This is what I came up with

protocol BackendAPIRequest {
    var endpoint: String { get }
    var method: NetworkService.Method { get }
    var parameters: [String: AnyObject]? { get }
    var headers: [String: String]? { get }
}

A class that implements the protocol is able to provide a basic informations that are required to build a request. The NetworkService.Method is just an enum with GET, POST, PUT, DELETE cases.

An example request that maps an endpoint might look like this

final class SignUpRequest: BackendAPIRequest {

    private let firstName: String
    private let lastName: String
    private let email: String
    private let password: String

    init(firstName: String, lastName: String, email: String, password: String) {
        self.firstName = firstName
        self.lastName = lastName
        self.email = email
        self.password = password
    }

    var endpoint: String {
        return "/users"
    }

    var method: NetworkService.Method {
        return .POST
    }

    var parameters: [String: AnyObject]? {
        return [
            "first_name": firstName,
            "last_name": lastName,
            "email": email,
            "password": password
        ]
    }

    var headers: [String: String]? {
        return ["Content-Type": "application/json"]
    }
}

To not create the dictionary for headers everywhere we can define extension for BackendAPIRequest.

extension BackendAPIRequest {

    func defaultJSONHeaders() -> [String: String] {
        return ["Content-Type": "application/json"]
    }
}

The *Request class takes all the parameters needed to make a successful request. You’re always sure that at least all the parameters you need will be passed, otherwise you can’t create a request object.

Defining endpoint is easy. If there should be some id of an object that should be included in the endpoint it is super easy to add it because you actually would have such id stored as a property.

private let id: String

init(id: String, ...) {
  self.id = id
}

var endpoint: String {
  return "/users/\(id)"
}

The method of the request never changes, the parameters body is easily constructed and very easy to maintain, headers too. Everything is very easy to test.

Executing the request

Do I need any 3rd party frameworks to communicate with the backend?

I see that people are using AFNetworking (Objective-C) and Alamofire for Swift. I used it many times, but for some time I am not using it. Since we’ve got NSURLSession that do its job very well I don’t think you need any 3rd party framework. IMO this dependency is going to make your app architecture more complex.

The current solution consists of two classes - NetworkService and BackendService.

NetworkService - allows you to execute HTTP request, it incorporates NSURLSession internally. Every network service can execute just one request at a time, can cancel the request (big advantage), and has callbacks for success and failure responses.
BackendService - (Not the coolest name ever but fits quite well) is the class that takes requests (*Request objects described above) related to the backend. It uses NetworkService internally. In the current version I am using, it tries to serialize the response data to json using NSJSONSerializer.

class NetworkService {

    private var task: NSURLSessionDataTask?
    private var successCodes: Range<Int> = 200..<299
    private var failureCodes: Range<Int> = 400..<499

    enum Method: String {
        case GET, POST, PUT, DELETE
    }

    func request(url url: NSURL, method: Method,
                 params: [String: AnyObject]? = nil,
                 headers: [String: String]? = nil,
                 success: (NSData? -> Void)? = nil,
                 failure: ((data: NSData?, error: NSError?, responseCode: Int) -> Void)? = nil) {

        let mutableRequest = NSMutableURLRequest(URL: url, cachePolicy: .ReloadIgnoringLocalAndRemoteCacheData,
                                                 timeoutInterval: 10.0)
        mutableRequest.allHTTPHeaderFields = headers
        mutableRequest.HTTPMethod = method.rawValue
        if let params = params {
            mutableRequest.HTTPBody = try! NSJSONSerialization.dataWithJSONObject(params, options: [])
        }

        let session = NSURLSession.sharedSession()
        task = session.dataTaskWithRequest(mutableRequest, completionHandler: { data, response, error in
            // Decide whether the response is success or failure and call
            // proper callback.
        })

        task?.resume()
    }

    func cancel() {
        task?.cancel()
    }
}

class BackendService {

    private let conf: BackendConfiguration
    private let service: NetworkService!

    init(_ conf: BackendConfiguration) {
        self.conf = conf
        self.service = NetworkService()
    }

    func request(request: BackendAPIRequest,
                 success: (AnyObject? -> Void)? = nil,
                 failure: (NSError -> Void)? = nil) {

        let url = conf.baseURL.URLByAppendingPathComponent(request.endpoint)

        var headers = request.headers
        // Set authentication token if available.
        headers?["X-Api-Auth-Token"] = BackendAuth.shared.token

        service.request(url: url, method: request.method, params: request.parameters, headers: headers, success: { data in
            var json: AnyObject? = nil
            if let data = data {
                json = try? NSJSONSerialization.JSONObjectWithData(data, options: [])
            }
            success?(json)

            }, failure: { data, error, statusCode in
                // Do stuff you need, and call failure block.
        })
    }

    func cancel() {
        service.cancel()
    }
}

As you can see the BackendService can set authentication token in headers. The BackendAuth objects is a simple storage that stores the token in NSUserDefaults. If that would be necessary it could be storing the token in Keychain.

The BackendService takes BackendAPIRequest as a parameter of request(_:success:failure:) method and extracts necessary informations from the request object. This is nicely encapsulated and backend service just consumes what it gets.

public final class BackendAuth {

    private let key = "BackendAuthToken"
    private let defaults: NSUserDefaults

    public static var shared: BackendAuth!

    public init(defaults: NSUserDefaults) {
        self.defaults = defaults
    }

    public func setToken(token: String) {
        defaults.setValue(token, forKey: key)
    }

    public var token: String? {
        return defaults.valueForKey(key) as? String
    }

    public func deleteToken() {
        defaults.removeObjectForKey(key)
    }
}

Both NetworkService, BackendService and BackendAuth are easy to test and maintain.

Queueing requests

Several questions to cover here. What way would we like to perform network requests? What if we want to perform many requests at a time? How would we like to be notified about the success or failure for requests in general?

Decided to go with NSOperationQueue and NSOperations that execute network requests.

So, I subclassed NSOperation and overrided its asynchronous property to return true.

public class NetworkOperation: NSOperation {

    private var _ready: Bool
    public override var ready: Bool {
        get { return _ready }
        set { update({ self._ready = newValue }, key: "isReady") }
    }

    private var _executing: Bool
    public override var executing: Bool {
        get { return _executing }
        set { update({ self._executing = newValue }, key: "isExecuting") }
    }

    private var _finished: Bool
    public override var finished: Bool {
        get { return _finished }
        set { update({ self._finished = newValue }, key: "isFinished") }
    }

    private var _cancelled: Bool
    public override var cancelled: Bool {
        get { return _cancelled }
        set { update({ self._cancelled = newValue }, key: "isCancelled") }
    }

    private func update(change: Void -> Void, key: String) {
        willChangeValueForKey(key)
        change()
        didChangeValueForKey(key)
    }

    override init() {
        _ready = true
        _executing = false
        _finished = false
        _cancelled = false
        super.init()
        name = "Network Operation"
    }

    public override var asynchronous: Bool {
        return true
    }

    public override func start() {
        if self.executing == false {
            self.ready = false
            self.executing = true
            self.finished = false
            self.cancelled = false
        }
    }

    /// Used only by subclasses. Externally you should use `cancel`.
    func finish() {
        self.executing = false
        self.finished = true
    }

    public override func cancel() {
        self.executing = false
        self.cancelled = true
    }
}

Next, because I want to use the BackendService for executing network calls I subclassed NetworkOperation and created ServiceOperation.

public class ServiceOperation: NetworkOperation {

    let service: BackendService

    public override init() {
        self.service = BackendService(BackendConfiguration.shared)
        super.init()
    }

    public override func cancel() {
        service.cancel()
        super.cancel()
    }
}

The class creates BackendService internally so I don’t need to create it in its every subclass.

Here is how the Sign In operation might look like:

public class SignInOperation: ServiceOperation {

    private let request: SignInRequest

    public var success: (SignInItem -> Void)?
    public var failure: (NSError -> Void)?

    public init(email: String, password: String) {
        request = SignInRequest(email: email, password: password)
        super.init()
    }

    public override func start() {
        super.start()
        service.request(request, success: handleSuccess, failure: handleFailure)
    }

    private func handleSuccess(response: AnyObject?) {
        do {
            let item = try SignInResponseMapper.process(response)
            self.success?(item)
            self.finish()
        } catch {
            handleFailure(NSError.cannotParseResponse())
        }
    }

    private func handleFailure(error: NSError) {
        self.failure?(error)
        self.finish()
    }
}

In the start method the service executes request that is created internally in the operation’s constructor. handleSuccess and handleFailure methods are passed as a callbacks for request(_:success:failure:) method of a service. IMO this makes the code more clean, and it is still readable.

Operations are passed to a NetworkQueue object that is a singleton and can queue every operation. For now I keep it as simple as possible:

public class NetworkQueue {

    public static var shared: NetworkQueue!

    let queue = NSOperationQueue()

    public init() {}

    public func addOperation(op: NSOperation) {
        queue.addOperation(op)
    }
}

What are advantages of executing operations in one place?

Easily cancellation of all network operations.
Cancellation all operations that are downloading images or other operations that are requesting data that is not needed to provide user a basic experience of using the app while network connection is weak. E.g. you would like to prevent downloading images when user is on weak connection.
You can build a priority queue and execute some requests first to get answer faster.

Working with Core Data

This is the aspect for which I had to delay the publication of this entry. In previous version of the network layer operations returned Core Data objects. The response was received, parsed and converted to Core Data object. This solution was far from ideal.

The operation have to know what Core Data is. Because I had model detached to separate framework and network layer was in separate framework too, the network framework have to know about model framework.
Each operation have to take additional NSManagedObjectContext parameter to know which context it should operate on.
Each time the response was received and was about to call success block it first tried to find object in a context, or hit the disk to fetch object from disk. IMO this is a big disadvantage. You not always want to create Core Data object.

So I came with idea to take out Core Data out of network layer completely. I created middle layer that are objects created in result of parsing responses.

This way the parsing and creating objects is quick and not require to hit a disk.
You also don’t need to pass NSManagedObjectContext to operation.
You can update your core data object in the success block using the parsed item and reference to Core Data object that you probably keep somewhere where you create the operation - this is my case in most situations when the operation is added to a queue.

Mapping responses

The idea of response mappers was to separate the logic of parsing and mapping JSON to useful items.

We can distinguish two type of parsers. The first type return just a single object of specific type. The second type is a parser that parses array of such items.

First, let’s define a common protocol for all the items:

public protocol ParsedItem {}

Now, here are some objects that are products of mappers:

public struct SignInItem: ParsedItem {

    public let token: String
    public let uniqueId: String
}

public struct UserItem: ParsedItem {

    public let uniqueId: String
    public let firstName: String
    public let lastName: String
    public let email: String
    public let phoneNumber: String?
}

Let’s define an error type that will be thrown when something went wrong with parsing.

internal enum ResponseMapperError: ErrorType {
    case Invalid
    case MissingAttribute
}

Invalid - thrown when passed json is nil and should not be nil, or when it is array of objects instead of expected json with a single object.
MissingAttribute - self explanatory, when key is missing in json or when after parsing the value is nil and should not be.

A ResponseMapper may look like this

class ResponseMapper<A: ParsedItem> {

    static func process(obj: AnyObject?, parse: (json: [String: AnyObject]) -> A?) throws -> A {
        guard let json = obj as? [String: AnyObject] else { throw ResponseMapperError.Invalid }
        if let item = parse(json: json) {
            return item
        } else {
            L.log("Mapper failure (\(self)). Missing attribute.")
            throw ResponseMapperError.MissingAttribute
        }
    }
}

It takes an obj which is response from the backend - a JSON in our case, and a parse method which consumes this obj and returns A object that conforms to ParsedItem.

Now that we have this generic mapper we can create concrete mappers. Let’s take a look on a mapper used for parsing response of Sign In operation.

protocol ResponseMapperProtocol {
    associatedtype Item
    static func process(obj: AnyObject?) throws -> Item
}

final class SignInResponseMapper: ResponseMapper<SignInItem>, ResponseMapperProtocol {

    static func process(obj: AnyObject?) throws -> SignInItem {
        return try process(obj, parse: { json in
            let token = json["token"] as? String
            let uniqueId = json["unique_id"] as? String
            if let token = token, let uniqueId = uniqueId {
                return SignInItem(token: token, uniqueId: uniqueId)
            }
            return nil
        })
    }
}

The ResponseMapperProtocol is a protocol to be implemented by concrete mappers so they share the same method for parsing response.

Then, such a mapper is used in a success block of an operation and you can operate on concrete object of specific type instead of dictionary. Easy to use such object later, evertything is easy to test.

The last thing is a response mapper for parsing arrays.

final class ArrayResponseMapper<A: ParsedItem> {

    static func process(obj: AnyObject?, mapper: (AnyObject? throws -> A)) throws -> [A] {
        guard let json = obj as? [[String: AnyObject]] else { throw ResponseMapperError.Invalid }

        var items = [A]()
        for jsonNode in json {
            let item = try mapper(jsonNode)
            items.append(item)
        }
        return items
    }
}

It takes a mapping function and return array of items if everything is correctly parsed. Depends on what you expect you might throw an error if just a single item can’t be parsed or return empty array in worst case as a product of this mapper. The mapper expects that the obj (response from the backend) is an array of JSON elements.

Here is diagram that presents the network layer architecture.

Example project

You can find an example project here on my github. The project is using fake url for the backend, so no request will finish with success. I made this available only to give you a view of how the foundation of the network layer look like.

Wrap up

I found this way of doing network layer very useful, simple and easy to work with.

The biggest advantage of it is that you can easily add new operations that will have similar design to others and that it does not know anything about Core Data.
You can keep the code coverage close to 100% with no big effort, without thinking how to cover a super hard cases, because there is no such cases at all.
The core of it is easy to reuse in other applications that have similar complexity.

Custom View Controller transition by expanding view

Sat, 14 May 2016 19:00:00 +0000

I was looking for inspirations on dribbble and found a work that shows nice transition between view controllers by expanding a view (e.g. a button) in every direction. You can find it here: Login & Home Screen.

It is more like Android material design style animation, but I think it may fit nicely in any onboarding process animations.

The animation

Let’s disassemble this animation.

There is a view that is a source of animation. Let’s call it expandable view. In this work on dribbble the expandable view view is a “Sign in” button. (I’ll simplify it and just use button that is ready to be scaled. You could use additional delegate to notify the expandable view that it should prepare for being expanded - It could also implement Expandable protocol or something similar)
When user taps the button, the first step is to change the appearance of the expandable view. The view is about to scale to fill entire screen, so everthing that would not look good is removed from the view. In this case this is loading spinner and plus sign that is removed from the view. The only thing that will be scaling is simple circle button with solid background.
The next step is the scaling process itself. The button expands so it fills entire screen.
After view expanded quickly next view controller is presented by simple fade.

Custom transitions in iOS

One way to approach the problem is to create custom transition animation. This can be done by UIViewControllerAnimatedTransitioning and UIViewControllerTransitioningDelegate protocols.

UIViewControllerAnimatedTransitioning - The protocol is used by animator, the class that knows how the animation look like.

UIViewControllerTransitioningDelegate - The protocol is used by transitioning delegate. It knows what is the total length of the animation and can instantiate and return animators for both presenting and dismissing view controllers.

In this case I’ll only care about presenting animation.

Example project

You can find demo project in ExpandingViewTransition-Demo repository on github.

Transitioning delegate

At first, we have to create transitioning delegate that will return animators for presenting and dismissing view controller (we care only about presenting now).

import UIKit

class ExpandingViewTransition: NSObject, UIViewControllerTransitioningDelegate {

    private let expandableView: UIView
    private let expandViewAnimationDuration: NSTimeInterval
    private let presentVCAnimationDuration: NSTimeInterval

    init(expandingView: UIView,
         expandViewAnimationDuration: NSTimeInterval = 0.35,
         presentVCAnimationDuration: NSTimeInterval = 0.35) {
        self.expandableView = expandingView
        self.expandViewAnimationDuration = expandViewAnimationDuration
        self.presentVCAnimationDuration = presentVCAnimationDuration
    }

    func animationControllerForPresentedController(
        presented: UIViewController,
        presentingController presenting: UIViewController,
                             sourceController source: UIViewController) -> UIViewControllerAnimatedTransitioning? {

        return ExpandingViewTransitionAnimatorPresent(expandableView: self.expandableView,
                                                      expandViewAnimationDuration: self.expandViewAnimationDuration,
                                                      presentVCAnimationDuration: self.presentVCAnimationDuration)
    }

    func animationControllerForDismissedController(
        dismissed: UIViewController) -> UIViewControllerAnimatedTransitioning? {
        return nil
    }
}

The init(expandableView:expandViewAnimationDuration:presentVCAnimationDuration:) takes reference to view that will be expanded (button), and animation durations that specifies how long expanding process is and how long is fade of destination view controller after expandable view is fully expanded.

Two remaining methods are the one from UIViewControllerTransitioningDelegate. First returns ExpandingViewTransitionAnimatorPresent animator which is used to present new view controller.

Second method returns nil as we don’t care about dismissing animation. Default dismiss animation will be used in this case.

Animator

The foundation of animator look like this.

class ExpandingViewTransitionAnimatorPresent: NSObject, UIViewControllerAnimatedTransitioning {
  private let expandableView: UIView
  private let expandViewAnimationDuration: NSTimeInterval
  private let presentVCAnimationDuration: NSTimeInterval

  init (expandableView: UIView,
        expandViewAnimationDuration: NSTimeInterval,
        presentVCAnimationDuration: NSTimeInterval) {
      self.expandableView = expandableView
      self.expandViewAnimationDuration = expandViewAnimationDuration
      self.presentVCAnimationDuration = presentVCAnimationDuration
  }

  func transitionDuration(transitionContext: UIViewControllerContextTransitioning?) -> NSTimeInterval {
      return self.expandViewAnimationDuration + self.presentVCAnimationDuration
  }

  func animateTransition(transitionContext: UIViewControllerContextTransitioning) {
      // ...
  }
}

The first thing is to calculate how much the expandable view should expand. The idea is simple. We need to check how far the view is from the edges of the screen, take the longest distance and use it to calculate scale that should be applied.

After we find such maximal offset, then we look for the biggest dimension of the expandable view and for longest dimension of the source view controller which should be full screen - I think we could use dimension of UIScreen.mainScreen().bounds too. It might work even better for some cases.

With such informations we’re able to calculate new scale properly.

/**
 The method calculates a scale that expandable view should transform to
 in order to fill entire screen no matter where it is located on the screen.
 */
private func calculateFinalTransformOfExpandingViewInSourceVC(
    expandingView: UIView,
    sourceVC: UIViewController) -> CGAffineTransform {

    // left, right, top, bottom
    let offsets = [expandingView.frame.origin.x,
                   sourceVC.view.bounds.width - expandingView.frame.origin.x,
                   expandingView.frame.origin.y,
                   sourceVC.view.bounds.height - expandingView.frame.origin.y]

    let minExpandingViewDim = min(expandableView.bounds.width,
                                  expandableView.bounds.height)

    let maxOffsetVal = offsets.maxElement()!
    let maxSourceDim = max(sourceVC.view.bounds.width,
                           sourceVC.view.bounds.height)

    // to make sure that source is filled by `expandingView`
    // especially if the view has rounded edges
    let threshold_scale: CGFloat = 2

    let scale = (maxSourceDim + maxOffsetVal) / minExpandingViewDim + threshold_scale
    return CGAffineTransformMakeScale(scale, scale)
}

Here is how the transition code look like.

func animateTransition(transitionContext: UIViewControllerContextTransitioning) {
    /**
     Transitions involves:
     - adding source and destination view controller to the container view
     - transforming expandable view so it fills entire screen
     - finally displaying the destination view controller
     - bringing back previous state of expandable view
     */

    let sourceVC = transitionContext.viewControllerForKey(UITransitionContextFromViewControllerKey)!

    let destinationVC = transitionContext.viewControllerForKey(UITransitionContextToViewControllerKey)!
    destinationVC.modalPresentationStyle = .Custom
    destinationVC.view.alpha = 0

    let containerView = transitionContext.containerView()!
    containerView.addSubview(sourceVC.view)
    containerView.addSubview(destinationVC.view)

    let beginZPosition = self.expandableView.layer.zPosition
    let beginTransform = self.expandableView.transform

    let finalTransform = calculateFinalTransformOfExpandingViewInSourceVC(self.expandableView, sourceVC: sourceVC)

    self.expandableView.layer.zPosition = CGFloat.max - 1

    UIView.animateWithDuration(self.expandViewAnimationDuration, delay: 0, options: .CurveEaseIn, animations: {
        self.expandableView.transform = finalTransform
        }, completion: { _ in
            UIView.animateWithDuration(self.presentVCAnimationDuration, animations: {
                destinationVC.view.alpha = 1
                }, completion: { _ in
                    self.expandableView.transform = beginTransform
                    self.expandableView.layer.zPosition = beginZPosition

                    transitionContext.completeTransition(true)
            })
    })
}

Using UITransitionContextFromViewControllerKey and UITransitionContextToViewControllerKey keys, we can obtain source and destination view controllers via viewControllerForKey method.

Then as documentation says presentation style of destination view controller is set to custom - destinationVC.modalPresentationStyle = .Custom.

Animator provides us containerView via transitionContext - see UIViewControllerContextTransitioning for details. Source and destination view controllers are added to this container view.

We have to store somewhere begin state of zPosition and layer.transform of expandable view so we can bring it back to the state before scaling.

After this there is just simple animation of a transform of expandable view and after this finished, the destination view controller is presented.

After all of this is done and only destination view controller is on screen we can bring previous appearance of the expandable view.

When everything is done you have to mark that the transition completed.

transitionContext.completeTransition(true)

How to use it?

Here is one way you can use it programatically:

@IBAction func doAnimate(sender: UIView) {

    let transitionDelegate = ExpandingViewTransition(expandingView: sender,
                                                     expandViewAnimationDuration: 0.4,
                                                     presentVCAnimationDuration: 0.1)

    let storyboard = UIStoryboard(name: "Main", bundle: nil)

    let vc = storyboard.instantiateViewControllerWithIdentifier("SecondViewController")
    vc.transitioningDelegate = transitionDelegate

    self.presentViewController(vc, animated: true, completion: nil)
}

Initialization process of a view loaded from a storyboard

Fri, 21 Aug 2015 19:00:00 +0000

This post is continuation of the “UIViewController’s view loading process demystified” post I’ve wrote some time ago. I’d like to cover how custom view is loaded when it is placed in a storyboard.

There are several ways to add view to a view controller. You can put it in storyboard or you can create it in code and add as subview of view controller’s view.

I sat down and spent some time on debugging, trying to maybe find something useful and to learn about entire process of creating and presenting view. And here are my findings.

View without subviews loaded from a storyboard

Let’s say there is a storyboard which has one view controller, and in the view controller there is a view which is of some subclass of UIControl, and has some constraints set, and has few IBInspectable properties defined so the properties will be loaded and set after our view is loaded.

Here is how the flow look like:

I thought here will be some magic but didn’t find any. There are two or three private methods called between public ones but do nothing special.

At first initWithCoder: is called and next is setNeedsDisplay.

All constraints of this view are set by calling addConstraints:. Here are set constraints that not determine position of a view in its superview. So, only like height and width. I thought that all constraints are set here but makes more sense that not all are set in here, because position of this view is important for its superview. When view has subviews, constraints that define position of subviews will be added to the view that contains these subviews.

Next called method is awakeAfterUsingCoder: and view is prepared to be added to superview because willMoveToSuperview: method is called and the next one is didMoveToSuperview.

After view is added to superview awakeFromNib is called. I thought that awakeFromNib is called right after awakeAfterUsingCoder even before adding view to its superview, but was wrong. awakeFromNib is important method. This is a moment when you’ve got your IBInspectable properties and key-value pairs defined in a storyboard set and ready to use. Those loaded values are available before super awakeFromNib is called. awakeFromNib is called by UINib’s instantiateWithOwner:options: method, so it loads the view, decodes and set properties and those are ready to be used.

Next willMoveToWindow and didMoveToWindow methods are called. I was a bit confused why those are called (because view is added to its superview, not to a window directly) but read documentation which says that default implementation of these methods do nothing and this is useful if you want to do additional things when view moves to another window.

When view is on screen the updateConstraints:, layoutSublayersOfLayer: and layoutSubviews: methods are called. That’s all for this case. Easy to remember.

View with subviews loaded from a storyboard

The flow is bit different because there are few subviews to add and layout.

First difference is that after initWithCoder: method is called the next one is adding subviews of this loaded view in _addSubviews:positioned:relativeTo: method. Other things to time when updateConstraints method is called stays the same. The second thing is, no matter how many views there are the setNeedsLayout method is called twice and layoutSublayersOfLayer: is also called twice.

So… Yeah, I hope it helps in understanding the flow better.

I wrote a copy of 2048 game in 10 hours and submitted to the App Store

Tue, 04 Aug 2015 19:00:00 +0000

Important notice 1: The code presented here has been written in Swift 1.2 which is no longer supported.

Important notice 2: Except of that App is no longer in the store because I haven’t time to maintain it, the rest of the article is valid. Keep reading :)

–

That was pretty effective Saturday. Writing game was an interesting process and I played a lot 2048 that day. Here are my thoughts and impressions.

I spoke with my colleague about his job interview challenge he got from one of employers from California and it was about writing 2048 game. Actually two guys did it, one in 8 hours and my colleague in 17 hours - both with different approaches in Objective-C.

I got inspired. The challenge might be good opportunity to check my Swift skills and to make me more confident about it, because I am thinking about relocating from Poland to San Francisco Bay Area next year and will be searching for a job - Want to help me? Or Hire? :)

Anyway, I decided to spend Saturday working on the app. But on entire app, not just a module to play like in the original challenge. And I planned to do it in Swift because I’m in love with Swift these days and wanted to examine my Swift skills :)

I did it in Swift 1.2 and Xcode 6.4 to be able to submit the app to the store.

Repository and the app

The project is available on GitHub. Feel free to contribute if you find something that is worth to change/improve. I am always open to new ideas.

You can find the app on the App Store - 2048 - Flat Color Version. Enjoy it!

Planning UI

I spent about hour of Friday evening drawing some UI in Sketch app. This is I think 3rd or 4th app that has been designed in Sketch by me - it is really great, I recommend it not only for designing apps, it is also great in quick prototyping and has many plugins hosted on GitHub. People care about it so much - This is not an ad, just advice :)

The UI had to be simple, just colorful tiles on some darker background. I think it looks nice - I am not UI/UX master, just software engineer with some background in 2d/3d graphics :)

Stop and think a while

Thinking about UI before implementing anything related to UI is a big thing - it is a time-saver. If you’re planning to do some UI component or entire screen in the app, something complex, just draw it first, play it on screen, maybe show to someone and then when you’re done with prototyping you can start coding. I think I saved a lot of time by drawing UI before starting coding. I had some experience with previous projects when I was prototyping and coding at the same time and it took much more time than it should.

Assets

I’ve decided to export what I can to PDF files so I could work with vectors. I recommend using PDFs - you can keep just one file of an asset instead of one per screen scale/size. I wrote about it once in PDF vectors in Assets catalog - go and read, I’ll wait.

Architecture

App is targeted to iOS 8 and newer so Launch Screen was a piece of cake as well as adding icon and implementing first screen with “new game” button.

I read a bit about MVVM some time ago and wanted to use it, at least to some extent - It was more MVCVM (Model View Controller View Model). I didn’t want to use Reactive Cocoa and similar things, I just created and used View Models to keep code that was responsible for processing/formatting content to be displayed out of view controllers. The game’s UI is simple so there are just few View Models, but in bigger project I worked on it is working great - highly recommended.

Data Structure

This is something I am proud of. I spoke with colleague after I finished the game and he told me the approach is really nice. I was writing this in Swift and I wanted to keep it really, really simple.

There are always 16 elements on the screen, Meaning, the board is 4 by 4 and it has 16 slots for tiles. So I thought about the board like about matrix that has always 16 slots and that values are appearing, disappearing and transitioning between these slots. And I’ve created something like 2048-data-structure for it.

import Foundation
import CoreGraphics

func == (lhs: Position, rhs: Position) -> Bool {
    return lhs.x == rhs.x &amp;&amp; lhs.y == rhs.y
}

struct Position: Equatable {
    var x, y: Int

    var CGPointRepresentation: CGPoint {
        return CGPointMake(CGFloat(x), CGFloat(y))
    }
}

class Tile {
    let position: Position
    var value: Int?

    var upTile: Tile?
    var rightTile: Tile?
    var bottomTile: Tile?
    var leftTile: Tile?

    init(position: Position, value: Int? = nil) {
        self.position = position
        self.value = value
    }
}

Every tile has its own constant position and it always knows its neighbor tiles. Doing this helped me a lot when I was writing logic for shifting tiles/values.

Logic and its view representation

I wanted to keep game logic out of UI. It had to be very simple class that contains all the logic and knows only about the data structure on the board and it does not even know what UIKit is. I’ve implemented it this way that there is a class named GameLogicManager which contains the whole logic and a GameBoardRenderer class which is responsible for presenting the visual part of the game on screen. It works well, at least in this case. I am wondering if this is known/popular and good solution or not. Anyway, it fits nice to this project.

So, GameLogicManager calls delegate (GameViewController) and “saying” “move tile from position X to Y”, “move tile from X onto Y” (to combine with another tile) or just “game over” or “game win”.

Messages" were passed to GameBoardRenderer which has array with TileView elements and reference to GameBoardView and was responsible for moving (animating) them on the screen.

The method that is responsible for shifting tiles on the screen took 71 lines with comments - 56 without comments - not too long. This was the hardest thing to implement and I wanted to keep it well commented and implemented in very simple way. And simple it is :) It handles shifting in 4 directions as game needs. This method was a real pain in a butt and took almost 6 hours - I’ve tried few approaches before I found best solution.

func shift(direction: ShiftDirection) {
    // Want to wait for ending one shifting before doing another which
    // can collide with currently performing.
    if updating == true { return }
    updating = true

    var performedShift = false
    for rowOrColumn in 0..<boardWidth {
        // Get all tiles in a row or column.
        var tilesToCheck = tiles.filter {
            return ((direction == .Right || direction == .Left) ? $0.position.y : $0.position.x) == rowOrColumn
        }

        // When shifting right or down array need to be reversed.
        if direction == .Right || direction == .Down {
            tilesToCheck = reverse(tilesToCheck)
        }

        var tileIndex = 0
        while tileIndex < tilesToCheck.count {
            let currentTile = tilesToCheck[tileIndex]
            // Find first tile with some value. When shifting right filter
            // seeks for tiles on the left, otherwise on the right from current tile.
            let filter: ((tile: Tile) -> Bool) = { tile in
                let position: Bool = {
                    switch direction {
                    case .Up: return tile.position.y > currentTile.position.y
                    case .Right: return tile.position.x < currentTile.position.x
                    case .Down: return tile.position.y < currentTile.position.y
                    case .Left: return tile.position.x > currentTile.position.x
                    }
                }()

                return position == true &amp;&amp; tile.value != nil
            }

            if let otherTile = tilesToCheck.filter(filter).first {
                // If value is same increase value of current tile and
                // remove value from other tile.
                if otherTile.value == currentTile.value {
                    moveOnSameTile(otherTile, onTile: currentTile)
                    // Notify about additional points because of adding up values
                    pointCount += currentTile.value!
                    // If current tile get's win tile value just end the game.
                    if currentTile.value! == winTileValue {
                        delegate?.gameLogicManagerDidWinGame()
                        return
                    }
                    delegate?.gameLogicManagerDidCountPoints(pointCount)
                    performedShift = true
                } else if currentTile.value == nil {
                    moveOnEmptyTile(otherTile, destinationTile: currentTile)
                    // if tile has been moved to another place repeat this step
                    // because maybe next tile has the same value and they
                    // should be added up.
                    tileIndex--
                    performedShift = true
                }
            }
            tileIndex++
        }
    }

    // Every shift method returns boolean value if shift has been performed on
    // some at least one tile or not.
    if performedShift {
        delegate?.gameLogicManagerDidAddTile(addRandomTile())
    }

    if isGameOver() == true { delegate?.gameLogicManagerDidGameOver() }
    updating = false
}

The rendering part was very simple and communication between logic manager and renderer too - just look into repository for details. In the last three hours I’ve finished the “Game Over” / “Game Win” screen, storing/loading high score and submitted the app to the Store :)

Conclusion

I am happy to finish the game in 10 hours. I think it is pretty good time and doing this in Swift makes me more confident about my level of understanding the language.

The challenge gave me also another thoughts about how important prototyping/problem analysis before implementation is - It could be a big time-saver - It was something like research, right?

IMO I could finish the shifting method a bit faster, like about hour faster, if I would spend 30 minutes more on thinking about the problem with paper on desk and pen in a hand, instead of testing solutions that I had in my head without testing them on a paper.

UIViewController's view loading process demystified

Mon, 03 Aug 2015 19:00:00 +0000

@NatashaTheRobot posted about testing view controllers and issues with loading views on her blog in The One Weird Trick For Testing View Controllers in Swift post.

She also wrote:

The key here is that Apple overrides the viewController’s view getter to call the loadView function and do a bunch of other things we have no access to. If anyone else has other great insights into why this works, feel free to add it in the comments!

Yeah.. this is interesting what is going on under the hood. She inspired me and I started digging and debugging a bit. I’ve noticed there are two flows - one when view controller is assigned to window as root view controller and one when it is not (e.g. when you want to test view controller and you instantiated it from storyboard).

View Controller as a rootViewController

if self.window == nil {
    self.window = UIWindow(frame: UIScreen.mainScreen().bounds)
}

let storyboard = UIStoryboard(name: "Main", bundle: NSBundle.mainBundle())
let vc = storyboard.instantiateViewControllerWithIdentifier("ViewController")
self.window!.rootViewController = vc

This is the flow which takes a place e.g. in application:DidFinishLaunchingWithOptions: method.

The flow starts by calling makeKeyAndVisible method of UIWindow which calls its private addRootViewControllerViewIfPossible method that tries to add view of root view controller to itself and presents it. UIWindow accesses view property of the root view controller which starts a chain of loading view process. The accessor calls loadViewIfRequired method which calls loadView method. The loadView calls internal methods of UIViewController that loads nib with a view that will be set.

There is one great talk from this year’s WWDC which covered how Storyboard and their nibs behaves at runtime - Implementing UI Design in Interface Builder.

After the loaded view is set, view controller calls its internal _window method and read all the things like preferedInterfaceOrientation, supportedInterfaceOrientations, shouldAutorotate, etc. Actually it calls _window many times and there are some other methods called too.

Next viewDidLoad method is called and private __viewWillAppear which calls viewWillAppear on view controller. View is about to be presented so there are calls to willMoveToWindow:, willMoveToSuperview: and private _didMoveFromWindow:toWindow: methods.

The next thing is setting up Auto Layout in the view, so layoutMarginsDidChange, didMoveToWindow, didMoveToSuperview, updateViewConstraints, updateConstraints, layoutSublayersOfLayer, viewWillLayoutSubviews, layoutSubviews methods are called - there is a lot of them.

Finally viewDidAppear: is called and view is presented.

View Controller loaded in testing

This is another important case worth to investigate. In this case you probably don’t want to create window and put your view controller under the test to it. You just want to instantiate view controller instance from storyboard and test it.

Before Natasha’s post I known just one method to load view of a view controller and make sure it is loaded. I did it by accessing view property directly after view controller was created. Today I’ve learned about loadViewIfNeeded method which is available since iOS 9 and behaves the same way like accessing view property. I’ve also learned third - IMO the best method to load the view controller during testing and make sure it is ready to use - presented by Ørta. This is about calling beginAppearanceTransition:animated and endApperanceTransition methods. Here is solution he shared - covered below.

Accessing view directly

Let’s take a look on a flow when accessing view directly.

let storyboard = UIStoryboard(name: "Main", bundle: NSBundle.mainBundle())
let vc = storyboard.instantiateViewControllerWithIdentifier("ViewController")
_ = vc.view

And the flow is like below:

Okaaay… There is much less calls. View has been accessed and loaded. The window is nil so I think no more methods have been called and the flow ended up in viewDidLoad. A bit strange. Some configuration might be inside viewWillAppear or viewDidLoad. This method should work in most test cases. loadViewIfNeeded works the same way.

Let’s check how beginApperanceTransition:animated: behaves.

beginApperanceTransition:animated

let storyboard = UIStoryboard(name: "Main", bundle: NSBundle.mainBundle())
let vc = storyboard.instantiateViewControllerWithIdentifier("ViewController")
vc.beginAppearanceTransition(true, animated: false)
vc.endAppearanceTransition()

Great! This flow is more similar to the first one. You can see there is no window here so the view of view controller is not added to the flow so no auto layout configuration code is running. Just view controller configuration.

Conclusion

You can see the loading view flow depends of in which context view controller and view are used.

In the first case there was a view and view controller was the root one so it has a lot of configuration and view was configured too.

In the last case there is just view controller configuration since there is no window and configuring view is not necessary. This approach also simulated presenting view controller so viewWillAppear and viewDidAppear method have been called - This might be important in some cases.

And the last case I would mention is the second one. I didn’t know earlier that it behaves like this. I would expect that viewWill/viewDid method are called too, but they didn’t. IMO the approach presented by Ørta is the best one when testing view controllers.