Derived Data

A Feel-Good Refactor

Sun, 21 Feb 2021 00:00:00 GMT

If you are using Combine's Just, Fail, or Result.publisher as much as I do to mock publishers for SwiftUI's previews and tests, chances are you have grown tired of manually setting either the output or the failure types, then erasing to AnyPublisher in every occurrence.

Today I decided that it was time to honor the rule of three (or thirty eight?) and come up with something better. For one, we can heavily lean on Swift's type inference to improve the API at the call site. And while we're at it, we can make it easier to remember by using a similar syntax to handle both success and failure scenarios.

Since the goal here is to create a type-erased publisher that emits either a value or an error then completes, we can call the helper "once". As for the implementation, we have a couple of options: define a static function on Publisher, or create a custom Publisher type. Since the latter would still require type-erasure at the call site, I chose to go with the former.

Let's start with the far more common value-emitting path.

public extension Publisher {
  static func once<T, U: Error>(
   _ value: T,
    failAs error: U.Type // 1
  ) -> AnyPublisher<T, U> {
    Just(value)
      .setFailureType(to: U.self)
      .eraseToAnyPublisher()
  }
}

This does the job, but having to specify the error type (1) every time takes away some of the feel-goodness of this solution. Luckily, Swift's type inference comes to the rescue. Time for take 2!

static func once<T, U: Error>(
  _ value: T
) -> AnyPublisher<T, U> {
  Just(value)
    .setFailureType(to: U.self)
    .eraseToAnyPublisher()
}

The type of the return value should be enough to identify the publisher's failure type. For cases where there isn't enough type information at the call site, we can keep the first iteration around to avoid the need for explicit types when assigning values—but that's purely a matter of preference.

With the happy path case behind us, let's do the same for the failure-emitting case.

static func once<T, U: Error>( // 1
  failing error: U // 2
) -> AnyPublisher<T, U> {
  Fail(
    outputType: T.self,
    failure: error
  )
  .eraseToAnyPublisher()
}

I chose to keep the same method name (1) to streamline the API at the call site. Unfortunately this means an additional keyword is needed to help the compiler tell them apart. I went with failing (2) on the spur of the moment, but anything would do the job. If call site uniformity is a non-goal, then using just/fail to match the Combine publishers would be preferable.

As a parting bonus, we can throw in an additional helper for publishers where the output value is Void; quite common for write operations and PUT/DELETE endpoints.

static func once<U: Error>() -> AnyPublisher<Void, U> {
  once((), failAs: U.self)
}

static func once<U: Error>(
  failing error: U
) -> AnyPublisher<Void, U> {
  once(Void.self, failing: error)
}

Armed with these new tools, mocking publishers is now as easy as calling once() and once(failing:) with the value or error respectively.

Here's an example from the codebase that prompted me to write this post:

let cache = Cache(
  upsert: { value in // -> AnyPublisher<Value, CachingError> 
    Just(value)
      .setFailureType(to: CachingError.self)
      .eraseToAnyPublisher()
  },
  deleteOutdated: { // -> AnyPublisher<Int, CachingError>
    Just(2)
      .setFailureType(to: CachingError.self)
      .eraseToAnyPublisher()
  },
  deleteAll: { // -> AnyPublisher<Int, CachingError>
    Fail(
      outputType: Int.self,
      failure: CachingError.nothingToDelete
    )
  }
)

And here is the same section after the refactor:

let cache = Cache(
  upsert: { .once($0) }, // (Item) -> AnyPublisher<Value, Error>
  deleteOutdated: { .once(2) }, // () -> AnyPublisher<Int, Error>
  deleteAll: { .once(failing: .nothingToDelete) } // () -> AnyPublisher<Int, Error>
)

Now, tell me which scores higher in the feel-good department?

Debugging SwiftUI: Trials and Tribulations

Fri, 30 Oct 2020 00:00:00 GMT

I have been using SwiftUI since day one, on both client and side projects. It's an incredibly refreshing way of coding interfaces for Apple devices, but it's far from being wrinkle-free. The framework's bold ambitions are sometimes hampered by subpar debugging tools and arcane, seemingly random limitations.

I previously wrote about a SwiftUI bug that gave me quite a run for my money:

The stack trace isn’t of much help and no amount of view hierarchy tweaks got rid of it entirely. Initially I was under the impression that either my code or one of my external dependencies were doing something horribly wrong, but this post from Peter Steinberger made me realize that it is a rather widespread issue.

Since I didn’t manage to reproduce it on a particular test device at the time, I assumed it’s yet another simulator quirk. But a little over a month later, the same bug reared its ugly head on a test device. Fun times!

The app in question uses tab navigation where the first tab is always accessible, while the second tab shows different content depending on whether the user is signed in to their account or not. The view code looked roughly like this:

TabView {
  Home()
    .tabItem { /* ... */ }
    .tag { /* ... */ }

  if isSignedIn {
    Profile()
      .tabItem { /* ... */ }
      .tag { /* ... */ }
  } else {
    SignIn()
      .tabItem { /* ... */ }
      .tag { /* ... */ }
  }
}

To avoid the isSignedIn boolean check in multiple modifiers, I opted for an if-else block with separate views and tabItem modifiers.[^1] Except that didn’t seem to sit right with SwiftUI for some reason. The app launches and displays the content of the first tab exactly as intended. But when I switch tabs—or god forbid, sign in or out—the app crashes with this cryptic error message:

[error] precondition failure: invalid size for indirect attribute: <number> vs <number>

The call stack points exclusively to SwiftUI internals, with the last call referring to a certain AG::Graph—responsible for holding the view tree and diffing it. As far as debugging goes, this is very, very little to work with.

With my hands tied, I briefly considered resurrecting the UITabBarController wrapper I used prior to WWDC, especially since I didn’t manage to make a reproducible test case or submit a feedback to Apple. At first, I spent an inordinate amount of time tweaking the view hierarchies of the profile and sign-in screens themselves, with varying—and rather inconsistent—levels of success. I ran out of both time and patience, so I moved on to other things to not stall the project any further. Weeks later, I came back to the problematic screen—pitchfork in hand—ready to gut the entire tab navigation and replace it with a custom-made solution. I had had enough.

But then came the proverbial aha moment: what if the conditional check took place inside the second tab, instead of around it?

TabView {
  Home()
    .tabItem { /* ... */ }
    .tag { /* ... */ }

  ProfileOrSignIn(isSignedIn: $isSignedIn)
    .tabItem { /* ... */ }
    .tag { /* ... */ }
}

And just like that, the crasher was gone. Squashed into oblivion.

If this sounds dumb, it’s because it is. At no point did the compiler chastise me for doing something I wasn't supposed to do. And to make matters worse, the documentation doesn't mention anything related to... wait, what documentation?

It’s a bittersweet feeling when you fix a bug in a non-deterministic, haphazard way. On one hand you are elated you’ve managed to fix it at all. On the other, you feel somewhat powerless and insecure about your ability to handle similar situations in the future. I adore SwiftUI, but moments like these give me a good dose of anticipatory anxiety—the kind that erodes trust and dampens the thrill of being at the bleeding edge.

[^1]: As an aside, apps that greet users with a sign up screen are generally trash. You don't ask prospective tenants to sign the contract at the door before they've even seen the apartment.

How I Use Document Tabs in Xcode 12

Thu, 03 Sep 2020 00:00:00 GMT

The new document tabs in Xcode 12 caught me off-guard more than once at first, but as soon as I figured out how they work, I started to enjoy using them.

For instance, in server-side projects I am typically dealing with half a dozen files related to the same area or feature; the model itself, the repository, migrations, tests, mocks, etc. Before, I used separate window tabs for each "topic", but now I rely heavily on document tabs to fill that need. My current setup is something roughly like this:

I usually keep 3 window tabs in every project: development, testing, and debugging. I occasionally create break-out window tabs for self-contained tasks like refactoring, reading the source code of a dependency, etc.
In the development window tab, I use vertical area splits for the different topics I am actively working on. Usually these correspond to a model file and its satellite types. I start with one then add or remove splits as needed.
Inside each area, I use the new document tabs to keep all the related files open, enabling quick tab switching using the keyboard shortcut <kbd>cmd</kbd> + <kbd>shift</kbd> + <kbd>[</kbd> or <kbd>]</kbd>.
I use horizontal splits when I need to look at different files in the same topic. An example would be the model and its migration file in server-side, or a view and its state object in SwiftUI.

I reason better about code when I can see several related files at the same time, and document tabs give me an even more effective way to achieve that.

Mattt on WWDC 2020

Sun, 28 Jun 2020 00:00:00 GMT

It's refreshing to see Mattt's reasoned take amidst all the attention-seeking headlines this week:

As it turns out, going fully remote wasn’t merely good enough — it was, in many ways, superior to the original thing. [...] Sessions are tight and well-paced. Rather than stretching or cramming content into a fixed time slot, they’re as long as they need to be.

This definitely echoes my impressions. As someone who mostly followed along from home in the past, not only did I not miss much this year, but I got treated to a much improved remote experience.

Mattt also brings up the topic of Excitement—or hype, as I often call it—and productivity:

Here’s the thing about excitement: It’s kryptonite to developers. Excitement messes with our ability to focus on one thing, which is already a big struggle for a lot of us (myself included). When you’re excited, it’s almost impossible to get anything done.

This is true for any endeavor, but especially so for software development.

There are plenty of voices in the community who are echoing this excitement. I can’t add anything to that discussion. And besides, that’s not really where my head’s at right now.

The official Apple content generates enough sense of <abbr title="Fear of Missing Out">FOMO</abbr> as it is. Combining that with a firehose of What's new in X blog posts, podcasts, YouTube videos, and tweets doesn't help much as far as I am concerned.

It’s been an exciting week, so take a moment to collect yourself. Go on a walk. Take a hike. (Be safe about it.) Do whatever you need to break free of the “reality distortion field”. Once you do, you’ll have the necessary distance to determine what new technologies you should pay attention to and what you can ignore for now.

Solid advice, WWDC or otherwise.

Early Lessons in Adopting SwiftUI

Fri, 02 Aug 2019 00:00:00 GMT

We've been using SwiftUI day in and day out since the first beta to build a non-trivial app at work---a bold move, but one that makes me like my job. Here are some lessons I've learned:

Stick to standard navigation. As unstable as the APIs are for the time being, this will spare you the layout and accessibility headaches that come with custom transitions.
Always investigate whether your UI can be implemented as a list view. It handles dynamic type, dark mode, and other accessibility features out of the box, and will likely look more polished as a result.
Make good use of section headers and footers in List. Unlike UITableView, these are much easier to set up in SwiftUI's declarative syntax. They can be used for empty states, search fields, sorting controls, etc.
Embrace the current limitations of the framework. If you have to fight it at every turn to get the result you want, consider taking a different route where you don't have to do that. You can revisit the same challenge later as the framework matures.
Don’t use hard coded colors, i.e. the RGB initializer. Use system tint colors or asset catalogs instead, and stay clear of white and black as they don't adapt to appearance modes.
Pay attention to the methods used to pass data down to and up from subviews. It’s easy to use the wrong method and the error won’t be very helpful. Spend some time to understand the difference between @State, @Binding, @ObservedObject, and @EnvironmentObject.
Speaking of compiler errors, split your view hierarchy using variables, methods, and separate view structs to make the wide of the mark error messages slightly more relevant and helpful.
Extract reoccurring view modifier chains into custom modifiers to DRY up the code. It's a bit more work that I anticipated, but it's worth it.
UIKit appearance helpers still work in SwiftUI. Call them from within the init() method of the view when needed. For instance, this is the only method to remove the opaque background from a List as of now.
SwiftUI is still very rough around the edges, so keep your cool and stay hydrated.🥤

Swift's Killer Feature

Tue, 18 Jun 2019 00:00:00 GMT

Since its release 5 years ago, Swift has matured a great deal as a programming language, both in terms of stability and expressive power. Its concise syntax and type safety have been largely celebrated within the Apple developer community, and increasingly noticed outside of it. But, as it is the case with similar transitions, not everything is hunky-dory.

In addition to the source breaking changes that soured the language earlier on, Swift is often criticized for lacking an indisputable selling point compared to what was there before it (Cocoa and Objective-C), and what came after it (JavaScript cross-platform frameworks).

Unfair as it may sound, programming languages are often evaluated based on their ecosystem, not on their intrinsic merits. In the eyes of many, Swift is indissociable from Apple and their platform UI frameworks, for better or for worse. The mismatch between Cocoa APIs and Swift language features has been brought up again and again in discussions about its appeal as a replacement for Objective-C.

Expressiveness and type safety can certainly keep a handful of enthusiastic developers engaged, but it won’t be enough to sustain Swift’s momentum on the long run. As much as some of us hate to admit, the competition is colossal on the server and scripting side of things, and it’s getting uncomfortably stronger on the native platform front.

On top of that, the write-preview-debug development cycle that we’ve been dealt since the dawn of Cocoa is considered sluggish and tedious by today’s standards. A liability that’s long overdue for reconsideration. To make matters worse, Apple's UI frameworks haven’t converged fast enough to alleviate some of these issues---we are still required to implement half a dozen methods for each platform to display a plain table view.

This state of affairs has pushed many to adventure outside first-party fences in search of more exotic alternatives, while the holdouts stuck to their ~~guns~~ bows and arrows in the absence of a clear-cut perk of leaving their tried-and-true programming language behind[^1].

But all of this is bound to change.

During this past WWDC, Apple introduced SwiftUI---a modern, universal framework for building user interfaces across their platforms. And it’s packing quite a punch. SwiftUI is declarative, reactive, and ready to take us places; the killer feature that Swift deserved all along. Not only is it tightly integrated with the language, but it’s also pushing it forward by providing a use case for new additions such as function builders and property wrappers.

Even though we have barely scratched the surface of SwiftUI since its announcement, it’s already winning the hearts of large swaths of developers, myself included. I don't have a shred of doubt that this is the future of UI programming on Apple platforms, and I am thrilled to witness, and be part of, this transition.

[^1]: Part of me appreciates the prudent approach with regard to adopting new technology that’s yet to prove itself. Another part of me fails to see the point of swimming against the current in a predominantly closed platform where a single company gets to call the shots.

Units in Foundation

Sun, 04 Dec 2016 00:00:00 GMT

Starting iOS 10 and macOS 10.12, Foundation supports units and measurements out of the box, in the form of (NS)Unit and (NS)Measurement respectively. Let's take a look at how they work.

Note: All code snippets below are written in Swift 3.0.

To get started, let's define a measurement. To do that, you have to pass a value and a unit to the initializer:

import Foundation

let snorlaxWeight = Measurement(value: 460, unit: UnitMass.kilograms)
// -> 460.0 kg

You can then effortlessly convert the measurement to another unit:

let snorlaxWightInImperial = snorlaxWeight.converted(to: .pounds)
// -> 1014.12723328454 lb

You can also define your own unit by extending one of the default dimensions available:

extension UnitMass {
  static let snorlax = UnitMass(symbol: "snorlax", converter: UnitConverterLinear(coefficient: 460))
}

The converter is used to transform the measurement from any given unit to the base unit of the dimension; Kilograms in the case of UnitMass. You can inspect the base unit of any dimension by calling baseUnit() on it.

UnitMass.baseUnit()
// -> kg

Once defined, your custom unit can be used alongside the pre-defined ones:

let statueOfLibertyMass = Measurement(value: 225_000, unit: UnitMass.kilograms)
let statueOfLibertyMassInSnorlax = statueOfLibertyMass.converted(to: .snorlax)
// -> 489.130434782609 snorlax

You can also define a custom dimension of units by subclassing Dimension if necessary. Here is an example that defines a new UnitDataRate class for measuring data transfer rates, often used in Internet speed tests:

class UnitDataRate: Dimension {
  static let kilobitPerSecond = UnitDataRate(symbol: "kbps", converter: UnitConverterLinear(coefficient: 1))
  static let megabitPerSecond = UnitDataRate(symbol: "Mbps", converter: UnitConverterLinear(coefficient: 1_000))
  static let gigabitPerSecond = UnitDataRate(symbol: "Gbps", converter: UnitConverterLinear(coefficient: 1_000_000))

  override class func baseUnit() -> UnitDataRate {
    return .megabitPerSecond
  }
}

let speed = Measurement(value: 100, unit: UnitDataRate.megabitPerSecond)
let speedInKpbs = speed.converted(to: .kilobitPerSecond)

// -> 100000 kbps

Learn More

WWDC session 238
Measurements and Units in Foundation by Ole Begemann.
iOS 10: Measurements & Units Screencast by Sam Davies.

Swift 3 Access Control

Thu, 29 Sep 2016 00:00:00 GMT

Swift 3 introduced finer-grained control over what can access what in your code. The addition of 2 keywords made things less obvious, however. Here is a cheatsheet to help with the transition:

Private: Entity can only be accessed within the same scope it was defined in. A private class can only be subclassed by another private class defined in the same scope.
File private: Entity can only be accessed within the same file. You can subclass fileprivate classes and override their fileprivate methods and properties.
Internal: Entity can only be accessed within the same module, i.e. app or framework target. This is the default if no access keyword is specified. You can subclass classes and override their non-private methods and properties.
Public: Entity can be accessed from within other modules. Classes cannot be subclassed.
Open: Entity can be accessed from within other modules. Classes can be subclassed in other modules if they are marked as open. Each method and property needs to be marked as open to be overridable in subclasses.

tvOS HIG: Too Long; Didn't Read

Mon, 05 Oct 2015 00:00:00 GMT

I often joke about the HIG being an acronym for Highly Ignored Guidelines. This is an effort to change that, at least for tvOS.

The user interface of tvOS.

Glossary

Click. One-finger quick press on the center of the touch surface. The primary way of triggering actions.
Click-and-hold. One-finger long press on the center of the touch surface. Used to trigger context-specific actions, like entering edit mode.
Focus. The state of the currently selected interface element.
Parallax. An effect applied to focused app icons and content elements using multiple layered images.
Siri Remote. The Siri-enabled remote used as the primary input method for Apple TV. It comes with 6 buttons, a touch surface, an accelerometer, and a gyroscope.
Swipe. One-finger press followed by a quick movement in any direction on the touch surface. Used to move focus vertically or horizontally.
Tap. One-finger quick press on one of the four directions (top, right, bottom, left) of the touch surface. Used for single-item directional navigation.
Top Shelf. The area above the first row of apps where featured content of the focused app appears.

Update: My colleague Jack Nutting pointed out that clicks require you to press the touch surface until it clicks, whereas taps don't.

General

Design with multiple simultaneous users in mind.
Prefer showing old data to no data at all.
Avoid excessive animation.
Avoid using alerts unless it’s for a critical user decision. When you do, provide no more than two choices.
Don’t display your logo throughout the app UI.
Use the system video player to get advantage of all its interactive features.

Focus

Make focus obvious using labels, transforms, and other effects.
Use parallax on focused elements to make the UI more responsive to user interaction.
Prefer light backgrounds so that focus shadows remain visible.

Controls

Keep the difference between click and tap in mind. See the glossary.
Avoid using taps for triggering actions other than navigation.
Avoid using standard gestures to perform non-standard actions.
Avoid defining new gestures to perform standard actions.
Make sure your controller-compatible game works with the remote as well.
Always enable the Play/Pause button on the Siri Remote. If you are running out of ideas, make it at least perform a click.
Use gestures to move focus, not content. For instance, a left swipe would move focus to the left, making the content move to the right.
Use gestures to move content when displayed full-screen. For instance. a left swipe on a full-screen image would move the image to the left.

Navigation

Use the tab bar for the main navigation of your app.
Allow your users to navigate back to the previous screen or out of your app/game using the Menu button.
Don't display a back button.
Keep your content structure simple for easier navigation.
Prefer text, more specifically nouns and verbs for your tab titles.

Visual Design

Design your interface for a 1920 x 1080 pixels (16:9) screen in mind.
Use @1x resolution for all image assets.
Use an opaque background layer when making your layered images.
Provide at least one static Top Shelf image (1920px by 720px) if you don’t have any dynamic content to showcase.
Use the sRGB color space.
Favor muted color for better results on highly saturated TVs.
Prefer top-to-bottom, light-to-dark gradients.
Prefer horizontal layouts.
Leave 60 pixels on the top and bottom, and 90 pixels on the right and left as padding around the edges of the screen.

Text

Use San Francisco Text for text 39 points or smaller, and San Francisco Display for text that's 40 points or larger.
Put text in the top-most layer of your layered images.
Use the built-in text styles to take advantage of features like Dynamic Type.
Use title-case in your text buttons.
Avoid combining both icons and text in buttons.
Try to limit text-input in your app since typing on the Apple TV can be tedious.

App Icon

Use a layered image (2-5 layers) for your app icon (1280px by 768px for large version and 400px by 240px for the small one).
Leave a padding around the content of your foreground layers.
Don’t include screenshots in your app icon.
Avoid text in your app icon, unless it’s part of the brand.