Categories
Software

SwiftUI Being a bit Quirky

The Ecstasy and the Agony of Making Software

I recently wanted to create some content that would sometimes display in an HStack and sometimes in a VStack. The content was the same in both cases, so I wanted to avoid doing:

if goVertical {
    VStack {
        thing1
        thing2
    }
} else {
    HStack {
        thing1
        thing2
    }
}

Fortunately, I was able to use a ViewBuilder to contain the contents of the stacks.

@ViewBuilder var stackContents: some View {
    thing1
    thing2
}

...

if goVertical {
    VStack {
        contents
            .padding(.horizontal)
    }
} else {
    HStack {
        contents
    }
}

So far so good. (Aside: Am I the only one who didn’t know @ViewBuilder can be used to return a list of SwiftUI views?!) However I eventually got myself into a bit of trouble with my stack contents in an interesting way. Here are the details.

First you need to know that thing1 is an image and thing 2 is a VStack of sliders, steppers and such. Here’s how the view looks in portrait and landscape.

BUT… since I will be adding more sliders, steppers and such, I moved them into a ScrollView. But (as you can see on the right) when I did this, The ScrollView took more height than it needed and short changed the Image.

My first thought was in use a layoutPriority modifier on the image, but this had no effect, so I removed it. Next, I tried adding background modifiers to the VStack contents, and that proved to be very illuminating. (see below)

Here is the code with the background modifiers:

        VStack {
            contents
                .background(.red)
                .padding(.horizontal)
                .background(.blue)
        }
        .background(.yellow)

Applying horizontal padding to contents did not apply it once, it (presumably) iterated through all the items in contents and applied the padding to each item in contents.

I moved the padding (and background modifiers to apply to the VStack, instead of contents

        VStack {
            contents
        }
        .background(.red)
        .padding(.horizontal)
        .background(.blue)

Great, this looks more like what I was expecting with the padding. But the image is still narrower.

So I re-added the layoutPriority modifier to the image, and that did the trick. I still don’t understand why the ScrollView ‘steals’ vertical space from the Image. (And maybe one day I’ll better understand what causes me to anthropomorphize SW modules like layout engines.)

The interesting thing for me in this issue was how doing something incorrectly (ie applying the horizontal padding to the contents of the VStack, rather than to the VStack) worked correctly at first, but when the butterfly flapped its wings (ie one of the elements in contents was wrapped in a ScrollView) the wheels fell off.

Encountering and eventually overcoming this type of problem is a big part of the ecstasy and the agony of writing software.

Categories
Software

A SwiftUI Picker Using an Swift Enum Part 2

In Part 1, we created a basic SwiftUI Picker that was bound to an enum variable that included n possible values. When users pick a value from the picker, the app’s data model is aware of this change and the UI updates to reflect the user’s selection.

In this post we are going to extend this basic functionality.

Display Text for Sort Types

Life would be better if we could customize the display text for each of the different sort types. To do this we will add a function to our enum.

    func displayText() -> String {
        switch self {
        case .name:
            return NSLocalizedString("Name", comment: "display text for sort type: name")
        case .height:
            return NSLocalizedString("Height", comment: "display text for sort type: height")
        case .averageScore:
            return NSLocalizedString("Average Score", comment: "display text for sort type: averageScore")
        }
    }

In order to use this new function, replace rawValue calls with displayText() calls.

struct ContentView: View {
    @ObservedObject var settings = Settings.shared
    var body: some View {
        VStack {
            Picker(selection: $settings.sortType, label: Text("Sort Type")) {
                ForEach(SortType.allCases, id: \.self) { sortType in
                    Text("\(sortType.displayText())")
                }
            }
            Text("sort type is: \(settings.sortType.displayText())")
        }
    }
}

Persist Preferred Sort Type

In this section we will add code to remember a user’s previously selected sort type. So if the user closes the app and relaunches it, their preferred sort type will still be selected. To do this, we will write the sortType to UserDefaults, and then read this value when the app launches. These changes will be made in the Settings class.

class Settings: ObservableObject {
    static let shared = Settings()
    @Published var sortType: SortType {
        didSet {
            UserDefaults.standard.setValue(sortType.rawValue, forKey: "sortType")
        }
    }
    init() {
        sortType = SortType(rawValue: UserDefaults.standard.string(forKey: "sortType") ?? "name") ?? .name
    }
}

I’m mildly pained by the need to include both a fallback value for the string read from UserDefaults and also a fallback value SortType(rawValue: ) return value. I guess this is just my way to demonstrate that I don’t like forced unwraps !

Add a New Sort Type

So what happens when end requirements change and now our data can also be sorted by…. let’s say Shoe Size? What needs to change in our example? In fact, very little needs to change. Basically just add the new enum case, and add a corresponding case to the displayText function

enum SortType: String, CaseIterable {
    case name
    case height
    case averageScore
    case shoeSize
    
    func displayText() -> String {
        switch self {
        case .name:
            return NSLocalizedString("Name", comment: "display text for sort type: name")
        case .height:
            return NSLocalizedString("Height", comment: "display text for sort type: height")
        case .averageScore:
            return NSLocalizedString("Average Score", comment: "display text for sort type: averageScore")
        case .shoeSize:
            return NSLocalizedString("Shoe Size", comment: "display text for sort type: shoeSize")
        }
    }
}
Categories
Software Uncategorized

A SwiftUI Picker Using an Swift Enum

These two items (the SwiftUI Picker and a Swift enum) work really well together. Some might say they go together as well as Peanut Butter and Banana.

Requirement: Your app needs a way for a user to choose how to sort their list items. Today list items can be sorted by Name, Height and Average Score. Some time in the future, the list of sort types is expected to grow.

Eventually we are going to need some UI for this, but let’s start be defining an enum to define the sort types. Our enum needs to conform to CaseIterable because we will need to call the allCases class method. I don’t think String is required, but is helpful in the initial stage before we polish the UI.

enum SortType: String, CaseIterable {
    case name
    case height
    case averageScore
}

And also a Settings model object to store our source of truth (ie sort type) We will access the Settings singleton via the shared static variable. Settings needs to conform to ObservableObject because the Picker will bind to the sortType property.

class Settings: ObservableObject {
    static let shared = Settings()
    @Published var sortType: SortType
    init() {
        sortType = .name
    }
}

For the UI, we will use the following Picker init

    public init(selection: Binding<SelectionValue>, label: Label, @ViewBuilder content: () -> Content)

The UI content view will start with something like this:

struct ContentView: View {
    @ObservedObject var settings = Settings.shared
    var body: some View {
        VStack {
            Picker(selection: $settings.sortType, label: Text("Sort Type")) {
                ForEach(SortType.allCases, id: \.self) { sortType in
                    Text("\(sortType.rawValue)")
                }
            }
            Text("sort type is: \(settings.sortType.rawValue)")
        }
    }
}

If we run this code, we’ll see a picker above a text label. When we pick a different value in the picker, the text label updates accordingly. Woot!

In Part 2, we will:

  1. Improve the UI by adding display names for the sort types
  2. Use UserDefaults to persist and recall the selected sort type
  3. Add another sort type