südrocket.de Blog

SwiftUI equal and ideal sizes

Matthias Maurbeger (matthias@hey.com) — Sun, 22 May 2022 20:38:15 +0200

One of the more common sentiments towards SwiftUI you’ll come across on the Internet goes something like this: It’s magical until it isn’t. Meaning: SwiftUI let’s you write UI code so quickly that it sometimes feels like a superpower. But suddenly you hit a wall and there’s seemingly no way around it. One example that illustrates this quite well is when you want to make all children of a VStack as wide as the widest child. Sounds like it should be straightforward. But it’s not. It’s a surprisingly hard problem.

Let’s stack up all of our favorite movies so we can pick our most favorite among them:

struct EqualWidthButtonStack: View {
    
    let buttonTitles: [String] = [
        "The Fast and the Furious",
        "2 Fast 2 Furious",
        "The Fast and the Furious: Tokyo Drift",
        "Fast & Furious",
        "Fast Five",
        "Fast & Furious 6",
        "Furious 7",
        "The Fate of the Furious",
        "F9"
    ]
    
    var body: some View {
        VStack {
            ForEach(buttonTitles, id: \.self) { t in
                Button(action: {}, label: {
                    Text(t)
                })
                .buttonStyle(.borderedProminent)
            }
        }
    }
}

What we see, apart from the fact that it’s a very sad top movies list, is that each movie button is as wide as it needs to be to fit the title. Yet we want all of the buttons to have equal widths so our brain isn’t tricked to pick the one which stands out the most (Tokyo Drift!!!).

To achieve this, we’ll need to make two changes to our above code. First, we’ll wrap each Button’s Text label in a .frame modifier with maxWidth: .infnity. That alone only solves our problem if we want our stack of buttons to occupy the full width it was given. If we want the stack of buttons to be as wide as it needs to be, we’ll need to make a second adjustment: apply the fixedSize modifier to the VStack.

struct EqualWidthButtonStack: View {
    
    let buttonTitles: [String] = [
        "The Fast and the Furious",
        "2 Fast 2 Furious",
        "The Fast and the Furious: Tokyo Drift",
        "Fast & Furious",
        "Fast Five",
        "Fast & Furious 6",
        "Furious 7",
        "The Fate of the Furious",
        "F9"
    ]
    
    var body: some View {
        VStack {
            ForEach(buttonTitles, id: \.self) { t in
                Button(action: {}, label: {
                    Text(t).frame(maxWidth: .infinity)
                })
                .buttonStyle(.borderedProminent)
            }
        }.fixedSize()
    }
}

This yields the desired result:

There are, of course, a few other ways to achieve the same result. John Sundell has a great article with details.

How does it work

I’m probably the wrong person to attempt an explanation how exactly SwfitUI’s layout engine works under the hood. I didn’t come up with this solution myself. I was taught this technique by Paul Hudson in one of his workshops and it kind of blew my mind, because up until then I used the preference system to achieve something like that.

The key for this technique to work is that even though we wrap all the labels in a frame(maxWidth: .infinity) modifier the idealWidth of the Text is still propagated to the parent VStack. The VStack then determines its own idealWidth by looking at the idealWidth of all children and picking the widest one. Applying the fixedSize modfifier fixes the stack’s width at its ideal width (i.e. the width of the widest child).

References

Using awk for project hygiene

Matthias Maurbeger (matthias@hey.com) — Mon, 03 Jan 2022 17:29:00 +0100

In a somewhat recent tweet Adam Gordon Bell predicted that awk might still be around in the year 3000 despite being already in use for 44 years:

Some software that was written in 2021 will still be in use in the year 3000.

What will it be?

Considering that I’m using awk today, and it was written 44 years ago, I guessing awk will still be in use then. But what else will make the cut? Anything made this year?

Here’s an example where I recently used awk for iOS development: I was working on a codebase that already went through at least one major change in its lifetime. Over the years, the codebase accumulated more and more translations. Some are still in use others are not. The naming convention for the translation keys also was revised along the way which contributed a lot to translation corpses being left behind. That’s why I wanted to answer the question: “Which keys are still in use now and which keys may be safely deleted from the project?” Let’s tackle the question one step at a time:

Searching for a single key

We can start by checking if one specific key is used in our codebase and then scale the method we developed for the general case. How do we define “is used”? Well, we’ll just say that whenever the key comes up in any of the source files (*.swift) the key is used. If the project uses Interface Builder we would also consider storyboard files (and potentially XIB files?). In my case considering *.swift files was enough so that’s what I’m going with here.

There are several command line tools available for you to find all occurrences of a given string within the project. My go-to tool in this case is always ripgrep but similar tools like git-grep or the silver searcher are also a great fit. If we want to know if the key ERROR_OFFLINE is used we’ll just execute the following command from our project root:

rg -t swift --case-sensitive -F "ERROR_OFFLINE" .

Let’s break it down:

-t swift tells ripgrep that we’re only interested in .swift files

--case-sensitive speaks for itself

-F tells ripgrep that our search term is a fixed string, meaning that it should not be treated as a regular expression

This yields the following output which tells us if and where our key is currently in use:

$ rg -t swift --case-sensitive -F "ERROR_OFFLINE"
iOSApplication/Sources/Model/Errors+Localization.swift
25:            return LocalizedString("ERROR_OFFLINE")

Getting a list of keys

Now that we know how to answer if a specific key is currently in use, we need to ask this question for all the keys. How do we get this list? This is where awk comes in. All the keys we might want to check are present in one of our Localizable.strings files. Assuming our reference is en.lproj/Localizable.strings we need a way to extract just the keys from the file without the translation. Each Localizable.strings file contains key-value pairs which map a key to a corresponding translation:

"ERROR_OFFLINE" = "Why are you offline?!";

Extracting the key in the first column is a prime use-case for awk. I’m by no means an expert in using awk. I’ll basically have to look up everything again when I use it. Here’s a great primer that I have bookmarked: Awk in 20 Minutes . Anyway, let’s get the keys out of our file:

$ awk '/^\"/ { print $1 }' < Assets/en.lproj/Localizable.strings

This is a bit less readable but it basically just says: Pipe our input file into awk, only look at lines that begin with a double quote " and print the first field. Awk per default separates a line into fields by looking at spaces. print $0 would’ve given us the full line, print $2 the equal sign and print $3 the translation plus the trailing semi-colon. So print $1 it is. And that’s already our list of keys that we need to process further.

Detect all unused keys

To answer the original question “Which keys are safe to delete?” we now combine the two previous mentioned methods. First, we’ll use our reference file to get a list of keys and then we’ll search the project using ripgrep for each of those keys. Combining the two methods could look like the following:

!#/bin/bash

awk '/^\"/ { print $1 }' < Assets/en.lproj/Localizable.strings  | \ # get a list of keys
while read -r KEY; do                                               # loop over each key
	rg -q -t swift --case-sensitive -F "$KEY" .                     #   browse the project for this key
	if [ $? -eq 1 ] ; then                                          #   if there's no match...
		printf "$KEY"                                               #     ... print out the key
	fi
done

Compared to our previous invocation above, we added the -q (quiet) option to our ripgrep command to suppress any output from ripgrep. In the following if statement we inspect the status code of the previous command. rg will exit with code 1 if it could not find any occurrence and 0 otherwise. Every key that did not come up in our search will be printed out. And that’s basically how we identify unsused keys within our project.

Caveats & Outlook

Of course the method as written above is not bulletproof for every project. For example, what if we fetch some keys dynamically from our server? The keys don’t necessarily need to appear in our source files to be important to or project. However, in my opinion a script like the above does no need to be 100% bullet proof to be useful. Sure, if you pipe the output of the above script to another command which just purges all those keys from all Localizable.strings files it better be bulletproof. But what we wanted for now is just to get a sense which of the existing translations are probably obsolete. And it might serve as a starting point for a more sophisticated script that accomodates the various intricacies of the project. The main takeaway is this: embrace the shell. Transforming output with the plethora of commands available to us is such a powerful tool. And awk is the swiss army knife among those tools.

P.S.: Drew DeVault has a great blog post about shell literacy.