SwiftUI Layout Protocol - Part 2

Preface

In Part 1 we explored the basics of the layout protocol, laying a solid foundation for understanding how layouts work. Now it’s time to delve deeper into some of the lesser-known features and how we can use them to our advantage.

Part 1 - Basics:

• What is a layout protocol?
• Family dynamics of view hierarchies
• Our first layout implementation
• Container Alignment
• Custom value: LayoutValueKey
• Default Spacing
• Layout attributes and Spacer()
• Layout Cache
• A good pretender
• Use AnyLayout to switch layouts
• Conclusion

Part 2 - Advanced Layout:

• Preface
• Custom animations
• Bidirectional custom values
• Avoiding layout loops and crashes
• Recursive layout
• Layout combination
• Insert two layouts
• Using bind parameters
• A useful debugging tool
• Final Thoughts

Custom animations

Let's start by writing a view container for a circular layout. We'll call it WheelLayout:

 struct ContentView : View {
 let colors : [ Color ] = [ .yellow , .orange , .red , .pink , .purple , .blue , .cyan , .green ]

 var body : some View {
 WheelLayout ( radius : 130.0 , rotation : .zero ) {
 ForEach ( 0 . . < 8 ) { idx in
 RoundedRectangle ( cornerRadius : 8 )
 .fill ( colors [ idx % colors .count ] .opacity ( 0.7 ) )
 .frame ( width : 70 , height : 70 )
 .overlay { Text ( "\( idx + 1 )" ) }
 }
 }
 }
 }
 struct WheelLayout : Layout {
 var radius : CGFloat
 var rotation : Angle
 func sizeThatFits ( proposal : ProposedViewSize , subviews : Subviews , cache : inout ( ) ) - > CGSize {
 let maxSize = subviews .map { $0 .sizeThatFits ( proposal ) } .reduce ( CGSize .zero ) {
 return CGSize ( width : max ( $0 .width , $1 .width ) , height : max ( $0 .height , $1 .height ) )
 }
 return CGSize ( width : ( maxSize .width / 2 + radius ) * 2 ,
 height : ( maxSize .height / 2 + radius ) * 2 )
 }
 func placeSubviews ( in bounds : CGRect , proposal : ProposedViewSize , subviews : Subviews , cache : inout ( ) )
 {
 let angleStep = ( Angle .degrees ( 360 ) .radians / Double ( subviews .count ) )
 for ( index , subview ) in subviews .enumerated ( ) {
 let angle = angleStep * CGFloat ( index ) + rotation .radians
 // Find a vector with an appropriate size and rotation.
 var point = CGPoint ( x : 0 , y : - radius ) .applying ( CGAffineTransform ( rotationAngle : angle ) )
 // Shift the vector to the middle of the region.
 point.x + = bounds.midX​​
 point.y + = bounds.midY​​
 // Place the subview.
 subview .place ( at : point , anchor : .center , proposal : .unspecified )
 }
 }
 }

SwfitUI provides built-in animation support when the layout changes. So if we change the rotation value of the wheel to 90 degrees, we can see how it gradually moves to the new position:

 WheelLayout ( radius : radius , rotation : angle ) {
 // ...
 }
 Button ( "Rotate" ) {
 withAnimation ( .easeInOut ( duration : 2.0 ) ) {
 angle = ( angle == .zero ? .degrees ( 90 ) : .zero )​
 }
 }

This is great and I could have ended the animation section right there. However, you already know that our blog doesn’t just scratch the surface, so let’s take a deeper look at what’s going on.

As we change the angle, SwiftUI calculates the initial and final positions of each view, and then modifies their positions over the duration of the animation to form a straight line from point A to point B. It may not seem to do this at first, but examine the animation below, focusing on the individual views, to see how they all follow the straight dashed line.

Have you ever wondered what would happen if the angle of the animation was from 0 to 360? Give you a minute… That’s right! … Nothing would happen. The starting position and the ending position are the same, so as far as SwiftUI is concerned, there is no animation.

If that’s what you’re looking for, that’s great, but since we’re positioning the views around a circle, wouldn’t it make more sense if the views moved along that imaginary circle? Well, it turns out that doing that is super easy!

The answer to our problem is luckily, this layout protocol adopts the Animatable protocol! If you don’t know or have forgotten what this is, I recommend you check out the Animating Shape Paths section of SwiftUI Layout Protocols – Part 1.

In short, by adding animatableData property to our layout, we ask SwiftUI to recalculate the layout for every frame of the animation. However, in each layout pass, the angle receives an interpolated value. Now SwiftUI doesn’t interpolate the position for us. Instead, it interpolates the angle value. Our layout code will do the rest.

 struct Wheel : Layout {
 // ...
 var animatableData : CGFloat {
 get { rotation .radians }
 set { rotation = .radians ( newValue ) }
 }
 // ...
 }

Adding an animatableData property is enough to make our view follow the circle correctly. But, since we've come this far... why don't we also animate the radius?

 var animatableData : AnimatablePair < ​​CGFloat , CGFloat > {
 get { AnimatablePair ( rotation .radians , radius ) }
 set {
 rotation = Angle .radians ( newValue .first )
 radius = newValue.second​
 }
 }

Bidirectional custom values

In the first part of the article we saw how to use LayoutValues ​​to attach information to views so that their delegates can expose this information in the placeSubviews and sizeThatFits methods. The idea is that information flows from views to layouts, and we will see how this can be reversed in a moment.

The ideas explained in this section should be used with caution to avoid layout cycles and CPU spikes. In the next section I will explain why and how to avoid it. But don't worry, it's not that complicated, you just need to follow some guidelines.

Let's go back to our wheel example and suppose we want to rotate the views so that they point toward the center.

Layout protocols can only determine view positions and their suggested sizes, but cannot apply styles, rotations, or other effects. If we want these effects, then the layout should have a way to communicate back to the view. This is where layout values ​​become important. So far, we have used them to pass information to the layout, but with a little creativity, we can use them in the opposite direction.

I mentioned before that LayoutValues ​​is not limited to passing ​CGFloats​​​ , you can use it for anything, including ​Binding​​ ​, in this example we will use ​Binding<Angle>​​ ​:

 struct Rotation : LayoutValueKey {
 static let defaultValue : Binding < Angle > ? = nil
 }

Note: I call this a bidirectional custom value because information can flow both ways, however, this is not an official SwiftUI term, it’s just a term to make the idea clearer.

In the layout's placeSubview method, we set the angle of each subview:

 struct WheelLayout : Layout {
 // ...
 func placeSubviews ( in bounds : CGRect , proposal : ProposedViewSize , subviews : Subviews , cache : inout ( ) )
 {
 let angleStep = ( Angle .degrees ( 360 ) .radians / Double ( subviews .count ) )
 for ( index , subview ) in subviews .enumerated ( ) {
 let angle = angleStep * CGFloat ( index ) + rotation .radians
 // ...
 DispatchQueue .main .async {
 subview [ Rotation .self ] ? .wrappedValue = .radians ( angle )
 }
 }
 }
 }

Back in our view, we can read the value and use it to rotate the view:

 struct ContentView : View {
 // ...
 @State var rotations : [ Angle ] = Array < Angle > ( repeating : .zero , count : 16 )
 var body : some View {
 WheelLayout ( radius : radius , rotation : angle ) {
 ForEach ( 0 . . < 16 ) { idx in
 RoundedRectangle ( cornerRadius : 8 )
 .fill ( colors [ idx % colors .count ] .opacity ( 0.7 ) )
 .frame ( width : 70 , height : 70 )
 .overlay { Text ( "\( idx + 1 )" ) }
 .rotationEffect ( rotations [ idx ] )
 .layoutValue ( key : Rotation .self , value : $ rotations [ idx ] )
 }
 }
 // ...
 }

This code will make sure all the views are pointing towards the center of the circle, but we can be a little more elegant. The solution I provided requires setting up an array of rotations, passing them as layout values ​​and then using those values ​​to rotate the views. Wouldn't it be nice if we could hide this complexity from the user of the layout? Here's what it looks like after the rewrite.

First we create a wrapper view WheelComponent:

 struct WheelComponent < V : View > : View {
 @ViewBuilder let content : ( ) - > V
 @State private var rotation : Angle = .zero
 var body : some View {
 content ( )
 .rotationEffect ( rotation )
 .layoutValue ( key : Rotation .self , value : $ rotation )
 }
 }

We then get rid of the rotations array (we don't need it anymore!) and wrap each view in a WheelComponent view.

 WheelLayout ( radius : radius , rotation : angle ) {
 ForEach ( 0 . . < 16 ) { idx in
 WheelComponent {
 RoundedRectangle ( cornerRadius : 8 )
 .fill ( colors [ idx % colors .count ] .opacity ( 0.7 ) )
 .frame ( width : 70 , height : 70 )
 .overlay { Text ( "\( idx + 1 )" ) }
 }

 }
 }

That's it. Users of the container only need to remember to encapsulate their views inside the WheelComponent. They don't need to worry about layout values, bindings, angles, etc. Of course, views not in the encapsulation will not be affected in any way and will not rotate to point to the center.

One more improvement we can add is animation of the view rotation. Look closely and compare the three wheels below: One does not rotate. The other two rotate towards the center, but one does not use animation while the other does.

Avoiding layout loops and crashes

It's well known that we can't update view state during layout. This can lead to unpredictable results and will most likely spike the CPU. We've seen this before where closures run during layout and maybe it wasn't so obvious at the time. But now, it's a no-brainer. sizeThatFits and placeSubviews are part of the layout process. So when we use the "cheating" tricks described in the previous section, we have to queue our updates using a DispatchQueue. Like in the example above:

 DispatchQueue .main .async {
 subview [ Rotation .self ] ? .wrappedValue = .radians ( angle )
 }

Another potential problem with using bidirectional custom values ​​is that your view must use the value without affecting other layouts, otherwise you will get stuck in a layout loop.

For example, if you use placeSubviews to change the color of a view, it's safe. In this case, it might seem that rotation affects the layout, but that's not the case. When you rotate the view, its surroundings are never affected, the bounds remain the same. The same thing happens if you set an offset, or some other transformation matrix. But regardless, I recommend monitoring the CPU to spot other potential problems with your layout. If the CPU starts to spike, perhaps add a print statement in placeSubviews to see if it's being called endlessly. Note that animations can also increase the CPU. If you want to test whether your container is looping, don't monitor the CPU during an animation.

Note that this is not a new problem. We have encountered this problem in the past when we used GeometryReader​ to get the view size and passed that value to the superview, which then used that information to change the view, which then used GeometryReader​ to change again, and we ended up in a layout loop. This is an old problem, I wrote about this problem when SwiftUI was first released, you can read more about it in Safely Updating The View State [1].

I want to mention one more potential crash. This has nothing to do with bidirectional custom values. This is something you have to consider when writing any layout. We mentioned that SwiftUI​ may call sizeThatFits multiple times to test the flexibility of the view. In these calls, the values ​​you return should be reasonable. For example, the following code will crash:

 struct ContentView : View {
 var body : some View {
 CrashLayout {
 Text ( "Hello, World!" )
 }
 }
 }
 struct CrashLayout : Layout {
 func sizeThatFits ( proposal : ProposedViewSize , subviews : Subviews , cache : inout ( ) ) - > CGSize {
 if proposal .width == 0 {​
 return CGSize ( width : CGFloat .infinity , height : CGFloat .infinity )
 } else if proposal .width = = .infinity {
 return CGSize ( width : 0 , height : 0 )
 }

 return CGSize ( width : 0 , height : 0 )
 }

 func placeSubviews ( in bounds : CGRect , proposal : ProposedViewSize , subviews : Subviews , cache : inout ( ) )
 {
 }
 }

Here sizeThatFits returns .infinity as the minimum size and .zero as the maximum size. This doesn't make sense, the minimum size can't be larger than the maximum size!

Recursive layout

In the following example we will explore recursive layouts. We will convert the previous WheelLayout view into a RecursiveWheel. Our new layout will place 12 views in a circle. The inner 12 views will be scaled down into the inner circle until they have no other views. Scaling and rotating the views is once again achieved using bidirectional custom values.

In this example there are 44 views in the container, so our new container will be in a circle of 12, 12, 12 and 8 respectively.

Notice how in this case we use the cache to communicate with the subviews. This is possible because the cache is an inout parameter that we can update in placeSubviews.

The placeSubviews method iterates over and places 12 subviews:

 for ( index , subview ) in subviews [ 0 . . < 12 ] .enumerated ( ) {
 // ...
 }

Then recursively call placeSubviews but only for the remaining views, and so on until there are no more views.

 placeSubviews ( in : bounds ,
 proposal : proposal ,
 subviews : subviews [ 12 . . < subviews .count ] ,
 cache : & cache )

Layout combination

In the previous example we used the same layout recursion. However, we can also combine several different layouts into a container. In the next example we will place the first three views horizontally at the top of the view, and the next three horizontally at the bottom. The remaining views will be in the middle, arranged vertically.

We don’t need to code vertical or horizontal spacing logic because SwiftUI already has such layouts: HStackLayout and VStackLayout.

It's just a minor issue, and it's easy to fix. For some reason, the system layout implements sizeThatFits and placeSubviews privately. This means we can't call them. However, the type-elided layout does expose all of its methods, so instead of doing this:

 HStackLayout ( spacing : 0 ) .sizeThatFits (.. . ) // not possible

We can:

 AnyLayout ( HStackLayout ( spacing : 0 ) ) .sizeThatFits (.. . ) // it is possible!

Furthermore, we’re acting as SwiftUI’s counterpart when working with other view layouts. Any cache creation and updates for sublayouts are our responsibility, and luckily, this is easy to handle. We just need to add the sublayout cache to our own cache.

 struct ComposedLayout : Layout {
 private let hStack = AnyLayout ( HStackLayout ( spacing : 0 ) )
 private let vStack = AnyLayout ( VStackLayout ( spacing : 0 ) )

 struct Caches {
 var topCache : AnyLayout .Cache
 var centerCache : AnyLayout .Cache
 var bottomCache : AnyLayout .Cache
 }

 func makeCache ( subviews : Subviews ) - > Caches {
 Caches ( topCache : hStack .makeCache ( subviews : topViews ( subviews : subviews ) ) ,
 centerCache : vStack .makeCache ( subviews : centerViews ( subviews : subviews ) ) ,
 bottomCache : hStack .makeCache ( subviews : bottomViews ( subviews : subviews ) ) )
 }

 // ...
 }

Insert two layouts

Another combination example: inserting two layouts

The next example will create a layout that displays views in the form of a wheel or wave. Of course, it also provides a pct parameter from 0.0 to 1.0. When pct == 0.0, the view will display a wheel, and when pct == 1.0, the view will display a sin wave. The intermediate values ​​will be interspersed between the two positions.

Before we create the composite layout, let me introduce the WaveLayout. This layout has several parameters that allow you to change the amplitude, frequency and angle of the sine wave.

InterpolatedLayout will calculate the size and position of both layouts (wave and wheel) and then it will interpolate these values ​​for the final positioning. Note. In the placeSubviews method, if a subview is positioned multiple times, the last call to place()

The interpolation value is calculated using the following formula:

 ( wheelValue * pct ) + ( waveValue * ( 1 - pct ) )

We need a way for WaveLayout and WheelLayout to return each view position and rotation to InterpolatedLayout. We do this by caching. Once again, we see that caching is not the only use for performance improvements.

We also need WaveLayout and WheelLayout to detect if they are used by an InterpolatedLayout so that they can update the cache accordingly. These views can easily detect this situation thanks to a separate cache value, which is only false if the cache was created by an InterpolatedLayout.

Using bind parameters

An interesting question came up at the SwiftUI Lounges this year, asking if it was possible to use the new layout protocol to create a hierarchical tree, connected by lines. The challenge wasn’t the view tree structure, but how we draw the connecting lines.

There are other ways to do this, for example, using Canvas[2] , but since we’re all about layout protocols here, let’s see how we can solve the problem of connecting lines.

We now know that this line cannot be drawn by the layout. So what we need is a way for the layout to tell the view how to draw the line. The initial idea is to use layout values ​​(which is what Apple engineers suggest on this issue [3]). This is exactly what we did in the previous example, with two-way custom values. However, after careful consideration, there is a simpler way.

Rather than using layout values ​​to tell each node of the tree where it will end up, it’s much simpler to create the entire path using layout code. Then, we just need to return the path to the view responsible for displaying it. This is easily done by adding bindings to the layout parameters.

 struct TreeLayout {

 @Binding var linesPath : Path

 // ...
 }

After we have placed the views, we know the positions and use their coordinates to create the path. Note again that we must be very careful to avoid layout cycles. I have found that updating the path will create a cycle even if the path is drawn as a background view that does not affect the layout, so to avoid this cycle, we must ensure that the path changes before updating the binding, which will successfully break the cycle.

 let newPath = ...

 if newPath .description ! = linesPath .description {

 DispatchQueue .main .async {
 linesPath = newPath
 }

 }

Another interesting part of this challenge is telling the layout how these views are connected hierarchically. In this case, I created two UUID layout values, one to identify the view and another to serve as the ID of the parent view.

 struct ContentView : View {
 @State var path : Path = Path ( )

 var body : some View {
 let dash = StrokeStyle ( lineWidth : 2 , dash : [ 3 , 3 ] , dashPhase : 0 )

 TreeLayout ( linesPath : $ path ) {
 ForEach ( tree .flattenNodes ) { node in
 Text ( node .name )
 .padding ( 20 )
 .background {
 RoundedRectangle ( cornerRadius : 15 )
 .fill ( node ​​.color .gradient )
 .shadow ( radius : 3.0 )
 }
 .node ( node .id , parentId : node .parentId )
 }
 }
 .background {
 // Connecting lines
 path .stroke ( .gray , style : dash )
 }
 }
 }

 extension View {
 func node ( _ id : UUID , parentId : UUID ? ) - > some View {
 self
 .layoutValue ( key : NodeId .self , value : id )
 .layoutValue ( key : ParentNodeId .self , value : parentId )
 }
 }

There are a few things to keep in mind when using this code. There should be only one node whose parent is nil (the root node), and you should be careful to avoid circular references (for example, two nodes are each other's parents).

Also note that a good alternative here is to place it inside a ScrollView that has both vertical and horizontal scrolling.

Note that this is a basic implementation, just to show how it could be done. There are many potential optimizations, but the key elements needed to make a tree layout are all here.

A useful debugging tool

Back when SwiftUI was first released and I was trying to figure out how layouts worked, I wish I had a tool like the one I’m going to show you today. Until now, it’s been the best tool for adding borders around views to look at the edges of views. That’s our best ally.

Using borders is still a great debugging tool, but we can add a new one. Thanks to the new layout protocols, I created a decorator that is very useful when trying to understand why a view doesn't work the way you think it does. Here it is:

 func showSizes ( _ proposals : [ MeasureLayout .SizeRequest ] = [ .minimum , .ideal , .maximum ] ) - > some View

You can use this on any view, and an overlay will float in the view's header corner, showing a given set of suggested sizes. If you don't specify suggestions, the minimum, ideal, and maximum sizes will all be overlaid.

 MyView ( )
 .showSizes ( )

Some usage examples:

 showSizes ( ) // minimum, ideal and maximum
 showSizes ( [ .current , .ideal ] ) // the current size of the view and the ideal size
 showSizes ( [ .minimum , .maximum ] ) // the minimum and maximum
 showSizes ( [ .proposal ( size : ProposedViewSize ( width : 30 , height : .infinity ) ) ] ) // a specific proposal

More examples:

 ScrollView {
 Text ( "Hello world!" )
 }
 .showSizes ( [ .current , .maximum ] )

 Rectangle ( )
 .fill ( .yellow )
 .showSizes ( )

 Text ( "Hello world" )
 .showSizes ( )
 Image ( "clouds" )
 .showSizes ( )

 Image ( "clouds" )
 .resizable ( )
 .aspectRatio ( contentMode : .fit )
 .showSizes ( [ .minimum , .ideal , .maximum , .current ] )

Suddenly everything makes sense. For example: check out the image dimensions with and without resizable(). Isn't it strangely satisfying to finally see numbers?

Summarize

Even if you don’t plan on writing your own layout container, understanding how it works will help you understand how layouts work in SwiftUI in general.

Personally, diving into the layout protocols gave me a new appreciation for the teams that write code for containers like HStack or VStack. I often take these views for granted and think of them as simple, uncomplicated containers, and well, trying to write my own version that replicates an HStack in a variety of situations, with multiple types of views and layout priorities competing for the same space... it's a nice challenge!

References

[1] Safely Updating The View State: https://swiftui-lab.com/state-changes/​.

[2] Canvas: https://swiftui-lab.com/swiftui-animations-part5/​.

[3] Suggestions: http://swiftui-lab.com/digital-lounges-2022#layout-9​.