UserInterfaceLevel, the future of floating apps?

Raul Riera — Sun, 07 Jun 2020 23:03:34 +0000

Last year Shopify started developing the All-new POS application. There was a small problem, given that all screens are presented as full screen to the user we needed the ability to distinguish a modal screen vs the rest. iOS 13 had a great answer to this.

It feels like every new iOS version adds something to UITraitCollection or UIUserActivity. iOS 13 was no different. There was an handy small addition to UITraitCollection for apps with floating windows. That addition was userInterfaceLevel.

What is UserInterfaceLevel?

Apple describes it as the visual level for content in a window. The possible values are base, elevated, and unspecified. The first one being the window’s main content and the last one anything above it. This will be the perfect match for our need of modal windows having a dedicated background colour.

Using it to meet our requirement

import UIKit

public struct AdaptiveColor {
    /// See [UserInterfaceLevel](https://developer.apple.com/documentation/uikit/uiuserinterfacelevel) for more info.
    private(set) var base: (light: UIColor, dark: UIColor)
    /// The color used for content visually above your window's main content. If none is specified, the `base` color is used instead.
    ///
    /// See [UserInterfaceLevel](https://developer.apple.com/documentation/uikit/uiuserinterfacelevel) for more info.
    private(set) var elevated: (light: UIColor, dark: UIColor)

    public init(light: UIColor, dark: UIColor) {
        base = (light: light, dark: dark)
        elevated = base
    }

    public init(base: (light: UIColor, dark: UIColor), elevated: (light: UIColor, dark: UIColor)) {
        self.base = base
        self.elevated = elevated
    }

    public var value: UIColor {
        if #available(iOSApplicationExtension 13.0, *) {
            return UIColor { traitCollection in
                let isElevated = traitCollection.userInterfaceLevel == .elevated
                if traitCollection.userInterfaceStyle == .dark {
                    return isElevated ? self.elevated.dark : self.base.dark
                } else {
                    return isElevated ? self.elevated.light : self.base.light
                }
            }
        } else {
            return base.light
        }
    }
}

The previous snippet is how Shopify’s Point of Sale application is handling dynamic colours. You should focus on line #24, we detect the current elevation of the user interface and decide which of the two colour sets to use for this particular colour.

Now, let’s say we want to change the background colour of a view all we need to do is:

view.backgroundColor = AdaptiveColor(base: (light: .white, dark: .black), elevated: (light: .lightGray, dark: .gray)).value

And thanks to the excellent UIAppearance we can style our UINavigationController similarly how we styled the background view, and all our screens will be displayed with the correct colour.

Putting everything together into a project, it looks something like this:

raulriera / technical-articles

Just a place where I can store demo projects for my technical articles.

Undo and Redo support to iOS apps

Raul Riera — Sun, 27 Jan 2019 19:31:00 +0000

Adding Undo and Redo support to iOS

People make mistakes. Let’s use allow undoing.

You have accidentally shaken your phone and noticed that little alert screen that says “Undo [something]”. In this story we are going to implement Undo and Redo actions in an iOS app.

By now you are making all your screens using a declarative and functional approach, right? 😉 If not, you can read all about it. Expanding on that approach, we can easily implement undo actions into our app if all our View Controller state is encapsulated like it was demostrated in that article.

Looking at the documentation

When I looked at Undo Manager it appeared like I was going to be dealing with Selectors, old Objective-C API, and whatever else was lurking underneath. I tried to get around this by creating a wrapper struct with some syntactic sugar.

struct Undoer {
  let undoManager: UndoManager
  ...
}

Thankfully, Geoffrey Foster talked me out of it and I end up choosing a better approach. By simply extending UndoManager to include one more function. Now, taking everything I had in the previous wrapper, all I was left with was this.

Pretty simple right?

Pretty simple right? To be honest, the biggest issue with writing this short function was embracing the fact that you want to capture your variables inside the registerUndo closure, while also having it call itself.

Exploring the code

UndoManager works exactly like that. It retains a copy of the data in the closure so you can revert any changes by calling undoManager.undo() or redo() for that matter. Doing so, executes our handler callback and recursively calls itself again, but this time with the values inverted. Creating that loop of undo and redo actions that we desire.

Fixing the bug 🙃

There is one issue that you probably spotted by now. If we use reference types, we won’t be maintaining the previous data. Thankfully that is why we have the Codable constraint in the generic type T.

By leveraging Codable, we can implement a quick and dirty version of copy to serialize and deserialze the content of the data, so we can maintain the state.

Don’t @ me 🙈

This is more like it, now our UndoManager can store and restore the state of any class or struct, and we barely even had to break a sweat writing this.

You can find the source code of this function with a quick implementation into a View Controller in the following link.

raulriera/technical-articles

Did I miss anything? Get in touch on Twitter: @raulriera

DEV Community: Raul Riera