In this article we will look at the main aspects of structure-oriented programming: how to write code according to the SOLID principles without using protocols and without losing abstraction.

The Structure Oriented Programming is a paradigm based on the fact that any protocol can be replaced by a structure.

The advantages of this approach is performance.
Since the structure-oriented approach is based on structures that use static dispatch, the dispatch speed will be significantly different from protocols with dynamic dispatch in the protocol-oriented approach.

1. Replacing a protocol with an equivalent structure

Let’s start by trying to replace the protocol with an equivalent structure.

In a protocol-oriented approach, the protocol itself allows abstraction from the implementation.

In the structure-oriented approach, generics and closures help to provide abstraction.

Consider, as an example, the composition of a protocol and a class, in which the protocol provides the square of a number for any object that will conform to this protocol:

// Abstraction
protocol RegularProtocol {
    var sqrValue: Int { get }
}

// Object
class RegularClass {
    
    let value: Int
    
    init(value: Int) {
        self.value = value
    }
}

// Realization
extension RegularClass: RegularProtocol {
    var sqrValue: Int {
        value * value
    }
}

let onbject = RegularClass(value: 25)
print(onbject.sqrValue)

Thus, the extension to the protocol adopt RegularProtocol.

For a structure-oriented approach, the above would look like this:

// Abstraction
struct RegularStruct<AdoptedObject> {
    var sqrValue: (AdoptedObject) -> Int
    
    init(sqrValue: @escaping (AdoptedObject) -> Int) {
        self.sqrValue = sqrValue
    }
}

// Object
class RegularClass {
    
    let value: Int
    
    init(value: Int) {
        self.value = value
    }
}

// Realization
extension RegularStruct where AdoptedObject == RegularClass {
    init() {
        sqrValue = { object in object.value * object.value }
    }
}

let onbject = RegularStruct<RegularClass>()
print(onbject.sqrValue(.init(value: 25)))

2. Covering all kinds of cases

To understand how to use structure-oriented approach in practice, let’s consider the most likely cases of using the protocol:

1. Computed property
2. Property with getter and setter
3. Static property
4. Regular method
5. Static function
6. Function with associated value
7. Parent protocol function when inheriting protocols

For protocol-oriented approach all these cases are presented below:

protocol ProtocolExample: ParentProtocolExpample {
    // 1
    var getVariable: Int { get }
    
    // 2
    var getSetVariable: Int { get set }
    
    // 3
    static var staticVariable: Int { get }
    
    // 4
    func regularFunction(value: Int) -> Bool
    
    // 5
    static func staticFunction(value: Int) -> Bool
    
    // 6
    associatedtype Value
    func assosiatedFunction(value: Value) -> Bool
}

protocol ParentProtocolExample {
    // 7
    func inheritedFunction() -> String
}

An equivalent composition for a structure-oriented approach looks like this:

struct StructExample<AdoptedObject, Value> {
    // 1
    var getVariable: (_ object: AdoptedObject) -> Int
    
    // 2
    var setVariable: (_ object: AdoptedObject, Int) -> Void
    
    // 3
    var staticVariable: () -> Int
    
    // 4
    var regularFunction: (_ object: AdoptedObject, _ value: Int) -> Bool
    
    // 5
    var staticFunction: (_ value: Int) -> Bool
    
    // 6
    var assosiatedFunction: (_ object: AdoptedObject, _ value: Value) -> Bool
    
    // 7
    var parentStruct: ParentStructExample<AdoptedObject>
    var inheritedFunction: () -> String
}

struct ParentStructExample<AdoptedObject> {
    var inheritedFunction: () -> String
}

3. Performance benefits

The effect of the implementation was tested with XCTest and the Optimization Level flags — Fastest, Smallest [-Os] and showed that dispatching is 3–4 times faster for the structure-oriented approach.

Protocol-oriented approach:

Structure-oriented approach

Don’t hesitate to contact me on Twitter if you have any questions. Also, you can always buy me a coffee.

Structure Oriented Programming VS Protocol Oriented Programming in Swift was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

There are a sufficient number of ways to increase the speed of a project at runtime. Let’s look at the most popular of them:

Limiting dynamic dispatch in classes

Under the hood, any new class will use dynamic (table) dispatch. This is a price for the ability to be inherited, but if the class is not inherited, you can save a significant amount of resources. The final prefix will turn your class into a statically dispatched object.

Before optimization:

// parent class with dynamic table dispatch
class A {}
// child class with dynamic table dispatch
class B: A {}

After optimization:

// child class with static dispatch
final class B: A {}

Examples of speed boost:

• Parent class A:

• Subclass B:

• Final class B:

Limitation of dynamic dispatch at methods

A similar approach is used for class methods, but there are several options available:

• If your method is not used outside the class, feel free to use private.
• If you are going to protect your method from the possibility of override, use final.

Both prefixes will turn your method into a statically dispatched method, but with different scopes.

Before optimization:

// method with dynamic table dispatch
func method() {}

After optimization:

// private method with static dispatch
private func method() {}

// method with static dispatch cannot be override
final func method() {}

Examples of speed boost:

• Nonfinal menthod:

• Final or private method

Inline optimization

One of the most curious and rarely used types of optimization. Inline optimization allows you to copy code calculations directly to the place where a given function is called without calling a method marked with inline, which reduces the number of method calls and works faster than static dispatch.

Among the pitfalls, in order to force the compiler to call a method with inline optimization — it is necessary to mark the method not only @inlineable but also @inline(__always)

It is important not to mark methods that spend a large amount of resources on copying with these prefixes; there is a risk of filling the cache of all processor levels with calculations of these methods and, as a result, getting slower instead of speeding up.

Before optimization:

// test method with multiple calling
func testMethod() {}

After optimization:

// inlinable test method with multiple calling
@inlinable
@inline(__always)
func testMethod() {}

Examples of speed boost:

• regular calling:

• inlined calling:

Optimization in protocols

Under the hood, protocols in Swift can be implemented for reference types and value types. Due to the fact that the memory management mechanism for reference types and value types are different, you can significantly speed up the compiler by limiting protocols adoption to reference types only.

Before optimization:

// can be adopted to reference types and value types,
// but value types adoption is unnecessarily
protocol Implementable {}

After optimization:

// can be adopted to reference types only
protocol Implementable: AnyObject {}

Examples of speed boost:

• creation array elements with protocol for reference and value type

• creation array elements with protocol for reference type only

Arrays

Array was originally intended not only as a collection type for Swift, allowing elements of the same type to be stored sequentially, but also as a collection type providing compatibility with NSArray.

In case the array is intended to store non-ObjC data types, it is recommended to use ContagiousArray for more efficient operation of the array.

Before optimization:

// creation array with NSArray interop
let array: Array<Int> = [1, 2, 3]

After optimization:

// creation array without NSArray interop
let fastArray: ContiguousArray<Int> = [1, 2, 3]

Examples of speed boost:

• creation Array:

• creation ContagiousArray:

Don’t hesitate to contact me on Twitter if you have any questions. Also, you can always buy me a coffee.

Optimizing work in iOS runtime was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

In Swift using OperationQueue for asynchronous code may seem like pure hell because, under the hood, Operations are considered complete if the compilation of their synchronous code is completed.

In other words, compiling the example described below will output a broken execution order since, by the time the asynchronous code is executed, the Operation itself will have already been completed.

let operationQueue = OperationQueue()
operationQueue.maxConcurrentOperationCount = 1

operationQueue.addOperation {
    DispatchQueue.main.asyncAfter(deadline: .now() + 1) {
        print("First async operation complete")
    }
    print("First sync operation complete")
}

operationQueue.addOperation {
    DispatchQueue.main.asyncAfter(deadline: .now() + 1.5) {
        print("Second async operation complete")
    }
    print("Second sync operation complete")
}

This will be printed:

First sync operation complete
Second sync operation complete
First async operation complete
Second async operation complete

However, there is a way to circumvent these restrictions. To understand how to solve the problem, you need to understand how Operation works under the hood.

The Operation itself has four flags by which you can track the life cycle of the operation:

• isReady — indicates whether the Operation can be performed at this time.
• isExecuting —indicates whether an Operation is currently in progress.
• isFinished —indicates whether the Operation is currently completed.
• isCancelled —indicates whether the Operation was cancelled.

In theory, the Operation enters the isFinished state before the Operation itself is executed asynchronously, so we need to develop a technique by which we will be able to manipulate the life cycle of the Operation.

This possibility can be solved by subclassing the Operation and also by redefining the start / cancel methods, as well as all the flags on which the operation's life cycle is built. Here’s the code:

public class AsyncOperation: Operation {
    // MARK: Open

    override open var isAsynchronous: Bool {
        true
    }

    override open var isReady: Bool {
        super.isReady && self.state == .ready
    }

    override open var isExecuting: Bool {
        self.state == .executing
    }

    override open var isFinished: Bool {
        self.state == .finished
    }

    override open func start() {
        if isCancelled {
            state = .finished
            return
        }
        main()
        state = .executing
    }

    override open func cancel() {
        super.cancel()
        state = .finished
    }

    // MARK: Public

    public enum State: String {
        case ready
        case executing
        case finished

        // MARK: Fileprivate

        fileprivate var keyPath: String {
            "is" + rawValue.capitalized
        }
    }

    public var state = State.ready {
        willSet {
            willChangeValue(forKey: newValue.keyPath)
            willChangeValue(forKey: state.keyPath)
        }
        didSet {
            didChangeValue(forKey: oldValue.keyPath)
            didChangeValue(forKey: state.keyPath)
        }
    }
}

The subclass we received from the Operation is basic and allows us to forcefully complete it manually.

To work with completion blocks, you should create another subclass. However, this will not be a subclass of the Operation, but of AsyncOperation.

public typealias VoidClosure = () -> Void
public typealias Closure<T> = (T) -> Void

public class CompletionOperation: AsyncOperation {
    // MARK: Lifecycle

    public init(completeBlock: Closure<VoidClosure?>?) {
        self.completeBlock = completeBlock
    }

    // MARK: Public

    override public func main() {
        DispatchQueue.main.async { [weak self] in
            self?.completeBlock? {
                DispatchQueue.main.async {
                    self?.state = .finished
                }
            }
        }
    }

    // MARK: Private

    private let completeBlock: Closure<VoidClosure?>?
}

This subclass will allow us to pass a closure to the Operation, after which the Operation will be completed.

Let’s try this type of operation in practice:

let operationQueue = OperationQueue()
operationQueue.maxConcurrentOperationCount = 1

operationQueue.addOperation(
    CompletionOperation { completion in
        DispatchQueue.main.asyncAfter(deadline: .now() + 1) {
            print("First async operation complete")
            completion?()
        }
        print("First sync operation complete")
    }
)

operationQueue.addOperation(
    CompletionOperation { completion in
        DispatchQueue.main.asyncAfter(deadline: .now() + 1.5) {
            print("Second async operation complete")
            completion?()
        }
        print("Second sync operation complete")
    }
)

As a result, we were able to achieve synchronous execution of Operations:

First sync operation complete
First async operation complete
Second sync operation complete
Second async operation complete

Don’t hesitate to contact me on Twitter if you have any questions.

OperationQueue + Asynchronous Code was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

Memory management in Swift is based on automatic reference counting (ARC), which means that an object exists in memory as long as there is at least one strong reference to it. After that, ARC initiates the object deallocation mechanism, depending on the number of existing weak and unowned object references, the deallocation mechanism will be different.

However, in addition to ARC, Swift also supports manual memory management. In this article, I will tell you what are the ways to work with memory that provide create / read / update / delete (CRUD) operations and much more.

1.Pointers

Manual memory management can be implemented based on pointers. Pointer types vary depending on the need for unsafe memory access.

The data type is:

• Pointers to a piece of memory without an explicit type. Returns the number of bytes. Usually contains Raw in the name;
• Pointers with an explicit type specified during initialization as a generic parameter. Does not contain Raw in the name;

Variability is distinguished by:

• Pointers to a memory area with the possibility of changing it. The name contains Mutable;
• Pointers to a piece of memory without the possibility of changing it. The name does not contain Mutable;

The number of elements is distinguished by:

• Pointers that operate on an array of elements. The name contains Buffer;
• Pointers that operate on a single element. The name does not contain Buffer;

In total, all possible combinations of pointers look like this:

• UnsafePointer<T>;
• UnsafeMutablePointer<T>;
• UnsafeBufferPointer<T>;
• UnsafeMutableBufferPointer<T>;
• UnsafeRawPointer;
• UnsafeMutableRawPointer;
• UnsafeRawBufferPointer;
• UnsafeMutableRawBufferPointer;

2. Creating objects

Let’s consider the creation of objects on the example of UnsafePointer.

var x: Int = 10
let unsafePointer = UnsafePointer<Int>(&x)

Because UnsafePointer is an immutable pointer, it can only be initialized by passing it an already initialized object directly.

You can get information about the memory area stored at a given pointer as follows:

unsafePointer.pointee // printed 10

Consider the creation of objects on the example of UnsafeMutablePointer. Unlike UnsafePointer, this pointer can be initialized before information is written to the memory area.

let size = MemoryLayout<Int>.size

let unsafeMutablePointer = UnsafeMutablePointer<Int>.allocate(capacity: size)
unsafeMutablePointer.pointee = 5

Now, through the pointee property, you can read and write the allocated memory area. Since we are working with the Int data type, the capacity area was chosen taking into account the required size of the MemoryLayout.

You can deallocate a memory area and a pointer to it as follows:

unsafeMutablePointer.deallocate()
unsafeMutablePointer.deinitialize(count: 1)

Consider the creation of elements on the example of UnsafeMutableRawPointer. Since this pointer is mutable and without explicit typing, it is enough to allocate a memory area for an object, and then write data to it. In this case, all operations for this pointer occur byte by byte, without a specific data type.

let unsafeMutableRawPointer = UnsafeMutableRawPointer.allocate(byteCount: size, alignment: alignment) // 6000006E44F0
unsafeMutableRawPointer.storeBytes(of: 32, as: Int.self) // 6000006E44F0
unsafeMutableRawPointer.load(as: Int.self) // printed 32

The load method allows you to read a memory area with a given data type. The storeBytes method allows you to write to the allocated memory area. At the same time, because of the lack of binding to a specific data type, you can easily put and read data with a completely different type into the allocated area:

unsafeMutableRawPointer.initializeMemory(as: String.self, to: "123") // 6000006E44F0
unsafeMutableRawPointer.load(as: String.self) // printed “123”
unsafeMutableRawPointer.deallocate()

The address 6000006E44F0 was the number 32 with the data type Int, but we rewrote it to the string "123", hello Python.

3. Copying

In addition to standard CRUD operations, pointers also support copying memory from one address to another.

let size = MemoryLayout<Int>.size
let alignment = MemoryLayout<Int>.alignment

let unsafeMutableRawPointer1 = UnsafeMutableRawPointer.allocate(byteCount: size, alignment: alignment)
unsafeMutableRawPointer1.storeBytes(of: 32, as: Int.self) // 32

let unsafeMutableRawPointer2 = UnsafeMutableRawPointer.allocate(byteCount: size, alignment: alignment)
unsafeMutableRawPointer2.storeBytes(of: 40, as: Int.self) // 40

unsafeMutableRawPointer2.copyMemory(from: unsafeMutableRawPointer1, byteCount: size)
unsafeMutableRawPointer2.load(as: Int.self) // 32

Two pointers were created to different memory locations containing the numbers 32 and 40. Thanks to copyMemory, we were able to copy information from one memory location to another. At the same time, the use of the copyMemory method allows one-time copying, preserving the further independence of memory sections with different addresses.

4. Binding

It is also possible to bind two different pointers:

let unsafeMutableRawPointer3 = UnsafeMutableRawPointer.allocate(byteCount: size, alignment: alignment)
unsafeMutableRawPointer3.storeBytes(of: 32, as: Int.self)

let unsafeMutableRawPointer4 = unsafeMutableRawPointer3.bindMemory(to: Int.self, capacity: size)
unsafeMutableRawPointer4.pointee // 32

unsafeMutableRawPointer3.storeBytes(of: 40, as: Int.self)

unsafeMutableRawPointer4.pointee // 40

Thanks to bindMemory, both pointers point to the same memory location and will catch all changes, regardless of which pointer they are written to.

5. Collections

To allocate an area of memory for an array using UnsafeMutableBufferPointer , the area for each element of the array will be allocated first:

let array: [Int] = [5, 6, 7, 8, 9]
let elementPointer = UnsafeMutablePointer<Int>.allocate(capacity: array.count)
let arrayPointer = UnsafeMutableBufferPointer(start: elementPointer, count: array.count)

Let’s fill in the previously allocated area. Offset between memory locations of different elements will be provided by the advanced(by: Int) method.

for (index, value) in array.enumerated() {
    elementPointer.advanced(by: index).pointee = value
}

In addition to writing, the advanced(by: Int) method also helps when reading a specific array element by ordinal index:

elementPointer.advanced(by: 4).pointee // 9

UnsafeMutableBufferPointer supports subscript[index] to read and write array elements by ordinal index:

arrayPointer[4] = 5
elementPointer.advanced(by: 4).pointee // 5
arrayPointer.deallocate()

On this, the article comes to an end. I will talk about other types of manual memory management, such as Unmanaged objects, in the next article.

Don’t hesitate to contact me on Twitter if you have any questions. Also, you can always buy me a coffee.

I continue the series of articles devoted to the use of a protocol-oriented approach when scaling projects with a large code base.

If you have not read the previous article, then I strongly recommend that you familiarize yourself with the approaches and conclusions that were made in it. Briefly, a case was considered with the creation of a universal class that would allow creating a constructor for using scrolling lists based on UICollectionViewFlowLayout.

The motivation for this approach is very simple, we want to reduce the amount of boilerplate code by creating universal tools that will reduce the amount of routine and at the same time not lose flexibility.

In this article, we will continue to consider a similar task using UICollectionViewCompositionalLayout, which is supported from iOS 13+, and see what nuances this framework brings.

As in the previous problem, we will solve this problem in 4 stages.

1. Writing an abstraction of the data type of scrolling elements;
2. Writing a base class for scrollable elements;
3. Writing an Implementation for Lists;
4. Use cases

1. Abstract scrolling elements

The creation of abstraction — is undoubtedly the most important stage for design. To lay the foundation for a system open to scaling, it is necessary to abstract from the qualitative and quantitative characteristics of scrolling elements. It is only important to comply with the requirements for the same type of layout.

Let us introduce such a notion — as a section. A section is one or more elements with the same layout. We use the section as an abstraction over the scrollable elements:

Using a section as an abstraction over scrollable elements:

protocol BaseSection {
    var numberOfElements: Int { get }

    func registrate(collectionView: UICollectionView)
    func cell(for collectionView: UICollectionView, indexPath: IndexPath) -> UICollectionViewCell
    func header(for collectionView: UICollectionView, indexPath: IndexPath) -> UICollectionReusableView
    func footer(for collectionView: UICollectionView, indexPath: IndexPath) -> UICollectionReusableView
    func section() -> NSCollectionLayoutSection
    func select(row: Int)
}

We will transfer the responsibility for configuring the layout to the section. The presence of supplementary views, such as a header or footer, will also be determined there.

2. Scrolling list

The base class will be used as the scrollable list. The task of the base class is to take the abstract data of the BaseSection and render it. In our case, UICollectionView and UICollectionViewCompositionalFlowLayout will be used as a visualization tool:

class SectionView: UIView {
    override init(frame: CGRect) {
        super.init(frame: frame)
        
        commonInit()
    }
    
    required init?(coder: NSCoder) {
        super.init(coder: coder)
        
        commonInit()
    }
    
    private func commonInit() {
        collectionView.autoresizingMask = [.flexibleWidth, .flexibleHeight]
        collectionView.frame = bounds
        addSubview(collectionView)
    }
    
    private(set) lazy var flowLayout: UICollectionViewCompositionalLayout = {
        let layout = UICollectionViewCompositionalLayout { [weak self] index, env in
            self?.sections[index].section()
        }
        return layout
    }()
    
    private(set) lazy var collectionView: UICollectionView = {
        let collectionView = UICollectionView(frame: .zero, collectionViewLayout: flowLayout)
        collectionView.backgroundColor = .clear
        collectionView.delegate = self
        collectionView.dataSource = self
        return collectionView
    }()
    
    private var sections: [BaseSection] = []
    
    public func set(sections: [BaseSection], append: Bool) {
        sections.forEach {
            $0.registrate(collectionView: collectionView)
        }
        
        if append {
            self.sections.append(contentsOf: sections)
        } else {
            self.sections = sections
        }
        
        collectionView.reloadData()
    }
    
    public func set(contentInset: UIEdgeInsets) {
        collectionView.contentInset = contentInset
    }
}

extension SectionView: UICollectionViewDataSource {
    func numberOfSections(in collectionView: UICollectionView) -> Int {
        sections.count
    }
    
    func collectionView(_ collectionView: UICollectionView, numberOfItemsInSection section: Int) -> Int {
        sections[section].numberOfElements
    }
    
    func collectionView(_ collectionView: UICollectionView, cellForItemAt indexPath: IndexPath) -> UICollectionViewCell {
        sections[indexPath.section].cell(for: collectionView, indexPath: indexPath)
    }
    
    func collectionView(_ collectionView: UICollectionView, viewForSupplementaryElementOfKind kind: String, at indexPath: IndexPath) -> UICollectionReusableView {
        kind == UICollectionView.elementKindSectionHeader
            ? sections[indexPath.section].header(for: collectionView, indexPath: indexPath)
            : sections[indexPath.section].footer(for: collectionView, indexPath: indexPath)
    }
}

extension SectionView: UICollectionViewDelegate {
    func collectionView(_ collectionView: UICollectionView, didSelectItemAt indexPath: IndexPath) {
        sections[indexPath.section].select(row: indexPath.row)
    }
}

UICollectionViewCompositionalLayout, compared to using UICollectionViewFlowLayout, allows you to transfer cell / header / footer layout configuration from delegate methods to the layout body.

3. Implementing Scrollable Elements

Based on the fact that the section, which includes the ability to show the footer and header, was taken as an abstraction, it is also necessary to take this into account in the implementation class.

In this case, the requirements for any cell will look like this:

protocol SectionCell: UICollectionViewCell {
    associatedtype CellData: SectionCellData

    func setup(with data: CellData) -> Self
    static func groupSize() -> NSCollectionLayoutGroup
}

protocol SectionCellData {
    var onSelect: VoidClosure? { get }
}

typealias VoidClosure = () -> Void

We move the configuration of the cell size to the area of responsibility of the cell, we also take into account the possibility of receiving an action by tapping on any cell.

The header and footer requirements will look like this:

protocol SectionHeader: UICollectionReusableView {
    associatedtype HeaderData
    
    func setup(with data: HeaderData?) -> Self
    static func headerItem() -> NSCollectionLayoutBoundarySupplementaryItem?
}

protocol SectionFooter: UICollectionReusableView {
    associatedtype FooterData
    
    func setup(with data: FooterData?) -> Self
    static func footerItem() -> NSCollectionLayoutBoundarySupplementaryItem?
}

Based on the requirements for scrolling elements, we can design the implementation of the section:

class Section<Cell: SectionCell, Header: SectionHeader, Footer: SectionFooter>: BaseSection {
    init(items: [Cell.CellData], headerData: Header.HeaderData? = nil, footerData: Footer.FooterData? = nil) {
        self.items = items
        self.headerData = headerData
        self.footerData = footerData
    }
    
    private(set) var items: [Cell.CellData]
    private let headerData: Header.HeaderData?
    private let footerData: Footer.FooterData?
    
    var numberOfElements: Int {
        items.count
    }
    
    func registrate(collectionView: UICollectionView) {
        collectionView.register(Cell.self)
        collectionView.registerHeader(Header.self)
        collectionView.registerFooter(Footer.self)
    }
    
    func cell(for collectionView: UICollectionView, indexPath: IndexPath) -> UICollectionViewCell {
        collectionView
            .dequeue(Cell.self, indexPath: indexPath)?
            .setup(with: items[indexPath.row])
        ?? UICollectionViewCell()
    }
    
    func header(for collectionView: UICollectionView, indexPath: IndexPath) -> UICollectionReusableView {
        collectionView
            .dequeueHeader(Header.self, indexPath: indexPath)?
            .setup(with: headerData)
        ?? UICollectionReusableView()
    }
    
    func footer(for collectionView: UICollectionView, indexPath: IndexPath) -> UICollectionReusableView {
        collectionView
            .dequeueFooter(Footer.self, indexPath: indexPath)?
            .setup(with: footerData)
        ?? UICollectionReusableView()
    }
    
    func section() -> NSCollectionLayoutSection {
        let section = NSCollectionLayoutSection(group: Cell.groupSize())
        
        if let headerItem = Header.headerItem() {
            section.boundarySupplementaryItems.append(headerItem)
        }
        
        if let footerItem = Footer.footerItem() {
            section.boundarySupplementaryItems.append(footerItem)
        }

        return section
    }

    func select(row: Int) {
        items[row].onSelect?()
    }
}

Generics that implement the requirements for them act as cell / header / footer types.

In general, the implementation is complete, but I would like to add a few helpers that further reduce the amount of boilerplate code. In particular, in practice it will not always be useful to have such a generic section, for the simple reason that the footer or header is not always used. Therefore, let’s add a section heir that takes into account similar cases:

class SectionWithoutHeaderFooter<Cell: SectionCell>: Section<Cell, EmptySectionHeader, EmptySectionFooter> {}

class EmptySectionHeader: UICollectionReusableView, SectionHeader {
    func setup(with data: String?) -> Self {
        self
    }
    
    static func headerItem() -> NSCollectionLayoutBoundarySupplementaryItem? {
        nil
    }
}

class EmptySectionHeader: UICollectionReusableView, SectionHeader {
    func setup(with data: String?) -> Self {
        self
    }
    
    static func headerItem() -> NSCollectionLayoutBoundarySupplementaryItem? {
        nil
    }
}

On this, the design can be considered complete, I propose to move on to the use cases themselves.

4. Use cases

Let’s create a section of cells with a fixed size and display it on the screen:

class ColorCollectionCell: UICollectionViewCell, SectionCell {

    func setup(with data: ColorCollectionCellData) -> Self {
        contentView.backgroundColor = data.color
        
        return self
    }

    static func groupSize() -> NSCollectionLayoutGroup {
        let itemSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1), heightDimension: .fractionalWidth(0.5))
        let item = NSCollectionLayoutItem(layoutSize: itemSize)
        let group = NSCollectionLayoutGroup.horizontal(layoutSize: itemSize, subitem: item, count: 2)
        group.interItemSpacing = .fixed(16)
        return group
    }
}

class ColorCollectionCellData: SectionCellData {
    let onSelect: VoidClosure?
    let color: UIColor
    
    init(color: UIColor, onSelect: VoidClosure? = nil) {
        self.onSelect = onSelect
        self.color = color
    }
}

Let’s create an implementation of the header and footer:

class DefaultSectionHeader: UICollectionReusableView, SectionHeader {
    let textLabel: UILabel = {
        let label = UILabel()
        label.font = .systemFont(ofSize: 32, weight: .bold)
        return label
    }()
    
    override init(frame: CGRect) {
        super.init(frame: frame)
        
        commonInit()
    }

    required init?(coder: NSCoder) {
        super.init(coder: coder)
        
        commonInit()
    }
    
    private func commonInit() {
        addSubview(textLabel)
        textLabel.numberOfLines = .zero
        textLabel.translatesAutoresizingMaskIntoConstraints = false
        
        NSLayoutConstraint.activate([
            textLabel.topAnchor.constraint(equalTo: topAnchor),
            textLabel.bottomAnchor.constraint(equalTo: bottomAnchor),
            textLabel.leftAnchor.constraint(equalTo: leftAnchor),
            textLabel.rightAnchor.constraint(equalTo: rightAnchor)
        ])
    }
    
    func setup(with data: String?) -> Self {
        textLabel.text = data
        
        return self
    }

    static func headerItem() -> NSCollectionLayoutBoundarySupplementaryItem? {
        let headerSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1.0), heightDimension: .estimated(20))
        let header = NSCollectionLayoutBoundarySupplementaryItem(
            layoutSize: headerSize,
            elementKind: UICollectionView.elementKindSectionHeader,
            alignment: .top,
            absoluteOffset: .zero
        )
        header.pinToVisibleBounds = true
        return header
    }
}

class DefaultSectionFooter: UICollectionReusableView, SectionFooter {
    let textLabel: UILabel = {
        let label = UILabel()
        label.font = .systemFont(ofSize: 12, weight: .light)
        return label
    }()
    
    override init(frame: CGRect) {
        super.init(frame: frame)
        
        commonInit()
    }

    required init?(coder: NSCoder) {
        super.init(coder: coder)
        
        commonInit()
    }
    
    private func commonInit() {
        addSubview(textLabel)
        textLabel.numberOfLines = .zero
        textLabel.translatesAutoresizingMaskIntoConstraints = false
        
        NSLayoutConstraint.activate([
            textLabel.topAnchor.constraint(equalTo: topAnchor),
            textLabel.bottomAnchor.constraint(equalTo: bottomAnchor),
            textLabel.leftAnchor.constraint(equalTo: leftAnchor),
            textLabel.rightAnchor.constraint(equalTo: rightAnchor)
        ])
    }
    
    func setup(with data: String?) -> Self {
        textLabel.text = data
        
        return self
    }

    static func footerItem() -> NSCollectionLayoutBoundarySupplementaryItem? {
        let footerSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1.0), heightDimension: .estimated(20))
        let footer = NSCollectionLayoutBoundarySupplementaryItem(
            layoutSize: footerSize,
            elementKind: UICollectionView.elementKindSectionFooter,
            alignment: .bottom,
            absoluteOffset: .zero
        )

        return footer
    }
}

Let’s add a new section to the scrolling list:

class ViewController: UIViewController {
    
    let sectionView = SectionView()
    
    override func loadView() {
        view = sectionView
    }

    override func viewDidLoad() {
        super.viewDidLoad()
        sectionView.backgroundColor = .white

        sectionView.set(
            sections: [
                Section<ColorCollectionCell, DefaultSectionHeader, DefaultSectionFooter>(
                    items: [
                        .init(color: .blue) {
                            print(#function)
                        },
                        .init(color: .red) {
                            print(#function)
                        },
                        .init(color: .yellow) {
                            print(#function)
                        },
                        .init(color: .green) {
                            print(#function)
                        },
                        .init(color: .blue) {
                            print(#function)
                        }
                    ],
                    headerData: "COLOR SECTION",
                    footerData: "footer text for color section"
                )
            ],
            append: false
        )
    }
}

In total, in just a few lines of code, we implemented a section of 5 multi-colored cells with a size proportional to the screen, a header and a footer.

Let’s try to use a similar approach for dynamically sized cells.

class DynamicCollectionCell: UICollectionViewCell, SectionCell {
    let textLabel = UILabel()
    
    override init(frame: CGRect) {
        super.init(frame: frame)
        
        commonInit()
    }

    required init?(coder: NSCoder) {
        super.init(coder: coder)
        
        commonInit()
    }
    
    private func commonInit() {
        contentView.addSubview(textLabel)
        textLabel.numberOfLines = .zero
        textLabel.translatesAutoresizingMaskIntoConstraints = false
        
        NSLayoutConstraint.activate([
            textLabel.topAnchor.constraint(equalTo: contentView.topAnchor),
            textLabel.bottomAnchor.constraint(equalTo: contentView.bottomAnchor),
            textLabel.leftAnchor.constraint(equalTo: contentView.leftAnchor),
            textLabel.rightAnchor.constraint(equalTo: contentView.rightAnchor)
        ])
    }

    func setup(with data: DynamicCollectionCellData) -> Self {
        textLabel.text = data.text
        
        return self
    }
    
    static func groupSize() -> NSCollectionLayoutGroup {
        let itemSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1), heightDimension: .estimated(20))
        let item = NSCollectionLayoutItem(layoutSize: itemSize)
        let group = NSCollectionLayoutGroup.vertical(layoutSize: itemSize, subitems: [item])
        return group
    }
}

class DynamicCollectionCellData: SectionCellData {
    let text: String
    var onSelect: VoidClosure?
    
    init(text: String) {
        self.text = text
    }
}


class ViewController: UIViewController {
    
    ...

    override func viewDidLoad() {
        super.viewDidLoad()

        ...
        sectionView.set(
            sections: [
                SectionWithoutHeaderFooter<DynamicCollectionCell>(
                    items: [
                        .init(text: "Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s"),
                        .init(text: "when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged."),
                        .init(text: "It was popularised"),
                        .init(text: "the 1960s with the release of Letraset sheets containing"),
                        .init(text: "Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum.")
                    ]
                ),
                ...
            ],
            append: false
        )
    }
}

As a result, we got rid of writing boilerplate code when creating scrolling lists based on UICollectionViewCompositionalLayout.

The source code can be viewed here.

Don’t hesitate to contact me on Twitter if you have any questions. Also, you can always buy me a coffee.

Each developer in practice faced the need to make up a screen based on a scrolling list of elements. Or maybe not just one list, but several.

It can be horizontal lists, vertical lists, lists with a complex layout. These can be lists with a predetermined size, or with a dynamic size. And the developer always has a choice — to use UITableView or UICollectionView. (We will not consider UIScrollView, since its use is limited to a finite list of a predetermined number).

Each of the above options has strengths and weaknesses:

• UITableView, one of the advantages of which is the dynamic calculation of the content height out of the box, is used in vertical lists.
• UICollectionView — always had more use cases chronologically, as they always covered more scroll direction. However, their biggest drawback prior to iOS 13 is the static size, which had to be calculated manually.

And as every developer knows, after choosing one or the other, the next step is to write a tangible amount of accompanying code in order to make this list work.

• You have to register cells, headers, footers or a runtime crash is inevitable;
• You have to monotonously create cells, configure their number in a section, declare the number of sections;
• You have to fill in the cells with preset data;
• Handle table or collection delegate methods, handle clicks inside a cell;
• It is necessary to duplicate the code and wrap in cells, previously designed for a table, in cells for a collection if both classes are used in the project.

Each of us spent a huge amount of time on all these things, and this is not normal. This problem is called the problem of writing boilerplate code, and it must be solved by writing universal tools that will reduce the amount of routine and at the same time not lose flexibility.

In this article, we will solve the problem of writing boilerplate code based on UICollectionView using a protocol-oriented approach for UICollectionViewFlowLayout. This approach is suitable for any project for all currently supported versions of iOS.

In the next article, I will show how to use this approach for UICollectionViewCompositionalFlowLayout, which is supported from iOS 13+.

We are faced with the issue of reducing the amount of boilerplate code and we will solve it in 4 stages.

1. Writing an abstraction of the data type of scrolling elements;
2. Writing a base class for scrollable elements;
3. Writing an Implementation for Lists;
4. Use cases

1. Abstract scrolling elements

Designing abstractions is one of the key points in creating a system that is well resistant to changes. It is important to understand that the requirements for abstraction must cover absolutely all possible cases of using objects, otherwise, when scaling the system, additional entities will have to be introduced, the value of the root abstraction will decrease, and the introduction of new features will become more complicated.

In the case of designing a scrolling list based on UICollectionView, we want to have a unit that would describe the behavior of the elements in the list, without being tied to their qualitative and quantitative characteristics.

In other words, it doesn’t matter how many objects we have, it doesn’t matter what exactly these objects contain — they should be able to get into the scrolling list if they meet the stated requirements.

Let us introduce such a notion — as a section.
A section is one or more elements with the same layout.
We use the section as an abstraction over the scrollable elements:

protocol BaseSection {
    var numberOfElements: Int { get }

    func registrate(collectionView: UICollectionView)
    func cell(for collectionView: UICollectionView, indexPath: IndexPath) -> UICollectionViewCell
    func cellSize(
        for collectionView: UICollectionView,
        layout: UICollectionViewFlowLayout,
        indexPath: IndexPath
    ) -> CGSize
    func header(for collectionView: UICollectionView, indexPath: IndexPath) -> UICollectionReusableView
    func headerSize(for collectionView: UICollectionView) -> CGSize
    func footer(for collectionView: UICollectionView, indexPath: IndexPath) -> UICollectionReusableView
    func footerSize(for collectionView: UICollectionView) -> CGSize
    func select(row: Int)
}

Since each section can have a header and footer, we will also provide their configuration in abstraction. In addition, the abstraction is supplemented by methods for calculating the size of cells / header / footer.

2. Scrolling list

The base class will be used as the scrollable list. The task of the base class is to take the abstract data of the BaseSection and render it. In our case, UICollectionView and UICollectionViewFlowLayout will be used as a visualization tool:

class SectionView: UIView {
    override init(frame: CGRect) {
        super.init(frame: frame)
        
        commonInit()
    }
    
    required init?(coder: NSCoder) {
        super.init(coder: coder)
        
        commonInit()
    }
    
    private func commonInit() {
        collectionView.autoresizingMask = [.flexibleWidth, .flexibleHeight]
        collectionView.frame = bounds
        addSubview(collectionView)
    }
    
    private(set) var flowLayout: UICollectionViewFlowLayout = {
        let layout = UICollectionViewFlowLayout()
        layout.minimumLineSpacing = .zero
        layout.minimumInteritemSpacing = .zero
        layout.scrollDirection = .vertical
        return layout
    }()
    
    private(set) lazy var collectionView: UICollectionView = {
        let collectionView = UICollectionView(frame: .zero, collectionViewLayout: flowLayout)
        collectionView.backgroundColor = .clear
        collectionView.delegate = self
        collectionView.dataSource = self
        return collectionView
    }()
    
    private var sections: [BaseSection] = []
    
    public func set(sections: [BaseSection], append: Bool) {
        sections.forEach {
            $0.registrate(collectionView: collectionView)
        }
        
        if append {
            self.sections.append(contentsOf: sections)
        } else {
            self.sections = sections
        }
        
        collectionView.reloadData()
    }
    
    public func set(itemSpacing: CGFloat) {
        flowLayout.minimumInteritemSpacing = itemSpacing
    }
    
    public func set(lineSpacing: CGFloat) {
        flowLayout.minimumLineSpacing = lineSpacing
    }
    
    public func set(contentInset: UIEdgeInsets) {
        collectionView.contentInset = contentInset
    }
}

extension SectionView: UICollectionViewDataSource {
    func numberOfSections(in collectionView: UICollectionView) -> Int {
        sections.count
    }
    
    func collectionView(_ collectionView: UICollectionView, numberOfItemsInSection section: Int) -> Int {
        sections[section].numberOfElements
    }
    
    func collectionView(_ collectionView: UICollectionView, cellForItemAt indexPath: IndexPath) -> UICollectionViewCell {
        sections[indexPath.section].cell(for: collectionView, indexPath: indexPath)
    }
    
    func collectionView(_ collectionView: UICollectionView, viewForSupplementaryElementOfKind kind: String, at indexPath: IndexPath) -> UICollectionReusableView {
        kind == UICollectionView.elementKindSectionHeader
            ? sections[indexPath.section].header(for: collectionView, indexPath: indexPath)
            : sections[indexPath.section].footer(for: collectionView, indexPath: indexPath)
    }
}

extension SectionView: UICollectionViewDelegate, UICollectionViewDelegateFlowLayout {
    func collectionView(_ collectionView: UICollectionView, didSelectItemAt indexPath: IndexPath) {
        sections[indexPath.section].select(row: indexPath.row)
    }
    
    func collectionView(_ collectionView: UICollectionView, layout collectionViewLayout: UICollectionViewLayout, sizeForItemAt indexPath: IndexPath) -> CGSize {
        sections[indexPath.section].cellSize(
            for: collectionView,
            layout: flowLayout,
            indexPath: indexPath
        )
    }
    
    func collectionView(_ collectionView: UICollectionView, layout collectionViewLayout: UICollectionViewLayout, referenceSizeForHeaderInSection section: Int) -> CGSize {
        sections[section].headerSize(for: collectionView)
    }
    
    func collectionView(_ collectionView: UICollectionView, layout collectionViewLayout: UICollectionViewLayout, referenceSizeForFooterInSection section: Int) -> CGSize {
        sections[section].footerSize(for: collectionView)
    }
}

In addition to the usual rendering of objects, the base class solves the problem of writing boilerplate code. Instead of writing UICollectionView delegate method handling for each of the screens where the list will be used, we have only one single base class in which the delegate method processing will be performed once.

3. Implementing Scrollable Elements

Based on the fact that the section was taken as an abstraction, including the ability to show the footer and header, it is also necessary to take this into account in the implementation class.

In this case, the requirements for any cell will look like this:

protocol SectionCell: UICollectionViewCell {
    associatedtype CellData: SectionCellData

    func setup(with data: CellData) -> Self
    static func size(for data: CellData, width: CGFloat) -> CGSize
}

protocol SectionCellData {
    var onSelect: VoidClosure? { get }
}

typealias VoidClosure = () -> Void

We move the configuration of the cell size to the area of responsibility of the cell, we also take into account the possibility of receiving an action by tapping on any cell.

The header and footer requirements will look like this:

protocol SectionHeader: UICollectionReusableView {
    associatedtype HeaderData
    
    func setup(with data: HeaderData?) -> Self
    static func size(for data: HeaderData?, width: CGFloat) -> CGSize
}

protocol SectionFooter: UICollectionReusableView {
    associatedtype FooterData
    
    func setup(with data: FooterData?) -> Self
    static func size(for data: FooterData?, width: CGFloat) -> CGSize
}

Based on the requirements for scrolling elements, we can design the implementation of the section:

class Section<Cell: SectionCell, Header: SectionHeader, Footer: SectionFooter>: BaseSection {
    
    init(items: [Cell.CellData], headerData: Header.HeaderData? = nil, footerData: Footer.FooterData? = nil) {
        self.items = items
        self.headerData = headerData
        self.footerData = footerData
    }
    
    private(set) var items: [Cell.CellData]
    private let headerData: Header.HeaderData?
    private let footerData: Footer.FooterData?
    
    var numberOfElements: Int {
        items.count
    }
    
    func registrate(collectionView: UICollectionView) {
        collectionView.register(Cell.self)
        collectionView.registerHeader(Header.self)
        collectionView.registerFooter(Footer.self)
    }
    
    func cell(for collectionView: UICollectionView, indexPath: IndexPath) -> UICollectionViewCell {
        collectionView
            .dequeue(Cell.self, indexPath: indexPath)?
            .setup(with: items[indexPath.row])
        ?? UICollectionViewCell()
    }
    
    func header(for collectionView: UICollectionView, indexPath: IndexPath) -> UICollectionReusableView {
        collectionView
            .dequeueHeader(Header.self, indexPath: indexPath)?
            .setup(with: headerData)
        ?? UICollectionReusableView()
    }
    
    func footer(for collectionView: UICollectionView, indexPath: IndexPath) -> UICollectionReusableView {
        collectionView
            .dequeueFooter(Footer.self, indexPath: indexPath)?
            .setup(with: footerData)
        ?? UICollectionReusableView()
    }
    
    func cellSize(for collectionView: UICollectionView, layout: UICollectionViewFlowLayout, indexPath: IndexPath) -> CGSize {
        Cell.size(
            for: items[indexPath.row],
            width: collectionView.frame.width - collectionView.contentInset.left - collectionView.contentInset.right - layout.minimumInteritemSpacing
        )
    }
    
    func headerSize(for collectionView: UICollectionView) -> CGSize {
        Header.size(
            for: headerData,
            width: collectionView.frame.width - collectionView.contentInset.left - collectionView.contentInset.right
        )
    }
    
    func footerSize(for collectionView: UICollectionView) -> CGSize {
        Footer.size(
            for: footerData,
            width: collectionView.frame.width - collectionView.contentInset.left - collectionView.contentInset.right
        )
    }
    
    func select(row: Int) {
        items[row].onSelect?()
    }
}

Generics that implement the requirements for them act as cell / header / footer types.

In general, the implementation is complete, but I would like to add a few helpers that further reduce the amount of boilerplate code. In particular, in practice it will not always be useful to have such a generic section, for the simple reason that the footer or header is not always used. Therefore, let’s add a section heir that takes into account similar cases:

class SectionWithoutHeaderFooter<Cell: SectionCell>: Section<Cell, EmptySectionHeader, EmptySectionFooter> {}

class EmptySectionHeader: UICollectionReusableView, SectionHeader {
    func setup(with data: String?) -> Self {
        self
    }

    static func size(for data: String?, width: CGFloat) -> CGSize {
        .zero
    }
}

class EmptySectionFooter: UICollectionReusableView, SectionFooter {
    func setup(with data: String?) -> Self {
        self
    }

    static func size(for data: String?, width: CGFloat) -> CGSize {
        .zero
    }
}

On this, the design can be considered complete, I propose to move on to the use cases themselves.

4. Use cases

Let’s create a section of cells with a fixed size and display it on the screen:

class ColorCollectionCell: UICollectionViewCell, SectionCell {
    func setup(with data: ColorCollectionCellData) -> Self {
        contentView.backgroundColor = data.color
        
        return self
    }

    static func size(for data: ColorCollectionCellData, width: CGFloat) -> CGSize {
        .init(width: width / 2, height: width / 2)
    }
}

class ColorCollectionCellData: SectionCellData {
    let onSelect: VoidClosure?
    let color: UIColor
    
    init(color: UIColor, onSelect: VoidClosure? = nil) {
        self.onSelect = onSelect
        self.color = color
    }
}

class ViewController: UIViewController {
    
    let sectionView = SectionView()
    
    override func loadView() {
        view = sectionView
    }

    override func viewDidLoad() {
        super.viewDidLoad()
        sectionView.backgroundColor = .white

        sectionView.set(
            sections: [
                SectionWithoutHeaderFooter<ColorCollectionCell>(
                    items: [
                        .init(color: .blue) {
                            print(#function)
                        },
                        .init(color: .red) {
                            print(#function)
                        },
                        .init(color: .yellow) {
                            print(#function)
                        },
                        .init(color: .green) {
                            print(#function)
                        },
                        .init(color: .blue) {
                            print(#function)
                        }
                    ]
                )
            ],
            append: false
        )
    }
}

In total, in just a few lines of code, we implemented 5 multi-colored cells with a fixed size.

Let’s try to use a similar approach for dynamically sized cells. For this flight, we will write the successor of SectionCell:

protocol DynamicSectionCell: SectionCell {
    
}

extension DynamicSectionCell {
    static func size(for data: CellData, width: CGFloat) -> CGSize {
        let cell = Self().setup(with: data)
        let size = cell.contentView.systemLayoutSizeFitting(
            .init(width: width, height: .greatestFiniteMagnitude),
            withHorizontalFittingPriority: .required,
            verticalFittingPriority: .fittingSizeLevel
        )
        
        return .init(width: width, height: size.height)
    }
}

The method used here is the Prototype design pattern. To calculate the cell size, we create a cell, fill it with data, and calculate its size based on the data.

Using this approach, the implementation of the cell will look like this:

class DynamicCollectionCell: UICollectionViewCell, DynamicSectionCell {
    let textLabel = UILabel()
    
    override init(frame: CGRect) {
        super.init(frame: frame)
        
        commonInit()
    }

    required init?(coder: NSCoder) {
        super.init(coder: coder)
        
        commonInit()
    }
    
    private func commonInit() {
        contentView.addSubview(textLabel)
        textLabel.numberOfLines = .zero
        textLabel.translatesAutoresizingMaskIntoConstraints = false
        
        NSLayoutConstraint.activate([
            textLabel.topAnchor.constraint(equalTo: contentView.topAnchor),
            textLabel.bottomAnchor.constraint(equalTo: contentView.bottomAnchor),
            textLabel.leftAnchor.constraint(equalTo: contentView.leftAnchor),
            textLabel.rightAnchor.constraint(equalTo: contentView.rightAnchor)
        ])
    }

    func setup(with data: DynamicCollectionCellData) -> Self {
        textLabel.text = data.text
        
        return self
    }
}

class DynamicCollectionCellData: SectionCellData {
    let text: String
    var onSelect: VoidClosure?
    
    init(text: String) {
        self.text = text
    }
}

class ViewController: UIViewController {
    
    let sectionView = SectionView()
    
    override func loadView() {
        view = sectionView
    }

    override func viewDidLoad() {
        super.viewDidLoad()
        sectionView.backgroundColor = .white
        sectionView.set(itemSpacing: 16)
        sectionView.set(lineSpacing: 16)
        sectionView.set(
            sections: [
                SectionWithoutHeaderFooter<DynamicCollectionCell>(
                    items: [
                        .init(text: "Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s"),
                        .init(text: "when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged."),
                        .init(text: "It was popularised"),
                        .init(text: "the 1960s with the release of Letraset sheets containing"),
                        .init(text: "Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum.")
                    ]
                ),
                SectionWithoutHeaderFooter<ColorCollectionCell>(
                    items: [
                        .init(color: .blue) {
                            print(#function)
                        },
                        .init(color: .red) {
                            print(#function)
                        },
                        .init(color: .yellow) {
                            print(#function)
                        },
                        .init(color: .green) {
                            print(#function)
                        },
                        .init(color: .blue) {
                            print(#function)
                        }
                    ]
                )
            ],
            append: false
        )
    }
}

Despite the need to calculate the size of the UICollectionView elements, we were able to get rid of the template code and taught how to calculate the size dynamically.

The source code can be viewed here, and in the next article I will show how to use a similar approach to work with UICollectionViewCompositionalFlowLayout.

Don’t hesitate to contact me on Twitter if you have any questions. Also, you can always buy me a coffee.

Multipeer Connectivity is an alternative to the common data exchange format. Instead of exchanging data via Wi-Fi or Cellular Network through an intermediate broker, which is usually a backend server, Multipeer Connectivity provides the ability to exchange information between multiply nearby devices without intermediaries.

The technology itself for the iPhone and iPad is based on Wi-Fi and Bluetooth, while for the MacBook and Apple TV, a similar technology was organized via Wi-Fi and Ethernet.

From here, the pros and cons of this technology immediately follow. The advantages include decentralization and, accordingly, the ability to exchange information without intermediaries.

Disadvantages — sharing is limited to Wi-Fi and Bluetooth coverage for iPhone and iPad, or Wi-Fi and Ethernet for MacBook and Apple TV. In other words, the exchange of information can be carried out in the immediate vicinity of the devices.

Integration of Multipeer Connectivity is not complicated and consists of the following steps:

1. Project preset
2. Setup visibility for other devices
3. Scan for visible devices in range
4. Creating a pair of devices for data exchange
5. Data exchange

Let’s take a closer look at each of the above steps.

1. Project preset

At this stage, the project must be prepared for the implementation of Multipeer Connectivity. To do this, you need to obtain additional permissions from the user to be able to scan:

• to do this, add Privacy — Local Network Usage Description to the Info.plist file with a description of the purpose of use;
• In addition, for the possibility of information exchange, Info.plist also needs to be supplemented with the following lines:

<key>NSBonjourServices</key>
 <array>
  <string>_nearby-devices._tcp</string>
  <string>_nearby-devices._upd</string>
 </array>

It is important to note that the nearby-devices substring is used as an example in this context. In your project, this key must meet the following requirements:

1–15 characters long and valid characters include ASCII lowercase letters, numbers, and the hyphen, containing at least one letter and no adjacent hyphens.

You can read more about the requirements here.

As for communication protocols, the example uses tcp and upd (more reliable and less reliable one). If you do not know which protocol you need, you should enter both.

2. Setup visibility for other devices

Organization of device visibility for multi-peer connection is implemented by MCNearbyServiceAdvertiser. Let’s create a class that will be responsible for detecting, displaying and sharing information between devices.

import MultipeerConnectivity
import SwiftUI

class DeviceFinderViewModel: ObservableObject {
    private let advertiser: MCNearbyServiceAdvertiser
    private let session: MCSession
    private let serviceType = "nearby-devices"

    @Published var isAdvertised: Bool = false {
        didSet {
            isAdvertised ? advertiser.startAdvertisingPeer() : advertiser.stopAdvertisingPeer()
        }
    }
    
    init() {
        let peer = MCPeerID(displayName: UIDevice.current.name)
        session = MCSession(peer: peer)
        
        advertiser = MCNearbyServiceAdvertiser(
            peer: peer,
            discoveryInfo: nil,
            serviceType: serviceType
        )
    }
}

The core of the multipeer is a MCSession, which will allow you to connect and exchange data between devices.

The serviceType is the key mentioned above, which was added to the Info.plist file along with the exchange protocols.

The isAdvertised property will allow you to switch the visibility of the device using Toggle.

3. Scan for visible devices in range

Device visibility scanning for a multi-peer connection is performed by MCNearbyServiceBrowser:

class DeviceFinderViewModel: NSObject, ObservableObject {
    ...
    private let browser: MCNearbyServiceBrowser
    ...

    @Published var peers: [PeerDevice] = []
    ...
    
    override init() {
        ...
        
        browser = MCNearbyServiceBrowser(peer: peer, serviceType: serviceType)
        
        super.init()
        
        browser.delegate = self
    }

    func startBrowsing() {
        browser.startBrowsingForPeers()
    }
    
    func finishBrowsing() {
        browser.stopBrowsingForPeers()
    }
}

extension DeviceFinderViewModel: MCNearbyServiceBrowserDelegate {
    func browser(_ browser: MCNearbyServiceBrowser, foundPeer peerID: MCPeerID, withDiscoveryInfo info: [String : String]?) {
        peers.append(PeerDevice(peerId: peerID))
    }

    func browser(_ browser: MCNearbyServiceBrowser, lostPeer peerID: MCPeerID) {
        peers.removeAll(where: { $0.peerId == peerID })
    }
}  

struct PeerDevice: Identifiable, Hashable {
    let id = UUID()
    let peerId: MCPeerID
}

A list of all visible devices will be stored in peers. TheMCNearbyServiceBrowser delegate methods will add or remove an MCPeerID when a peer is found or lost.
The startBrowsing and finishBrowsing methods will be used to start discovering visible devices when the screen appears, or stop searching after the screen disappears.

The following View will be used as the UI:

struct ContentView: View {
    @StateObject var model = DeviceFinderViewModel()

    var body: some View {
        NavigationStack {
            List(model.peers) { peer in
                HStack {
                    Image(systemName: "iphone.gen1")
                        .imageScale(.large)
                        .foregroundColor(.accentColor)

                    Text(peer.peerId.displayName)
                        .frame(maxWidth: .infinity, alignment: .leading)
                }
                .padding(.vertical, 5)
            }
            .onAppear {
                model.startBrowsing()
            }
            .onDisappear {
                model.finishBrowsing()
            }
            .toolbar {
                ToolbarItem(placement: .navigationBarTrailing) {
                    Toggle("Press to be discoverable", isOn: $model.isAdvertised)
                        .toggleStyle(.switch)
                }
            }
        }
    }
}

Device visibility will be enabled/disabled by the Toggle.
As a result, at this stage, the detection and display of devices should work correctly.

4. Creating a pair of devices for data exchange

The delegate method MCNearbyServiceAdvertiser didReceiveInvitationFromPeer is responsible for sending an invitation between a pair of devices. Both of them must be capable of handling this request.

class DeviceFinderViewModel: NSObject, ObservableObject {
    ...

    @Published var permissionRequest: PermitionRequest?
    
    @Published var selectedPeer: PeerDevice? {
        didSet {
            connect()
        }
    }

    ...
   
    @Published var joinedPeer: [PeerDevice] = []
    
    override init() {
        ...
               
        advertiser.delegate = self
    }

    func startBrowsing() {
        browser.startBrowsingForPeers()
    }
    
    func finishBrowsing() {
        browser.stopBrowsingForPeers()
    }
    
    func show(peerId: MCPeerID) {
        guard let first = peers.first(where: { $0.peerId == peerId }) else {
            return
        }
        
        joinedPeer.append(first)
    }
    
    private func connect() {
        guard let selectedPeer else {
            return
        }
        
        if session.connectedPeers.contains(selectedPeer.peerId) {
            joinedPeer.append(selectedPeer)
        } else {
            browser.invitePeer(selectedPeer.peerId, to: session, withContext: nil, timeout: 60)
        }
    }
}

extension DeviceFinderViewModel: MCNearbyServiceAdvertiserDelegate {
    func advertiser(
        _ advertiser: MCNearbyServiceAdvertiser,
        didReceiveInvitationFromPeer peerID: MCPeerID,
        withContext context: Data?,
        invitationHandler: @escaping (Bool, MCSession?) -> Void
    ) {
        permissionRequest = PermitionRequest(
            peerId: peerID,
            onRequest: { [weak self] permission in
                invitationHandler(permission, permission ? self?.session : nil)
            }
        )
    }
}

struct PermitionRequest: Identifiable {
    let id = UUID()
    let peerId: MCPeerID
    let onRequest: (Bool) -> Void
}

When the selectedPeer is set, the connect method fires. If this peer is in the list of existing peers, it will be added to the joinedPeer array. In the future, this property will be processed by the UI.

In the absence of this peer in the session, the browser will invite this device to create a pair.

After that, the didReceiveInvitationFromPeer method will be processed for the invited device. In our case, after the start of didReceiveInvitationFromPeer, a permissionRequest is created with a delayed callback, which will be shown as an alert on the invited device:

struct ContentView: View {
    @StateObject var model = DeviceFinderViewModel()

    var body: some View {
        NavigationStack {
            ...
            .alert(item: $model.permissionRequest, content: { request in
                Alert(
                    title: Text("Do you want to join \(request.peerId.displayName)"),
                    primaryButton: .default(Text("Yes"), action: {
                        request.onRequest(true)
                        model.show(peerId: request.peerId)
                    }),
                    secondaryButton: .cancel(Text("No"), action: {
                        request.onRequest(false)
                    })
                )
            })
            ...
        }
    }
}

In the case of an approve, didReceiveInvitationFromPeer will return the device sending the invitation, permission and session if permission was succeed.
As a result, after successfully accepting the invitation, a pair will be created:

5. Data exchange

After creating a pair, MCSession is responsible for the exchange of data:

import MultipeerConnectivity
import Combine

class DeviceFinderViewModel: NSObject, ObservableObject {
 ...

    @Published var messages: [String] = []
    let messagePublisher = PassthroughSubject<String, Never>()
    var subscriptions = Set<AnyCancellable>()

    func send(string: String) {
        guard let data = string.data(using: .utf8) else {
            return
        }
        
        try? session.send(data, toPeers: [joinedPeer.last!.peerId], with: .reliable)

        messagePublisher.send(string)
    }
    
    override init() {

        
        ...
        
        session.delegate = self
        
        messagePublisher
            .receive(on: DispatchQueue.main)
            .sink { [weak self] in
                self?.messages.append($0)
            }
            .store(in: &subscriptions)
    }    
}


extension DeviceFinderViewModel: MCSessionDelegate {
    func session(_ session: MCSession, didReceive data: Data, fromPeer peerID: MCPeerID) {
        guard let last = joinedPeer.last, last.peerId == peerID, let message = String(data: data, encoding: .utf8) else {
            return
        }

        messagePublisher.send(message)
    }
}

Method func send(_ data: Data, toPeers peerIDs: [MCPeerID], with mode: MCSessionSendDataMode) throws helps send data between peers.

The delegate method func session(_ session: MCSession, didReceive data: Data, fromPeer peerID: MCPeerID) is triggered on the device that received the message.

Also, an intermediate publisher messagePublisher is used to receive messages, since the MCSession delegate methods fire in the DispatchQueue global().

More details on the Multipeer Connectivity integration prototype can be found in this repository. As an example, this technology has provided the ability to exchange messages between devices.

Don’t hesitate to contact me on Twitter if you have any questions. Also, you can always buy me a coffee.

Protocol-oriented programming is one of the most powerful and flexible tools for competent composition and distribution of responsibility in Swift. In one of the previous articles, protocol-oriented programming was used to manage the state and build a safe sequence of state transitions without additional checks. If you have not read the previous article, then it is recommended to read as material that will show one of the ways to use this wonderful approach.

In this article, we’ll explore another way to use protocol-oriented programming. As a bonus — we’ll write our extension for programming UI components in UIKit that mimics the SwiftUI experience.

What is the task before us? As we all know, all graphical components in UIKit are direct descendants of UIView, each with its own unique properties. A protocol-oriented approach will help us to endow each of the heirs with their own unique properties while making it possible to combine these properties in case we want to use the properties of the parent and the properties of the child. In addition to the protocol-oriented approach, we will also use the Decorator design pattern to bring the SwiftUI declarative syntax experience to UIKit.

Let’s start with the simplest. Select several basic UI classes with which we will start:

1. UIView — all graphical components are inherited from it
2. UIControl — all UIButton, UISegmentedControl and so on are inherited from it
3. Final UI components like UILabel, UITextField, and so on

The inheritance diagram can be seen below:

Let’s start our task by creating an interface:

protocol Stylable {}

This protocol is the basis for all subsequent extensions for our case. Since all graphical components somehow inherit from UIView to cover all components — it is enough to extend UIView with this protocol:

extension UIView: Stylable {}

Some of the most used properties for customizing a UIView are cornerRadius, backgroundColor, clipsToBounds, contentMode, isHidden. Moreover, these properties are often used not only to configure the UIView, but also for its descendants.

Let’s extend the possibilities of Stylable for all UIView classes and their descendants:

extension Stylable where Self: UIView {
    @discardableResult
    func cornerRadius(_ value: CGFloat) -> Self {
        self.layer.cornerRadius = value

        return self
    }

    @discardableResult
    func backgroundColor(_ value: UIColor) -> Self {
        self.backgroundColor = value

        return self
    }

    @discardableResult
    func clipsToBounds(_ value: Bool) -> Self {
        self.clipsToBounds = value

        return self
    }

    @discardableResult
    func contentMode(_ value: UIView.ContentMode) -> Self {
        self.contentMode = value

        return self
    }

    @discardableResult
    func isHidden(_ value: Bool) -> Self {
        self.isHidden = value

        return self
    }
}

Let’s check what this extension gave us:

let customView = UIView()
    .backgroundColor(.red)
    .clipsToBounds(true)
    .cornerRadius(20)
    
let customButton = UIButton()
    .backgroundColor(.red)
    .clipsToBounds(true)
    .cornerRadius(20)
    
let segmentedControl = UISegmentedControl(items: ["One", "Two"])
    .backgroundColor(.red)
    .clipsToBounds(true)
    .cornerRadius(20)
    
let scrollView = UIScrollView()
    .backgroundColor(.red)
    .clipsToBounds(true)
    .cornerRadius(20)

let textField = UITextField()
    .backgroundColor(.red)
    .clipsToBounds(true)
    .cornerRadius(20)

As we can see, thanks to the extension, we can declaratively change properties not only for UIView but also for its descendants.

Let’s move on to configuring the UIControl. For all of its descendants, one of the most used customizable things is tap, properties — isEnabled, tintColor, isUserInteractionEnabled.

Let’s extend the possibilities of Stylable for all UIControl classes and their descendants:

extension Stylable where Self: UIControl {
    @discardableResult
    func action(_ value: (() -> Void)?, event: UIControl.Event = .touchUpInside) -> Self {
        let identifier = UIAction.Identifier(String(describing: event.rawValue))
        let action = UIAction(identifier: identifier) { _ in
            value?()
        }
        
        self.removeAction(identifiedBy: identifier, for: event)
        self.addAction(action, for: event)
        
        return self
    }
    
    @discardableResult
    func secondAction(_ value: ((Bool) -> Void)?, controlEvent: UIControl.Event = .valueChanged) -> Self {
        let identifier = UIAction.Identifier(String(describing: controlEvent.rawValue))
        let action = UIAction(identifier: identifier) { item in
            guard let control = item.sender as? UIControl else {
                return
            }
            value?(!control.isTracking)
        }
        
        self.removeAction(identifiedBy: identifier, for: controlEvent)
        self.addAction(action, for: controlEvent)
        
        return self
    }
    
    @discardableResult
    func isEnabled(_ value: Bool) -> Self {
        self.isEnabled = value
        
        return self
    }
    
    @discardableResult
    func isUserInteractionEnabled(_ value: Bool) -> Self {
        self.isUserInteractionEnabled = value
        
        return self
    }
    
    @discardableResult
    func tintColor(_ value: UIColor) -> Self {
        self.tintColor = value
        
        return self
    }
}

After the Stylable extension for UIControl, an additional customization option became available for all its descendants:

let customButton = UIButton()
    .backgroundColor(.red)
    .clipsToBounds(true)
    .cornerRadius(20)
    .tintColor(.red)
    .action {
       print(#function)
    }
    .isEnabled(true)
    .isUserInteractionEnabled(true)

    
let segmentedControl = UISegmentedControl(items: ["One", "Two"])
    .backgroundColor(.red)
    .clipsToBounds(true)
    .cornerRadius(20)
    .tintColor(.red)
    .action {
       print(#function)
    }
    .isEnabled(true)
    .isUserInteractionEnabled(true)

It is worth noting that when calling the action method using a class method, you should initialize this component lazily to ensure that the class (self) is initialized before the component is initialized.

lazy var customButton = UIButton()
    .backgroundColor(.red)
    .clipsToBounds(true)
    .cornerRadius(20)
    .tintColor(.red)
    .action { [weak self] in
         self?.actionTest()
    }
    .isEnabled(true)
    .isUserInteractionEnabled(true)
    
private func actionTest() {
    print(#function)
}

Let’s also extend UITextField with some of the most popular custom properties:

extension Stylable where Self: UITextField {
    @discardableResult
    func text(_ value: String?) -> Self {
        self.text = value

        return self
    }

    @discardableResult
    func font(_ value: UIFont) -> Self {
        self.font = value

        return self
    }

    @discardableResult
    func textAlignment(_ value: NSTextAlignment) -> Self {
        self.textAlignment = value

        return self
    }

    @discardableResult
    func textColor(_ value: UIColor) -> Self {
        self.textColor = value

        return self
    }

    @discardableResult
    func capitalizationType(_ value: UITextAutocapitalizationType) -> Self {
        self.autocapitalizationType = value

        return self
    }

    @discardableResult
    func keyboardType(_ value: UIKeyboardType) -> Self {
        self.keyboardType = value

        return self
    }

    @discardableResult
    func isSecureTextEntry(_ value: Bool) -> Self {
        self.isSecureTextEntry = value

        return self
    }

    @discardableResult
    func autocorrectionType(_ value: UITextAutocorrectionType) -> Self {
        self.autocorrectionType = value

        return self
    }

    @discardableResult
    func contentType(_ value: UITextContentType?) -> Self {
        self.textContentType = value

        return self
    }

    @discardableResult
    func clearButtonMode(_ value: UITextField.ViewMode) -> Self {
        self.clearButtonMode = value

        return self
    }

    @discardableResult
    func placeholder(_ value: String?) -> Self {
        self.placeholder = value

        return self
    }

    @discardableResult
    func returnKeyType(_ value: UIReturnKeyType) -> Self {
        self.returnKeyType = value

        return self
    }
    
    @discardableResult
    func delegate(_ value: UITextFieldDelegate) -> Self {
        self.delegate = value

        return self
    }

    @discardableResult
    func atributedPlaceholder(
        _ value: String,
        textColor: UIColor,
        textFont: UIFont
    ) -> Self {
        let attributedString = NSAttributedString(
            string: value,
            attributes: [
                NSAttributedString.Key.foregroundColor: textColor,
                NSAttributedString.Key.font: textFont
            ]
        )

        self.attributedPlaceholder = attributedString

        return self
    }
}

Thanks to this extension, now customizing UITextField has become even easier. To customize the GUI, the methods of its parents are available, as well as its own methods:

lazy var textField = UITextField()
     .placeholder("Placeholder")
     .textColor(.red)
     .text("Text")
     .contentType(.URL)
     .autocorrectionType(.yes)
     .font(.boldSystemFont(ofSize: 12))
     .delegate(self) 

It’s worth noting that, similar to capturing self in the UIControl’s action method, assigning a delegate also requires textField to be lazy-initialized.

By analogy, the rest of the graphical components are expanded with properties that will be used for customization.

As a bonus for my readers, I’ve compiled some of the most requested properties in this repository. You need to copy the files to your project; they are ready to use.

Don’t hesitate to contact me on Twitter if you have any questions. Also, you can always buy me a coffee.

Creating and Modifying UIKit Components Like in SwiftUI was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this article, I would like to show one of the most convenient ways to manage the state of an object using a protocol-oriented approach and generics.

This approach is widely used in marketplaces, the banking environment, the service sector, and so on, and assumes that for each state of the object, it is predetermined into which state it is allowed to convert.

Consider an example:

• You ordered a product on Amazon, and your order is assigned the status Initiated
• After the purchase, your product enters the state of the need for payment (ReadyForPayment)
• After payment, it enters the processing state (Pending)
• After checking the availability of the goods, the fact of payment, and transferring it to the delivery service, your order enters the Delivering status
• After delivery of the goods, the status changes to Delivered, with the possibility of returning the goods within 30 days
• After 30 days, the status of the product changes to Finished, and the possibility of returning the goods ceases

In addition to the above positive cases, there are also possible pre-foreseen negative cases, such as:

• After ordering the goods (status ReadyForPayment), payment for the goods was not made within 10 minutes, and the order was put into the Cancelled status
• After processing the order (status Pending), it turned out that the product was out of stock, which is why the status of the order changed to CancelledWithRefunded
• After exceeding the pre-announced delivery time, you requested a refund, and the order status changed to CancelledWithRefunded
• After receiving the order, the product turned out to be of inadequate quality, and you also requested a refund in exchange for returning the product. The order status changed to Refunded

In more detail, a possible status change map is shown in the figure:

The designed system is required to support status routing and the ability to change / scale at the request of the business.

Let’s start with the most important unit of the system being designed:

struct Order<T> {}

As a generic parameter, we will use the order status. Let’s create for each order status, by the requirements described above, its own object:

struct Initiated {}
struct ReadyForPayment {}
struct Pending {}
struct Delivering {}
struct Delivered {}
struct Finished {}
struct Cancelled {}
struct CancelledWithRefunded {}
struct Refunded {}

The cancellation/refund capability implementation will be done using the “Strategy” design pattern. This will reduce the effort to change the statuses for which the business provides the possibility of cancellation/refusal/return of goods.

Let’s create our own protocol for each of the negative scenarios:

protocol Cancellable {}
protocol CancellableWithRefund {}
protocol Refundable {}

Taking into account the current statement of the problem, we will provide the possibility of canceling/refusing/returning goods for previously created statuses:

struct Initiated {}
struct ReadyForPayment: Cancellable {}
struct Pending: CancellableWithRefund {}
struct Delivering: CancellableWithRefund {}
struct Delivered: Refundable {}
struct Finished {}
struct Cancelled {}
struct CancelledWithRefund {}
struct Refunded {}

This completes the design of the system skeleton. Let’s move on to designing status visibility zones. The generic component of the order will help us with this.

1. According to the task statement, the Initiated status can only be changed to ReadyForPayment:

extension Order where T == Initiated {
    var readyForPayment: Order<ReadyForPayment> {
        Order<ReadyForPayment>()
    }
}

2. ReadyForPayment status changes to Pending after successful payment:

extension Order where T == ReadyForPayment {
    var pending: Order<Pending> {
        Order<Pending>()
    }
}

3. Pending status after checking the availability of goods, the fact of payment and transfer it to the delivery service changes to Delivering:

extension Order where T == Pending {
    var delivering: Order<Delivering> {
        Order<Delivering>()
    }
}

4. The status of Delivering changes to Delivered after delivery of the goods:

extension Order where T == Delivering {
    var delivered: Order<Delivered> {
        Order<Delivered>()
    }
}

5. Delivered status after 30 days excision changes to Finished:

extension Order where T == Delivered {
    var finished: Order<Finished> {
        Order<Finished>()
    }
}

6. Statuses that provide for Cancellable in advance can be changed to Cancelled:

extension Order where T: Cancellable {
    var canceled: Order<Cancelled> {
        Order<Cancelled>()
    }
}

7. CancellableWithRefund statuses can be changed to CancelledWithRefund:

extension Order where T: CancellableWithRefund {
    var canceledWithRefund: Order<CancelledWithRefund> {
        Order<CancelledWithRefund>()
    }
}

8. Statuses that provide for the possibility of returning Refundable goods in advance can be changed to Refunded:

extension Order where T: Refundable {
    var refunded: Order<Refunded> {
        Order<Refunded>()
    }
}

The system is ready. Now, we can use the constructor to collect any movement of statuses within predetermined possibilities.

For example, an order for which payment has not gone through moves like this:

let cancelled = Order<Initiated>().readyForPayment.canceled

The order for which it was delivered to the client moves like this:

let finished = Order<Initiated>().readyForPayment.pending.delivering.delivered

One of the important aspects: at each stage, the order movement occurs according to a pre-implemented routing. You cannot move an order from the Pending status to the Finished status bypassing all other intermediate statuses (if this was not allowed by your transition map).

Project sources can be found here.

And finally, don’t hesitate to contact me on Twitter if you have any questions. Also, you can always buy me a coffee.

State Management Using Protocol-Oriented Programming + Generics was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

There are a lot of articles about UIViewController lifecycle. Most of them are aimed at remembering the order in which life cycle methods of UIViewController are called and at using this order for UI configuration and request network data

This article will not include another interpretation of this sequence, assuming that its reader is already familiar with the basics of the life cycle UIViewController.

My task is to show the work of the UIViewController life cycle from a different point of view, namely

• show the source, responsible for the formation and start of the life cycle methods
• cover more corner cases than just showing UIViewController via present / push methods;

The goals of this article are to develop a deeper understanding of how the life cycle works, which will avoid situations where life cycle methods are either called in the wrong way, or not called at all.

UIViewController

Let’s start with a small example in the playground and cover the call of the lifecycle methods with prints and initialize the instance of this UIViewController

class LCViewController: UIViewController {
    
    init() {
        super.init(nibName: nil, bundle: nil)
        print(#function, type(of: self))
    }
    
    required init?(coder: NSCoder) {
        super.init(coder: coder)
    }
    
    override func loadView() {
        print(#function, type(of: self))
        super.loadView()
    }
    
    override func viewDidLoad() {
        print(#function, type(of: self))
        super.viewDidLoad()
    }
    
    override func viewWillAppear(_ animated: Bool) {
        print(#function, type(of: self))
        super.viewWillAppear(animated)
    }
    
    override func viewDidAppear(_ animated: Bool) {
        print(#function, type(of: self))
        super.viewDidAppear(animated)
    }
}

let vc = LCViewController()

In the console, we see that the object initialization block has been executed.

init() LCViewController

The rest of the lifecycle methods did not work, at least for the reason that the initialized object was not shown on the screen. But is this a necessary condition?

Let’s try to change the background color of the root view for the initialized object:

let vc = LCViewController()
vc.view.backgroundColor = .red

Console:

init() LCViewController
loadView() LCViewController
viewDidLoad() LCViewController

What do we see? By default, the view is initialized lazily, but after the color has been changed, the view is finally loaded (methods that signal the start and end of view loading are triggered).

Let’s move on.

We know that the lifecycle methods will work if the UIViewController is shown on the screen (for example, using the present or push methods), but is it possible to trigger the lifecycle of a UIViewController without showing it on the screen?

It is.

It is enough to initialize the UIWindow instance, and place the same UIViewController created above as the rootViewController.

let window = UIWindow()
let vc = LCViewController()
window.rootViewController = vc
window.makeKeyAndVisible()

Console:

init() LCViewController
loadView() LCViewController
viewDidLoad() LCViewController
viewWillAppear(_:) LCViewController
viewDidAppear(_:) LCViewController

In fact, this operation is enough to activate all the lifecycle methods responsible for the appearance of the UIViewController on the screen.

A similar operation is at the heart of launching the application with the installation of the starting UIViewController programmatically (without storyboard / xib) and is used under the hood in the case of storyboard / xib.

According to the documentation, UIWindow is the very source responsible for the formation and start of the UIViewController life cycle.

Let’s look at the rest of the navigation cases in UIKit:

UINavigationController

Let’s create a subclass UINavigationController:

class LCNavigationController: UINavigationController {
    
    override init(rootViewController: UIViewController) {
        super.init(rootViewController: rootViewController)
        print(#function, type(of: self))
    }
    
    required init?(coder: NSCoder) {
        super.init(coder: coder)
    }
    
    override func loadView() {
        print(#function, type(of: self))
        super.loadView()
    }

    override func viewDidLoad() {
        print(#function, type(of: self))
        super.viewDidLoad()
    }

    override func viewWillAppear(_ animated: Bool) {
        print(#function, type(of: self))
        super.viewWillAppear(animated)
    }

    override func viewDidAppear(_ animated: Bool) {
        print(#function, type(of: self))
        super.viewDidAppear(animated)
    }
}

let vc = LCViewController()
let nc = LCNavigationController(rootViewController: vc)

After the usual initialization in the console, we observe:

init() LCViewController
loadView() LCNavigationController
viewDidLoad() LCNavigationController
init(rootViewController:) LCNavigationController

In the case of LCNavigationController, the methods responsible for loading the view fire before the initializer, contrary to the sequence of the UIViewController life cycle. This must be kept in mind when writing the base UINavigationController classes.

In case of setting as rootViewController:

let window = UIWindow()
let vc = LCViewController()
let nc = LCNavigationController(rootViewController: vc)
window.rootViewController = nc
window.makeKeyAndVisible()

Console:

init() LCViewController
loadView() LCNavigationController
viewDidLoad() LCNavigationController
init(rootViewController:) LCNavigationController
viewWillAppear(_:) LCNavigationController
loadView() LCViewController
viewDidLoad() LCViewController
viewWillAppear(_:) LCViewController
viewDidAppear(_:) LCNavigationController
viewDidAppear(_:) LCViewController

The results undermine the theory of a chain of direct forwarding of lifecycle events from UINavigationController to UIViewController. The UIViewController starts loading only after the UINavigationController’s viewWillAppear fires.

TabBarController

Let’s initialize UIViewController and UITabBarController:

class LCTabbarController: UITabBarController {
    init() {
        print(#function, type(of: self))
        super.init(nibName: nil, bundle: nil)
    }
    
    required init?(coder: NSCoder) {
        super.init(coder: coder)
    }
    
    override func loadView() {
        print(#function, type(of: self))
        super.loadView()
    }

    override func viewDidLoad() {
        print(#function, type(of: self))
        super.viewDidLoad()
    }

    override func viewWillAppear(_ animated: Bool) {
        print(#function, type(of: self))
        super.viewWillAppear(animated)
    }

    override func viewDidAppear(_ animated: Bool) {
        print(#function, type(of: self))
        super.viewDidAppear(animated)
    }
}

let vc = LCViewController()
let tc = LCTabbarController()

Bottom line: UITabBarController starts loading the view immediately after initialization without additional manipulations:

init() LCViewController
init() LCTabbarController
loadView() LCTabbarController
viewDidLoad() LCTabbarController

Immediately after setting the UIViewController , the UITabBarController forces the view to be loaded by the active (by default, the first) UIViewController

let vc = LCViewController()
let secondVC = LCViewController()
let tc = LCTabbarController()
tc.setViewControllers([vc, secondVC], animated: true)

Console:

init() LCViewController
init() LCTabbarController
loadView() LCTabbarController
viewDidLoad() LCTabbarController
loadView() LCViewController
viewDidLoad() LCViewController

Immediately after setting the UITabBarController as the rootViewController of the UIWindow, the rest of the life cycle methods are triggered, which is responsible for the appearance of the UITabBarController / the first UIViewController:

let window = UIWindow()
let vc = LCViewController()
let secondVC = LCViewController()
let tc = LCTabbarController()
tc.setViewControllers([vc, secondVC], animated: true)
window.rootViewController = tc
window.makeKeyAndVisible()

Console:

init() LCViewController
init() LCViewController
init() LCTabbarController
loadView() LCTabbarController
viewDidLoad() LCTabbarController
loadView() LCViewController
viewDidLoad() LCViewController
viewWillAppear(_:) LCTabbarController
viewWillAppear(_:) LCViewController
viewDidAppear(_:) LCTabbarController
viewDidAppear(_:) LCViewController

Here we can talk about direct forwarding of life cycle events from UITabBarController to the active (by default, the first) UIViewController.

As for the other root UIViewControllers of the UITabBarController stack, setting data fetch requests to viewDidLoad will cause requests to be sent only after the user has directly navigated to the screen. You need to remember this when developing and, as an example, choose other life cycle methods to receive data or force the loading of the view of these UIViewController.

ContainerController

And the last thing worth considering within the framework of this article is the use of a container — child.

Let’s create a root container and inject another UIViewController into it

class ContainerController: UIViewController {
    
    init() {
        super.init(nibName: nil, bundle: nil)
        print(#function, type(of: self))
    }
    
    required init?(coder: NSCoder) {
        super.init(coder: coder)
    }
    
    override func loadView() {
        print(#function, type(of: self))
        super.loadView()
    }
    
    override func viewDidLoad() {
        print(#function, type(of: self))
        super.viewDidLoad()
        
        let vc = LCViewController()
        vc.willMove(toParent: self)
        view.addSubview(vc.view)
        vc.view.bounds = view.bounds
        vc.view.autoresizingMask = [.flexibleHeight, .flexibleWidth]
        vc.didMove(toParent: self)
        
    }
    
    override func viewWillAppear(_ animated: Bool) {
        print(#function, type(of: self))
        super.viewWillAppear(animated)
    }
    
    override func viewDidAppear(_ animated: Bool) {
        print(#function, type(of: self))
        super.viewDidAppear(animated)
    }
}

As we have already checked, after the initialization of a regular UIViewController, only the init method fires.

let containerVC = ContainerController()

init() ContainerController

Let’s force the container to load the view:

let containerVC = ContainerController()
containerVC.view.backgroundColor = .red

Console:

init() ContainerController
loadView() ContainerController
viewDidLoad() ContainerController
init() LCViewController
loadView() LCViewController
viewDidLoad() LCViewController

Let’s place the container as rootViewController in UIWindow

let window = UIWindow()
let containerVC = ContainerController()
containerVC.view.backgroundColor = .red
window.rootViewController = containerVC
window.makeKeyAndVisible()

Console:

init() ContainerController
loadView() ContainerController
viewDidLoad() ContainerController
init() LCViewController
loadView() LCViewController
viewDidLoad() LCViewController
viewWillAppear(_:) ContainerController
viewWillAppear(_:) LCViewController
viewDidAppear(_:) LCViewController
viewDidAppear(_:) ContainerController

In general, we can talk about the similar behavior of ContainerController and UITabBarController. Forwarding lifecycle events between parent and child is direct.

Conclusion

• The firing order of the lifecycle methods is not valid for all cases and may vary depending on the type of navigation.
• UIWindow — the source, responsible for the formation and start of the UIViewController life cycle
• View of UIViewController is initialized lazily, there are ways to force it to load
• The firing order of the UINavigationController lifecycle methods can vary. Forwarding lifecycle events is not direct
• In the case of UITabBarController, the view is loaded immediately after initialization. There is a direct redirect between the active UIViewController (the first UITabBarController in the stack) and the UITabBarController. By default, UITabBarController methods do not fire inactive UIViewController methods.
• There is a direct forwarding of lifecycle events between an injected UIViewController and its container (on a parent-child basis).

And finally, don’t hesitate to contact me at Twitter, if you have any questions. Also, you can always buy me a coffee