Categories
Software

WWDC 2021

No this does not refer to the Western Washington Debutantes Convention. Today is the first day of Apple’s World Wide Developers Conference. For anyone who writes software for iPhones, iPads, Watches, and Apple computers, it tends to be a very exciting week.

Sometimes there are new hardware announcements and releases. Other times there are big technology changes, such as a new development language (eg Swift!). Every time there are a lot of new technology announcements, that are usually obscure as heck. (eg. a new interface for coding In App Purchases)

Buried among the intimidating amount and complexity of detailed information, there are usually a few fun nuggets of new things I find very cool. So far this year, the best example of this is a new feature in the photos app that detects text in photos. Users will be able to copy text in photos and paste it into any other apps. They will also be able to detect and call phone numbers when they show up in photos. Crazy!

Before Covid, the conference was in San Francisco and the information was really only available to people who attended in person. Some time in the past 10 years the conference became ridiculously over subscribed and it became a lottery to be able to attend. At about the same time the information from all the presentations was made available on line.

The last two years, due to Covid, the conference was entirely online and free for everyone. (Attending in person in previous years typically cost ~$1500 USD.)

I have been to WWDC twice, once in 2004 and once in 2010. In 2004, I was attending with a co-worker who was very much a night owl. He would typically arrive at work around 11am. At WWDC I was very perplexed when he insisted we arrive at 6am for the Keynote Address on the first day that didn’t start until 10am.

When we arrived at 6am, there were already hundreds of people in line. I later realized this was most likely due to the personality cult around Steve Jobs. While I’d like to think I wasn’t susceptible to his reality distortion field, it was still pretty exciting to be in the room for his presentations.

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
Categories
Software

Zentangle App

I’ve already mentioned my affinity for making zentangles however I often struggle with choosing which tangles to include. I always fear I’ll get in a rut and repeatedly pick the same tangles, and miss out on others that would feel good to draw. However the only thing worse than inadvertently ignoring an old favourite would be spending a lot of time and energy diligently making sure my picking was fair.

To this end, I want to build an app that will keep track of all the tangles, and which ones I’ve used most, and also allow me to pick some of my favourites. Also (not sure how useful this will be) it’d be nice to present a set of suggestions that include different types of patterns.

All this to say, I’ve been working on an app that uses the CloudKit framework to store both the immutable and the mutable tangle details. I’ve come across a few interesting technical challenges along the way. My plan is to create some posts to describe some of these challenges and things I’ve learned about CloudKit.

possible topics:

  • turning a swiftUI Image into a Navigation Link and it turns blue
  • connecting an enum to a swiftUI Picker
  • the value of being able to set recordId’s (and don’t forget to include the prefix)
  • challenges I’ve found when using iCloud dashboard (save needs to be clicked twice, adding index loses recent edits)
  • SettingsView, userDefaults
  • tabBar via model
  • navViews in a tabBar seem to reset (or get confused if you switch tabs and come back