DEV Community: Diego Lavalle

Pausing and Reversing SwiftUI Animations

Diego Lavalle — Wed, 12 Aug 2020 17:15:34 +0000

Animations and transitions are decisively one of SwiftUI’s fortes. The framework allows us to go as deep as we want in handling specifics like timing function and duration parameters. Moreover it gives us sophisticated tools like the Animatable protocol to completely customize behavior. Here we are going to rely on the more constricted AnimatableModifier protocol to show how we can manually pause and resume and animation as well as adding the ability to reverse and loop over.

A Boring Animation

To focus on function rather than visuals we are going to design what is probably the simplest animation possible: a counter. We will display a number on screen which can be counting up or down within a range like some kind of stopwatch.

We’ll start by creating a basic ViewModifier containing a numeric value formatted to display as a zero-padded positive integer. The value is calculated as a percentage over a maximum which is taken as parameter.

struct CountModifier: ViewModifier {

  var maxValue: CGFloat // Maximum count value
  var timeDuration: Double // How long it will take to reach max, in seconds

  private let percentValue: CGFloat = 0 // Percentage of the maximum count

  // Counter value as integer
  var value: Int {
    Int(percentValue * maxValue)
  }

  func body(content: Content) -> some View {
    Text("\(value, specifier: "%03d")") // Formatted count
    .font(.system(.largeTitle, design: .monospaced))
    .font(.largeTitle)
  }
}

Notice how in this case we are simply ignoring the input view and returning a fresh body. So we are not really modifying anything but rather replacing it entirely. Additionally we added a timeDuration argument which will be useful to customize the duration of the animation.

Adding External Controls

Outside of the numeric display we want to show a set of controls for pausing and reversing the count. These can be regular buttons which modify state variables defined on the main content view.

struct CountDownUp: View {

  @State var isCounting = false // Whether we are counting (moving)
  @State var isReversed = false // The direction of the count: up or down

  var body: some View {
    VStack {
      EmptyView()
      .modifier(
        CountModifier(
          maxValue: 100, // We'll count to 100
          timeDuration: 10 // In 10 seconds
        )
      )
      HStack {
        Button(isCounting ? "⏸" : "▶️") {
          isCounting.toggle() // Pause / resume
        }
        Button(isReversed ? "🔽" : "🔼") {
          isReversed.toggle()  // Count up / down
        }
      }
      .frame(maxWidth: .infinity, maxHeight: .infinity, alignment: .top)
    }
  }
}

As an added touch we made the buttons adapt to the current status of the counter thus providing an instant feedback.

Communicating with the Modifier

Because the animation will change depending on the state determined by our external controls we'll necessarily have to pass these variables as bindings:

fileprivate struct CountModifier: ViewModifier {

  var maxValue: CGFloat // Maximum count value
  var timeDuration: Double
  @Binding var percentage: CGFloat
  @Binding var isCounting: Bool
  @Binding var isReversed: Bool

  private var percentValue: CGFloat // Percentage of maximum count

  init(
    maxValue: CGFloat,
    timeDuration: Double,
    percentage: Binding<CGFloat>,
    isCounting: Binding<Bool>,
    isReversed: Binding<Bool>
  ) {
    self.maxValue = maxValue
    self.timeDuration = timeDuration
    _percentage = percentage // Bindings initialization
    _isCounting = isCounting
    _isReversed = isReversed
    // The percent value is copied  from the binding, later on it will be used for the animation
    percentValue = percentage.wrappedValue
  }

  var value: Int {
    Int(percentValue * maxValue)
  }

  func body(content: Content) -> some View {
    Text("\(value, specifier: "%03d")")
    .font(.system(.largeTitle, design: .monospaced))
    .font(.largeTitle)
  }
}

We also included a binding to a percentage which indirectly initializes the internal percentValue variable by copying its current value. Remember this percentage drives the number on display at any given time during the course of the animation.

The reason why this piece of state needs to be declared outside of the modifier will be revealed momentarily. For now let's just add percentage to our root view:

struct CountDownUp: View {

  @State var percentage = CGFloat(0)
  …

  var body: some View {
    VStack {
      EmptyView()
      .modifier(
        CountModifier(
          …
          percentage: $percentage,
          …
        )
      …

Great! We now have state shared between controls and display but there is still no actual animation happening.

Animating the Counter

The way AnimatableModifier works, in order to animate a certain value we need to declare a writable computed property named animatableData backed by some stored property. To turn CountModifier into an AnimatableModifier we'll base our animatable data on the aforementioned percentage value.

struct CountModifier: AnimatableModifier {

  var animatableData: CGFloat {
    get { percentValue }
    set { percentValue = newValue }
  }
  …

Apart from needing to use CGFloat as opposed to regular double/single precision floating point scalars which is required by the protocol, the implementation of the property is as trivial as it gets.

Triggering the Animation

To kick-start the counter we will be adding an onChange handler to watch over the contents of isCounting. This is an iOS 14+ only feature. In the accompanying source code (see working example) you'll find a work-around for iOS 13 that uses PassthroughSubject to send the start signal.

struct CountModifier: AnimatableModifier {
  …
  func body(content: Content) -> some View {
    Text("\(value, specifier: "%03d")")
    …
    .onChange(of: isCounting) { _ in
      handleStart()
    }
  }

  func handleStart() -> () {
    if isCounting {
      withAnimation(.linear(duration: timeDuration)) {
        self.percentage = 1
      }
    }
  }
  …

We handle isCounting being set by using that binding directly to set off the animation.

Pausing and Resuming

Now in order to pause the animation we need to enrich our change handler for the isCounting variable as it now can switch from on to off. We will also introduce a timeRemaining property that will tell us exactly how long we have left on the full duration of the count. Finally for the sake of semantics we'll rename handleStart into the more descriptive handleStartStop:

struct CountModifier: AnimatableModifier {
  …
  var timeRemaining: Double {
    timeDuration * Double(1 - percentValue)
  }

  func body(content: Content) -> some View {
    Text("\(value, specifier: "%03d")")
    …
    .onChange(of: isCounting) { _ in
      handleStartStop()
    }
  }

  func handleStartStop() -> () { // Formerly handleStart()
    if isCounting {
      withAnimation(.linear(duration: timeRemaining)) {
        self.percentage = 1
      }
    } else {
      withAnimation(.linear(duration: 0)) {
        self.percentage = percentValue
      }
    }
  }
  …

The thing to notice here is that this time remaining approach only works for linear animations. More advanced timing functions would absolutely complicate the calculation that enables us to resume movement after pausing.

Looping over

It would be nice if our counter doesn’t just stop when it reaches the limit. For this we are forced into hijacking body() to check whether the percentage has reached its maximum value of 1, in which case we'll force it back to zero.

struct CountModifier: AnimatableModifier {
  …
  func body(content: Content) -> some View {
    // Loop when we reach completion
    if percentValue == 1 {
      DispatchQueue.main.async {
        self.percentage = 0
        withAnimation(.linear(duration: self.timeDuration)) {
          self.percentage = 1
        }
      }
    }
    return actualBody(content) // Original body of the view
  }

  // Moved the original body into a separate function
  func actualBody(_ content: Content) -> some View {
    Text("\(value, specifier: "%03d")")
    …
  }
  …

After resetting the percentage we'll kick it off again with an asynchronous call. To keep things clean we'll move the previous body function into actualBody to keep taking advantage of the enhanced ViewBuilder syntax.

Shift into Reverse

Whether the counting is on or now, we want to be able to change the direction. For this we monitor isReversed for changes and handle the new value using the same technique as before. We'll also need to alter the start/stop and the loop logic to take into consideration the current direction.

struct CountModifier: AnimatableModifier {
  …
  var timeRemaining: Double {
    isReversed
    ? timeDuration * Double(percentValue)
    : timeDuration * Double(1 - percentValue)
  }

  func body(content: Content) -> some View {
    if (isReversed && percentValue == 0) || (!isReversed && percentValue == 1) {
      DispatchQueue.main.async {
        self.percentage = self.isReversed ? 1 : 0
        withAnimation(.linear(duration: self.timeDuration)) {
          self.percentage = self.isReversed ? 0 : 1
        }
      }
    }
    return actualBody(content)
  }

  func actualBody(_ content: Content) -> some View {
    Text("\(value, specifier: "%03d")")
    …
    .onChange(of: isReversed) { _ in
      handleReverse()
    }
  }

  func handleStartStop() -> () {
    if isCounting {
      withAnimation(.linear(duration: timeRemaining)) {
        self.percentage = isReversed ? 0 : 1
      }
    } else { … }
    }
  }

  func handleReverse() -> () {
    if isCounting {
      withAnimation(.linear(duration: 0)) {
        self.percentage = percentValue
      }
      withAnimation(.linear(duration: timeRemaining)) {
        self.percentage = isReversed ? 0 : 1
      }
    }
  }
}

Notably the time remaining was re-calculated by pondering the percentage or its inverse in the case of counting downwards.

Final Thoughts

This is a fun way of gaining control over events within a linear animation. It's definitely not the only one and might not even the preferred way as it does involve some hacks. But on the other hand it has as an advantage the simplicity of not having to deal with the Animatable protocol directly.

That's it, as always check out the associated Working Example for the complete source code and interactive demo.

FEATURED EXAMPLE: Count Down Up - Some kinda stopwatch

Computed properties as synthesized bindings

Diego Lavalle — Thu, 06 Aug 2020 14:55:47 +0000

Computed properties are useful in so many ways and within the context of SwiftUI they are even more powerful. We can use them to split up our view body while keeping access to the same data. Or we can derive new values from our state that will recalculate with every change. We can also use computed properties in model objects, observing and even setting their values via synthesized bindings.

Italian dishes

Suppose we have a list of classic Italian dishes that we want to display. Each dish can be added or removed from our favorites but only one of them at a time can be pinned to the top of the list.

We would start with a simple model:

struct Dish: Identifiable {
  let id = UUID()
  let name: String
  var isFavorite = false

  static let allDishes = [
    Dish(name: "🍝 Spaghetti Carbonara"),
    Dish(name: "🧀 Eggplant Parmigiana"),
    Dish(name: "🍮 Classic Panna Cotta"),
    Dish(name: "🥗 Caprese Salad")
  ]
}

We have our named dishes which we can favorite. Now let's store them in an ObservableObject together with a new pinnedId variable to help us keep track of which dish is currently featured at the top of the list.

class UserData: ObservableObject {

  @Published var dishes: [Dish] = Dish.allDishes  
  @Published var pinnedId: UUID = Dish.allDishes[0].id

  static let shared = UserData()
}

We selected the first dish as the default one to be pinned and we added a shared singleton instance of our user data.

Now let's create a view to display all of these delicacies. We'll start with a single row showing the dish's name, favorite status and pinned status:

struct DishRow: View {

  let dish: Dish
  let pinnedId: UUID

  var body: some View {
    HStack {
      if dish.id == pinnedId {
        Text("📌")
      }

      Text(dish.name)

      Text("\(dish.isFavorite ? "💗" : "🤍")")
    }
    .padding()
  }
}

We can now show our list of all dishes:

struct DishList: View {

  let dishes: [Dish]
  let pinnedId: UUID

  var body: some View {
    VStack {
      ForEach(dishes) { dish in
        DishRow(dish: dish, pinnedId: pinnedId)
      }
    }
  }
}

Pinning the top dish

Let's hide the pinned dish from the list as we will put it back later at the top of the view.

…
ForEach(dishes) { dish in
  if dish.id != pinnedId {
    DishRow(dish: dish, pinnedId: pinnedId)
  }
}
…

Now let's compose a vertical stack with our list and the pinned dish as a single row at the top. We can feed data to both list and row straight from our user data instance which we'll also observe for changes.

struct FaveDishes: View {

  @ObservedObject var data = UserData.shared

  var body: some View {
    VStack {
      DishRow(dish: data.pinnedDish, pinnedId: data.pinnedId)
      Divider()
      DishList(dishes: data.dishes, pinnedId: data.pinnedId)
      Spacer()
    }
  }
}

This is all great but you may have noticed we didn't actually add any capabilities to change the status of our dishes. Every view so far has been display-only.

Enabling views to modify the dish's status

Let's then prepare our views for modifying the dishes' status by swapping a few let's for some @Binding var's starting with the row view:

struct DishRow: View {

  @Binding var dish: Dish
  @Binding var pinnedId: UUID
  …

This will allow each row to modify itself, changing the favorite status or selecting the dish for pinning. But first we need to make sure we generate and pass those bindings to the row initializer.

For this we work our way up to the dish list. We'll have to iterate over the indices of our dishes array to be able to reference both the dish and its corresponding binding.

struct DishList: View {

  @Binding var dishes: [Dish]
  @Binding var pinnedId: UUID?

  var body: some View {
    VStack {
      ForEach(dishes.indices) { i in
        if dishes[i].id != pinnedId {
          DishRow(dish: $dishes[i], pinnedId: $pinnedId)
        }
        …

As you can see we used the index to get our Binding<Dish> from the synthesized $dishes variable which is itself an array of dish bindings.

Now let's try to apply the same treatment to our root view:

struct FaveDishes: View {

  @ObservedObject var data = UserData.shared

  var body: some View {
    VStack {
      DishRow(
        dish: $data.dishes[
          data.dishes.firstIndex { $0.id == data.dishes.pinnedDish }!
        ],
        pinnedId: $data.pinnedId
      )
      Divider()
      DishList(dishes: $data.dishes, pinnedId: $data.pinnedId)
      Spacer()
    }
  }
}

Noticed anything odd? We will come back to that snippet later on the following section.

And finally we can modify the status of each dish represented in a row. While we are at it, let's split the body in three using computed properties:

struct DishRow: View {

  @Binding var dish: Dish
  @Binding var pinnedId: UUID

  var body: some View {
    HStack {
      pinIndicator
      Text(dish.name)
      favoriteIndicator
    }
  }

  var pinIndicator: some View {
    VStack {
      if dish.id == pinnedId {
        Text("📌")
      } else {
        Button("Pin") {
          pinnedId = dish.id
        }
      }
    }
  }

  var favoriteIndicator: some View {
    Button("\(dish.isFavorite ? "💗" : "🤍")") {
      self.dish.isFavorite.toggle()
    }
  }
}

Much cleaner and we now can express our love for these delicious items.

Bound computed properties

You may have noticed though at the end of the previous section a particular expression, so intricately beautiful that it had to be split among three lines of code. Here it is in all its splendor:

$data.dishes[
  data.dishes.firstIndex { $0.id == data.dishes.pinnedDish }!
]

Once again we are referencing an array of dish bindings except this time we don't have the index to the pinned dish so we need to look that up.

One possible improvement would be to provide the pinned dish index as a computed property on our data store. We could also manually create an explicit binding which would obviate the use of @ObservedObject. But what if we could compute the whole pinned dish variable – complete with getter and setter – for observing views to bind to?

class UserData: ObservableObject {
  …
  var pinnedDish: Dish? {
    get {
      return dishes.first { $0.id == pinnedId }!
    }
    set {
      if let i = dishes.firstIndex(where: { $0.id == pinnedId }) {
        dishes[i] = newValue
      }
    }
  }
}

So the great thing about computed properties on observed objects is that they get their own synthesized binding! This way our ugly duckling expression can turn into a beautiful one-line swan:

…
DishRow(dish: $data.pinnedDish, pinnedId: $data.pinnedId)
…

And it's all transparent to the views.

Optional bindings

Our widget now totally works as expected but it would be nice if we had the option not to feature any specific dish at all since we love them all the same.

First thing we'd need to do is turn pinnedId into an optional:

class UserData: ObservableObject {

  @Published var pinnedId: UUID?
  …

After this modification most of our views will only need to adapt slightly and in fact so will our pinnedDish computed property with a few minor changes. But what will happen to its synthesized binding?

Well since $data.pinnedDish now returns a Binding<Dish?> we can't simply unwrap it to pass it to DishRow. Fortunately the framework provide us with a tool for this one specific situation: a binding initializer that takes a binding of an optional and returns a binding optional Binding<Dish>?.

struct FaveDishes: View {

  @ObservedObject var data = UserData.shared

  var body: some View {
    VStack {
      if data.pinnedDish != nil {
        DishRow(
          dish: Binding<Dish>($data.pinnedDish)!,
          pinnedId: $data.pinnedId
        )
        Divider()
      }
      DishList(dishes: $data.dishes, pinnedId: $data.pinnedId)
    }
  }
}

Now we can feature a dish only if we want. Otherwise we'll just show the regular full menu.

That's all, please check out the associated Working Example to see this technique in action and to view its full source code.

FEATURED EXAMPLE: Fave Dishes - Heart or pin your favorite dish

On-demand bindings

Diego Lavalle — Mon, 03 Aug 2020 11:19:33 +0000

Bindings are used to pass parts of our state down to a subview that might later on make changes to said state. We typically rely on the @State and @Binding property wrappers to generate bindings for us but bindings can also be constructed programmatically. In fact there's a handful of cases in which creating bindings in an on-demand manner may just be the preferred option.

Like most UI controls in SwiftUI, Toggle is backed by a binding. In this case the initializer argument isOn of type Binding<Bool> informs the toggle whether it is on or off but most importantly, it also allows the control to alter the value of this variable from the inside. Now imagine that we have -as part of our state- a whole set of toggable models which we want represented in our user interface as individual toggle controls.

struct Toggles: View {

  struct Model: Identifiable {
    var id: String // Also used as label
    var on = false
  }

  @State var items = [
    Model(id: "foo"),
    Model(id: "bar"),
    Model(id: "baz"),
  ]

  var body: some View { … }
}

We can leverage SwiftUI's auto-generated bindings and reference the $items property which is bound to the items state variable. Given that ForEach can only iterate over sequences -not bindings of sequences- we need initialize it with items.indices instead. Each index gives us direct access to both an element of our state -a Model instance- and its corresponding binding.

var body: some View {
  VStack {
    ForEach(items.indices) {
      Toggle(
        self.items[$0].id, // Label
        isOn: self.$items[$0].on // Binding
      )
    } // ForEach
  } // VStack
} // body

This works fine except for one thing: the specification of ForEach warns us that iterating over ranges only applies to constant data. Now as far as our view is concerned, the element count for items could change overtime since the whole array is tagged with @State on its declaration. Let's suppose we want to enable the possibility of removing a toggle altogether.

ForEach(…) {
  HStack {
    Toggle(…)
    Button("remove") {
      // TODO: remove item from items array
    }
  }
}

Because we made our Model struct comply with the Identifiable protocol it's easy iterate over our items. But we still need a binding for Toggle to work with. We can instantiate the binding on-the-fly provided that we always use up-to-date indices to look up for items inside our array.

…
func makeBinding(_ item: Model) -> Binding<Bool> {
  let i = self.items.firstIndex { $0.id == item.id }!
  return .init(
    get: { self.available[i].on },
    set: { self.available[i].on = $0 }
  )
}

var body: some View {
  …
  ForEach(items) { item in
    HStack {
      Toggle(
        item.id,
        isOn: self.makeBinding(item)
      )
      Button("remove") {
        self.items.removeAll { $0.id == item.id }
      }
    }
  }
  …
}

We call the makeBinding function every time a toggle is rendered. The function first finds the current index for the specified item and uses it to produce both the getter and setter that make up the binding object. The remove button simply mutates our items array normally since it's declared as part of the view's state.

Check out the associated Working Example to see this technique in action.

FEATURED EXAMPLE: Toggles - Add'em, flip'em, hide'em!

Keyboard-aware views

Diego Lavalle — Sun, 02 Aug 2020 18:52:35 +0000

Sometimes we want to give our views a chance to react to the software keyboard being pulled up. This could be particularly useful in forms with text input where the keyboard might cover the very field we are typing into. We can solve this in SwiftUI with a little help from some old friends.

UIKit's UIResponder is an interface that provides notifications for a variety of UI-related events, including keyboard events. By subscribing to keyboardDidShowNotification we get the timely information we need via keyboardFrameEndUserInfoKey which contains the keyboard frame.

We'll start by creating an ObservableObject containing the current keyboard frame. There can only be one software keyboard so we'll make our class a singleton. The frame property is published so that we can subscribe to it from our views.

import Foundation
import UIKit
import CoreGraphics
import Combine

class KeyboardProperties: ObservableObject {

  static let shared = KeyboardProperties()

  @Published var frame = CGRect.zero

  var subscription: Cancellable?

  init() {
    subscription = …
  }
}

Now to populate our frame property we'll need to tap into NotificationCenter. In particular we are interested in the following UIResponder events: keyboardDidShowNotification and keyboardDidHideNotification. We'll use the Combine framework to filter out the information we want from these notifications - namely the keyboard frame - and assign it to the corresponding instance property.

subscription = NotificationCenter.default
  .publisher(for: UIResponder.keyboardDidShowNotification)
  .compactMap { $0.userInfo }
  .compactMap {
    $0[UIResponder.keyboardFrameEndUserInfoKey] as? CGRect
  }
  .merge(
    with: NotificationCenter.default.publisher(for: UIResponder.keyboardDidHideNotification).map { _ in
      CGRect.zero
    }
  )
  .assign(to: \.frame, on: self)

For demonstration purposes we are going to create a simple SwiftUI view based on a vertical stack with a text field at the bottom. Without any additional logic, the text field will be covered by the rising software keyboard.

@State var textValue = ""

var body: some View {
  VStack {
    // Pushes TextField to the bottom of view
    Spacer()

    // Text field would be covered by keyboard
    TextField("Enter some text", text: $textValue)
  }
}

To help us we can now bring in our KeyboardProperties singleton using the @ObservedObject property wrapper. Since we're specifically interested in the keyboard's height, we'll put that in a calculated kbHeight property. Finally, we use this height to offset our text field, so that it is no longer covered up by the keyboard.

…

@ObservedObject var keyboardProps = KeyboardProperties.shared

var kbHeight: CGFloat {
  keyboardProps.frame.height
}

var body: some View {
  VStack {
    …
    TextField("Enter some text", text: $textValue)
      // Text field will now be pushed up by the keyboard
      .offset(y: -kbHeight)
      // A little animation to soothe things up
      .animation(.easeIn(duration: 0.2))
  }
}

That's it, we have successfully made our form keyboard-aware solving a serious user experience issue. Please check out the associated Working Example to see this technique in action.

FEATURED EXAMPLE: All Rise! - Software keyboard in da view

Codable observable objects

Diego Lavalle — Sat, 01 Aug 2020 11:56:43 +0000

Complying to the Codable protocol is simple thanks to synthesized initializers and coding keys. Similarly making your class observable using the Combine framework is trivial with ObservableObject. But attempting to merge these two protocols in a single implementation poses a few obstables. Let's find out!

A simple class can be made Encodable and Decodable simultaneously by simply declaring it as Codable.

class CodableLandmark: Codable {

  var site: String = "Unknown site"
  var visited: Bool = false
}

After this you can easily convert objects to JSON format and back.

import Foundation

class CodableLandmark: Codable {
  …

  // Encode this instance as JSON data
  var asJsonData: Data? {
    try? JSONEncoder().encode(self)
  }

  // Create an instance from JSON data
  static func fromJsonData(_ json: Data) -> Self? {
    guard let decoded = try? JSONDecoder().decode(Self.self, from: json) else {
      return nil
    }
    return decoded
  }
}

An identical class could alternatively serve as a model for some SwiftUI view simply by adhering to ObservableObject. Annotating properties with the @Published wrapper will ensure that notifications are generated when these values change.

import Combine

class ObservableLandmark: ObservableObject {

  @Published var site: String = "Unknown site"
  @Published var visited: Bool = false
}

Initially just adding the ObservableObject to our codable class' protocol list produces no error. But when we try to mark the first variable as published we encounter error messages Type 'LandmarkModel' does not conform to protocol 'Decodable' and Type 'LandmarkModel' does not conform to protocol 'Encodable' error.

class LandmarkModel: Codable, ObservableObject {

  @Published // Error
  var site: String = "Unknown site"

  @Published // Error
  var visited: Bool = false
}

The solution is to simply implement some of the Codable requirements manually rather than have them synthesized. Namely the initializer (for decoding) and the encode function for encoding. This forces us to additionally declare our coding keys explicitly.

class LandmarkModel: Codable, ObservableObject {
  …

  // MARK: - Codable
  enum CodingKeys: String, CodingKey {
    case site
    case visited
  }

  // MARK: - Codable
  required init(from decoder: Decoder) throws {
    let values = try decoder.container(keyedBy: CodingKeys.self)
    site = try values.decode(String.self, forKey: .site)
    visited = try values.decode(Bool.self, forKey: .visited)
  }

  // MARK: - Encodable
  func encode(to encoder: Encoder) throws {
    var container = encoder.container(keyedBy: CodingKeys.self)
    try container.encode(site, forKey: .site)
    try container.encode(visited, forKey: .visited)
  }
}

This approach of tightly coupling the codable and observable models can be useful for simple projects as it avoids a lot of boilerplate code.

Check out the associated Working Example to see this technique in action.

FEATURED EXAMPLE: Real-Time JSON - Observe the codable object

Originally published at Swift You and I.

SwiftUI Scroll Magic

Diego Lavalle — Fri, 31 Jul 2020 10:47:59 +0000

Scroll views in SwiftUI are very straight-forward but give us no information or control over the current position of its content. So how can we detect for instance that the user has scrolled beyond certain threshold off the top?

Suppose we have some scrollable content with a title bar that is outside the ScrollView.

public struct JumpingTitleBar: View {

  var scrollView: some View {
    ScrollView(.vertical) {
      Text("""
      Scroll down to see the title bar jump from top to bottom.
      …
      """)
    }
  }

  var topBar: some View { … }
  var bottomBar: some View { … }

  var body: some View {
    ZStack {
      scrollView
      VStack {
        topBar
        Spacer()
        bottomBar
      }
    }
  }
}

We want the title bar to jump to the bottom once the user started scrolling down the text. Let's start by adding an onTop state variable to represent this behavior.

@State var onTop = true

var body: some View {
  ZStack {
    scrollView
    VStack {
      if onTop { topBar }
      Spacer()
      if !onTop { bottomBar }
    }
  }
}

Now for the magic bit of the article, how do we actually find out what the offset of the contents is at all times? For this we leverage .anchorPreference.

Anchor preferences let us compile geometry data about our descendants, of which our scrollable Text is part. We start by defining the key type with a default value and a reducer.

struct OffsetKey: PreferenceKey {
  static var defaultValue: CGFloat = 0
  static func reduce(value: inout CGFloat, nextValue: () -> CGFloat) {
    value = nextValue()
  }
}

From the text view itself we report our top anchor's y position to our ancestors.

  GeometryReader { g in
    ScrollView(.vertical) {
      Text(…)
      .anchorPreference(key: OffsetKey.self, value: .top) {
        g[$0].y
      }
      …

We will catch the offset value on the flip side using the onPreferenceChange() modifier on the scroll view itself.

var body: some View {
  ZStack {
    scrollView
    .onPreferenceChange(OffsetKey.self) {
    …
    }
    …

At this point the only thing remaining is to update our internal state according to the received offset.

…
scrollView
.onPreferenceChange(OffsetKey.self) {
  if $0 < -10 {
    self.onTop = false
  } else {
    self.onTop = true
  }
}
…

The title bar now slides away shortly after we start scrolling down and the footer instantly fades in. The whole action reverses when scrolling all the way back to the top.

For sample code featuring this and other techniques please checkout our working examples repo.

FEATURED EXAMPLE: Scroll Magic - See the title bar jump from top to bottom

Originally published at Swift You and I

Detecting When an Animation Has Ended

Diego Lavalle — Thu, 30 Jul 2020 19:43:19 +0000

Whenever a SwiftUI animation is triggered, its state is updated immediately regardless of the duration. The Animation struct does not provide us with any sort of callback to indicate whether it has completed. So how can we detect when our views have stopped animating?

Suppose we want to animate the image of a little plane flying towards the moon. We start by declaring a view for the plane, the moon background and a state variable indicating the current distance from the ground. We lay all of this out on our main view's body.

struct PlaneMoonScene: View {

  @State var distance: CGFloat = 0

  var plane: some View {
    Image(systemName: "paperplane")
    …
  }

  var moonBackground: some View {
    Image(systemName: "moon.stars")
    …
  }

  var body: some View {
    ZStack(alignment: .bottomLeading) {
      moonBackground
      plane.offset(x: distance, y: -distance)
    }
  }
}

To kick off our flight we need to define a launch button. The button's action will animate the distance from 0 to 200 by applying the easeInOut() timing function for a total duration of 1 second.

struct PlaneMoonScene: View {
  …
  var launchButton: some View {
    Button("Launch!") {
      withAnimation(.easeInOut(duration: 1)) {
        self.distance = 200
      }
    }
  }

  var body: some View {
    ZStack {
      …
      launchButton
    }
  }
}

As expected pressing Launch! causes our little plane to shoot up and reach the moon. But what if we want to display a congratulatory message once our destination has been attained? For this we need to replace the offset() modifier that places the plane over the background with our own FlyModifier.

struct FlyModifier: AnimatableModifier {

  var totalDistance: CGFloat
  var percentage: CGFloat
  var onReachedDestination: () -> () = {}

  private var distance: CGFloat { percentage * totalDistance }

  …

  func body(content: Content) -> some View {
    content
    .offset(x: distance, y: -distance)
  }
}

Our FlyModifier also positions the plane at a specified distance but because it inherits from AnimatableModifier it has the ability to look at the animation parameters as they transition from initial value to target. Our modifier is applied similarly to offset() except this time around we do get a chance to provide a completion handler.

struct PlaneMoonScene: View {

  @State var percentage: CGFloat = 0
  …

  var body: some View {
    …
    plane.modifier(
      FlyModifier(totalDistance: 200, percentage: percentage) {
        // We have reached the moon!
      }
    )
  }
}

So how do we actually detect within FlyModifier that the total distance has been covered - or that the percentage value is 1, as in 100 percent of the distance? Well we need to implement the variable animatableData to comply with AnimatableModifier and in the setter of that variable we check for completion. If the animation has finished we asynchronously invoke the handler given to us by the main view.

struct FlyModifier: AnimatableModifier {
  …

  var animatableData: CGFloat {
    get { percentage }
    set {
      percentage = newValue
      checkIfFinished()
    }
  }

  func checkIfFinished() -> () {
    if percentage == 1 {
      DispatchQueue.main.async {
        self.onReachedDestination()
      }
    }
  }

  …
}

Finally we can celebrate reaching the moon!

struct PlaneMoonScene: View {

  @State var reachedMoon = false
  …

  var congrats: some View {
    Text("Congrats!!")
    …
  }

  var launchButton: some View {
    Button("Launch!") {
      withAnimation(.easeInOut(duration: 1)) {
        self.percentage = 1
      }
    }
  }

  var body: some View {
    ZStack {
      moonBackground
      plane.modifier(
        FlyModifier(totalDistance: 200, percentage: percentage) {
          withAnimation { self.reachedMoon.toggle() }
        }
      }
      launchButton
      if reachedMoon {
        congrats
      }
    }
  }
}

For sample code featuring this and other techniques please checkout our working examples repo. Featured Example: Moonshot.

Originally published at Swift You and I

Form Validation with Combine

Diego Lavalle — Mon, 20 Jan 2020 17:19:12 +0000

In WWDC 2019 session Combine in Practice we learned how to apply the Combine Framework to perform validation on a basic sign up form built with UIKit. Now we want to apply the same solution to the SwiftUI version of that form which requires some adaptation.

We begin by declaring a simple form model separate from the view…

class SignUpFormModel: ObservableObject {
  @Published var username: String = ""
  @Published var password: String = ""
  @Published var passwordAgain: String = ""
}

And link each property to the corresponding TextField control…

struct SignUpForm: View {

  @ObservedObject var model = SignUpFormModel()

  var body: some View {
    …
    TextField("Username", text: $model.username)
    …
    TextField("Password 'secreto'", text: $model.password)
    …
    TextField("Password again", text: $model.passwordAgain)
    …

Now we can begin declaring the publishers in our SignUpFormModel. First we want to make sure the password has mor than six characters, and that it matches the confirmation field. For simplicity we will not use an error type, we will instead return invalid when the criteria is not met…

var validatedPassword: AnyPublisher<String?, Never> {
  $password.combineLatest($passwordAgain) { password, passwordAgain in
    guard password == passwordAgain, password.count > 6 else {
      return "invalid"
    }
    return password
  }
  .map { $0 == "password" ? "invalid" : $0 }
  .eraseToAnyPublisher()
}

For the user name we want to simultate an asynchronous network request that checks whether the chosen moniker is already taken…

func usernameAvailable(_ username: String, completion: @escaping (Bool) -> ()) -> () {
  DispatchQueue.main .async {
    if (username == "foobar") {
      completion(true)
    } else {
      completion(false)
    }
  }
}

As you can see, the only available name in our fake server is foobar.

We don't want to hit our API every second the user types into the name field, so we leverage debounce() to avoid this…

var validatedUsername: AnyPublisher<String?, Never> {
  return $username
    .debounce(for: 0.5, scheduler: RunLoop.main)
    .removeDuplicates()
    .flatMap { username in
      return Future { promise in
        usernameAvailable(username) { available in
          promise(.success(available ? username : nil))
        }
      }
  }
  .eraseToAnyPublisher()
}

Now to make use of this publisher we need some kind of indicator next to the text box to tell us whether we are making an acceptable choice. The indicator should be backed by a private @State variable in the view and outside the model.

To connect the indicator to the model's publisher we leverage the onReceive() modifier. On the completion block we manually update the form's current state…

Text(usernameAvailable ? "✅" : "❌")
.onReceive(model.validatedUsername) {
  self.usernameAvailable = $0 != nil
}

An analog indicator can be declared for the password fields.

Finally, we want to combine our two publishers to create an overall validation of the form. For this we create a new publisher…

var validatedCredentials: AnyPublisher<(String, String)?, Never> {
  validatedUsername.combineLatest(validatedPassword) { username, password in
    guard let uname = username, let pwd = password else { return nil }
    return (uname, pwd)
  }
  .eraseToAnyPublisher()
}

We can then hook this validation directly into our Sign Up button and its disabled state.

  Button("Sign up") { … }
  .disabled(signUpDisabled)
  .onReceive(model.validatedCredentials) {
    guard let credentials = $0 else {
      self.signUpDisabled = true
      return
    }
    let (validUsername, validPassword) = credentials
    guard validUsername != nil  else {
      self.signUpDisabled = true
      return
    }
    guard validPassword != "invalid"  else {
      self.signUpDisabled = true
      return
    }
    self.signUpDisabled = false
  }
}

Check out the associated Working Example to see this technique in action.

FEATURED EXAMPLE: Fake Signup - Validate your new credentials

You Don't Need UIImage

Diego Lavalle — Fri, 29 Nov 2019 13:53:42 +0000

The Image view provides a way to initialize it using UIKit's UIImage. This was used to work-around some early issues with Swift UI which prevented custom symbols to be scaled and colored.

Here's how we display, color and scale a built-in image:

Image(systemName: "heart.circle")
  .resizable()
  .aspectRatio(contentMode: .fit)
  .foregroundColor(.red)

And here's how we used to display a custom SVG image using UIImage as intermediary:

  Image(uiImage: UIImage(named: "heart.circle.custom")!)
    .resizable() // Dynamic sizing
    .aspectRatio(contentMode: .fit)
    .foregroundColor(.red)

Except that it would not take the foreground color and the scaling would be done by resampling a bitmap producing a low resolution result.

To work around these issue we would wrap the image in a dummy Button view, which would take care of the color. Then we would have to use a font size to scale the vector image in high resolution, like so:

Button(action: {}) { // Dummy button
  Image(uiImage: UIImage(named: "heart.circle.custom")!
    .withConfiguration(
        // Fixed size in points
        UIImage.SymbolConfiguration(pointSize: 100)
    )
  )
}
.foregroundColor(.red) // Color applied to button

But this still poses the problem of having to specify a static size. The solution is quite simple: avoid the use of UIImage and use the standard fixed method.

Image("heart.circle.custom")
  .resizable()
  .aspectRatio(contentMode: .fit)
  .foregroundColor(.red)

Works like a charm!

See below for a result comparison of each of the methods described on this post.

Originally posted at Swift You and I