Author: Toomas Vahter

Tags SwiftUI, UIImagePickerController, UIKit, UIViewControllerRepresentable

Combine Foundation iOS Swift SwiftUI

Observing a KVO compatible model in SwiftUI and MVVM

Post author By Toomas Vahter
Post date November 8, 2020
No Comments on Observing a KVO compatible model in SwiftUI and MVVM

In model-view-view model (MVVM) architecture the view model observes the model and provides data for the view by transforming it when needed. When the user interacts with the view and changes the data in it then the view model’s responsibility is to propagate those mutations back to the model object. Therefore, the important part in MVVM is how to manage data flows between objects. This time we’ll take a look on observing key-value observing (KVO) compatible model objects with Combine framework in SwiftUI view. The example view what we’ll build looks like this:

SwiftUI view with text fields for setting first name, last name, and street address. Under that is a label with recipient, postal address, and package contents descriptions. Under that is a button for adding more items to the package. — SwiftUI view which enables editing package related information and displays a summary of the package.

Model layer

The model object represents a package which contains information about the recipient, the sender, and the contents. The recipient and the sender are represented by a Person object which includes a first name, a last name, and a postal address. The contents is an array of immutable PackageContent objects. In Swift, we can use KVO by specifying @objc and dynamic modifiers on properties. Dynamic means that method dispatch is using objective-c runtime and therefore all the types must be representable in objective-c runtime. This immediately adds restrictions to the types we can use. When writing pure Swift code I do not recommend using KVO but sometimes we just need to use it. One example is NSManagedObject from the CoreData framework. But in this app we are not dealing with NSManagedObject but with a simple NSObject subclass instead.

	final class Package: NSObject {
	@objc dynamic var recipient = Person()
	@objc dynamic var sender = Person()
	@objc dynamic var contents = [PackageContent]()
	}

	final class Person: NSObject {
	@objc dynamic var firstName: String = ""
	@objc dynamic var lastName: String = ""
	@objc dynamic var postalAddress = CNPostalAddress()
	}

	final class PackageContent: NSObject {
	init(title: String, weight: Int) {
	self.title = title
	self.weight = weight
	}

	let title: String
	let weight: Int
	}

view raw PackageKVO.swift hosted with ❤ by GitHub

KVO compatible model object.

View Layer

The view object is responsible for describing the UI and rendering data represented by the view model. We have a simple form for modifying the recipient’s first name, last name, and the street name (for keeping this UI simple I left out all the other postal address related properties). At the bottom of the view we have a text object which just describes the package and a button for adding new items to the package’s contents. Whenever any of the package’s properties change, the view needs to reload. View reload is done through the @StateObject property wrapper (read mode about observing view models in MVVM in SwiftUI and @StateObject and MVVM in SwiftUI).

	struct ContentView: View {
	@StateObject var viewModel = ViewModel(package: .makeExample())

	var body: some View {
	ScrollView {
	VStack(spacing: 16) {
	Text("Recipient")
	.font(.headline)
	InputView(title: "First name",
	value: $viewModel.recipientFirstName)
	InputView(title: "Last name",
	value: $viewModel.recipientLastName)
	Text("Address")
	.font(.headline)
	InputView(title: "Street",
	placeholder: "e.g. 37 Christie St",
	value: viewModel.street)
	Text("Summary")
	.font(.headline)
	Text(viewModel.summary)
	.frame(maxWidth: .infinity, alignment: .leading)
	Button("Add item", action: viewModel.addRandomItem)
	}
	.padding()
	}
	}
	}

view raw ContentView.swift hosted with ❤ by GitHub

View Model layer

The view model’s responsibility is to observe the model object and propagating view changes to the model. It acts as a transformation layer where we can transform any data in the model to anything suitable for displaying. In the example below we are reading CNPostalAddress and only returning street name and reading multiple properties and returning a summary string. View models make it easy to contain such logic and also make it more easy to test.

Foundation framework defines a publisher named NSObject.KeyValueObservingPublisher which can be used for observing KVO compatible properties. One of the approaches is to use this publisher and then bind the model changes to the view model’s own property. Combine framework provides a convenient assign operator which takes a target publisher as an argument. Convenient because we can connect it with @Published properties in the view model. @Published properties automatically notify the ObservableObject’s objectWillChange publisher which is observed by a SwiftUI view. As soon as the property changes, SwiftUI view picks up the change and reloads itself. Note that we’ll also need to propagate changes back to the model when user updates the view and therfore the @Published property. This can be achieved by connecting property’s publisher with dropFirst, removeDuplicates and assign publishers where the latter assigns the value to the model object. Drop first is used for ignoring the initial value of the property. One downside is that now we can have the same information both in the view model and in the model. But on the other hand it makes the data streams easy to read and no need to have extra observation for triggering the view reload by manually calling send() on the objectWillChange publisher.

	@Published var recipientFirstName: String = ""

	// Model -> View Model
	package.recipient.publisher(for: \.firstName)
	.assign(to: &$recipientFirstName)

	// View Model -> Model
	$recipientFirstName.dropFirst()
	.removeDuplicates()
	.assign(to: \.firstName, on: package.recipient)
	.store(in: &cancellables)

view raw ViewModel.swift hosted with ❤ by GitHub

Observing model and view changes.

Another approach what we can use is providing properties in the view model which return a Binding. This allows us to write the transformation code inside the get and set closures. This is what we have done with the street property. Note that we’ll still need to observe the model as the model can change at any point. Binding just provides a way of accessing the value. Therefore, we’ll need to set up an observation and calling send() on the objectWillChange publisher.

	// Observing changes
	package.recipient.publisher(for: \.postalAddress)
	.notifyObjectWillChange(objectWillChange)
	.store(in: &cancellables)

	// Providing a binding for the view
	var street: Binding<String> {
	let package = self.package
	return Binding<String>(
	get: {
	package.recipient.postalAddress.street
	},
	set: { newValue in
	let postalAddress = package.recipient.postalAddress.mutableCopy() as! CNMutablePostalAddress
	postalAddress.street = newValue
	package.recipient.postalAddress = postalAddress
	}
	)
	}

	extension Publisher where Self.Failure == Never {
	public func notifyObjectWillChange(_ objectWillChange: ObservableObjectPublisher) -> AnyCancellable {
	return self.sink { _ in
	objectWillChange.send()
	}
	}
	}

view raw ViewModel.swift hosted with ❤ by GitHub

Providing a binding for the view.

If we go back to the SwiftUI view and connect all the properties then the full implementation of the view model looks like this:

	extension ContentView {
	final class ViewModel: ObservableObject {
	private let package: Package
	private var cancellables = [AnyCancellable]()

	init(package: Package) {
	self.package = package

	// Model -> View Model
	package.recipient.publisher(for: \.firstName)
	.assign(to: &$recipientFirstName)
	package.recipient.publisher(for: \.lastName)
	.assign(to: &$recipientLastName)

	package.recipient.publisher(for: \.postalAddress)
	.notifyObjectWillChange(objectWillChange)
	.store(in: &cancellables)
	package.publisher(for: \.contents)
	.notifyObjectWillChange(objectWillChange)
	.store(in: &cancellables)

	// View Model -> Model
	$recipientFirstName.dropFirst()
	.removeDuplicates()
	.assign(to: \.firstName, on: package.recipient)
	.store(in: &cancellables)
	$recipientLastName.dropFirst()
	.removeDuplicates()
	.assign(to: \.lastName, on: package.recipient)
	.store(in: &cancellables)
	}

	// Example of using published property
	@Published var recipientFirstName: String = ""
	@Published var recipientLastName: String = ""

	// Example of using bindings for propagating values
	var street: Binding<String> {
	let package = self.package
	return Binding<String>(
	get: {
	package.recipient.postalAddress.street
	},
	set: { newValue in
	let postalAddress = package.recipient.postalAddress.mutableCopy() as! CNMutablePostalAddress
	postalAddress.street = newValue
	package.recipient.postalAddress = postalAddress
	}
	)
	}

	var summary: String {
	let contents = package.contents
	.map({ "\($0.title) \($0.weight)" })
	.joined(separator: ", ")
	return """
	Recipient: \(package.recipient.firstName) \(package.recipient.lastName)
	Postal address: \(CNPostalAddressFormatter().string(from: package.recipient.postalAddress))
	Contents: \(contents)
	"""
	}

	func addRandomItem() {
	let weight = Int.random(in: 200…300)
	let item = PackageContent(title: "Light bulb", weight: weight)
	package.contents.append(item)
	}
	}
	}

view raw ViewModel.swift hosted with ❤ by GitHub

View model implementation for the view.

Summary

Key-value observing is getting less and less used after the introduction of Combine and SwiftUI. But there are still times when we need to connect good old KVO compatible NSObject subclasses with a SwiftUI view. Therefore, it is good to know how to handle KVO in SwiftUI views as well.

If this was helpful, please let me know on Mastodon@toomasvahter or Twitter @toomasvahter. Feel free to subscribe to RSS feed. Thank you for reading.

Project

SwiftUIMVVMKVOObserving (GitHub, Xcode 12.1)

Tags @Published, @StateObject, Combine, KeyValueObservingPublisher, KVO, MVVM, objectWillChange, ObservableObject, publisher, SwiftUI

iOS Swift UIKit

Resizing UIImages with aspect fill on iOS

Post author By Toomas Vahter
Post date October 25, 2020
2 Comments on Resizing UIImages with aspect fill on iOS

Resizing images is an important topic when we need to display images which do not match with the intended display size. For example, rendering much large images in a small rectangle. UIImageView supports scaling images automatically but that becomes inefficient when dealing with larger images. In this blog post we’ll take a look on how to crop and resize images to fill a target size while keeping the original aspect ratio.

Cropping and scaling UIImages

The end goal of this exercise is to create a small ImageScaler struct which supports cropping the original image and resizing it to the target size. The final instance of the UIImage has smaller size which means that less memory is required for rendering the image.

	// Scaling the full image
	let originalImage = UIImage(named: "example_photo.jpg")!
	var targetSize = CGSize(width: 100, height: 100)
	imageView.image = ImageScaler.scaleToFill(originalImage, in: targetSize)

	// Scaling only a small part of the image
	let originalImage = UIImage(named: "example_photo.jpg")!
	var fromRect = CGRect(x: 362.0, y: 449.0, width: 260.0, height: 160.0)
	var targetSize = CGSize(width: 100, height: 100)
	imageView.image = ImageScaler.scaleToFill(originalImage, in: targetSize, from: fromRect)

view raw Image.swift hosted with ❤ by GitHub

Scaling an image to a target size.

As the first step let’s take a look on how to write the cropping and scaling logic. NSHipster has a great post about the different techniques what we can use for resizing images. We are going to use UIGraphicsImageRenderer for creating the scaled image. One important thing to note is that when we use CGContext for drawing the image then we need to flip the coordinate system because UIImage’s and CGContext’s coordinates do not match (UIImage uses upper left corner, CGContext bottom left corner). Coordinates can be transformed from the UIImage coordinate system to the CGContext coordinate system by combining translation and scale transforms. First we’ll move the image and then flip it in the opposite direction so that the final frame stays in the image rect.

	var transform = CGAffineTransform(translationX: 0.0, y: targetSize.height)
	transform = transform.scaledBy(x: 1, y: -1)
	context.cgContext.concatenate(transform)

view raw CGContext.swift hosted with ❤ by GitHub

Flipping the image vertically in the CGContext .

Next step after applying the affine transform is to crop the image. UIImage has a cgImage property but it can be nil when the instance was initialized with a CIImage backing storage. Therefore, we’ll need to handle both cases. Apple has a convenience drawing method for CIImage which already knows how to handle cropping. On the otherhand CGImage needs to be cropped first and then drawn. The full implementation of the crop and resize becomes:

	private static func scale(_ image: UIImage, fromRect: CGRect = .zero, targetSize: CGSize) -> UIImage {
	let renderer = UIGraphicsImageRenderer(size: targetSize)
	return renderer.image { context in
	// UIImage and CGContext coordinates are flipped.
	var transform = CGAffineTransform(translationX: 0.0, y: targetSize.height)
	transform = transform.scaledBy(x: 1, y: -1)
	context.cgContext.concatenate(transform)
	// UIImage -> cropped CGImage
	let makeCroppedCGImage: (UIImage) -> CGImage? = { image in
	guard let cgImage = image.cgImage else { return nil }
	guard !fromRect.isEmpty else { return cgImage }
	return cgImage.cropping(to: fromRect)
	}
	if let cgImage = makeCroppedCGImage(image) {
	context.cgContext.draw(cgImage, in: CGRect(origin: .zero, size: targetSize))
	}
	else if let ciImage = image.ciImage {
	var transform = CGAffineTransform(translationX: 0.0, y: image.size.height)
	transform = transform.scaledBy(x: 1, y: -1)
	let adjustedFromRect = fromRect.applying(transform)
	let ciContext = CIContext(cgContext: context.cgContext, options: nil)
	ciContext.draw(ciImage, in: CGRect(origin: .zero, size: targetSize), from: adjustedFromRect)
	}
	}
	}

view raw Resize.swift hosted with ❤ by GitHub

Crop and resize the image.

Calculating rects for scaled to fill behavior

Now we have cropping and resize logic available. Depending on the target size of the image we’ll need to figure out which parts of the original image should be cropped so that the original aspect ratio does not change. Note that the original image size and the target size can have different aspect ratios: square, portrait, landscape. Therefore, we’ll need to handle all the cases. Let’s start by adding convenience properties to CGSize.

	extension CGSize {
	enum Aspect {
	case portrait, landscape, square
	}
	var aspect: Aspect {
	switch width / height {
	case 1.0:
	return .square
	case 1.0…:
	return .landscape
	default:
	return .portrait
	}
	}
	var aspectRatio: CGFloat {
	return width / height
	}
	}

view raw CGSizeAspect.swift hosted with ❤ by GitHub

Convenience properties on CGRect.

After that we can add a method on CGRect which calculates a CGRect of the original image, what can be drawn in the target image. There are 9 different combinations what we need to handle. But the core logic stays the same: scale the current rectangle so that it fills the target size while keeping the original aspect ratio. Then chop off the sides which go over the target size and center the image in the target size.

	extension CGRect {
	func scaled(toFillSize targetSize: CGSize) -> CGRect {
	var scaledRect = self
	switch (size.aspect, targetSize.aspect) {
	case (.portrait, .portrait), (.portrait, .square):
	scaledRect.size.height = width / targetSize.aspectRatio
	scaledRect.size.width = width
	if scaledRect.height > height {
	scaledRect.size = size
	}
	scaledRect.origin.y -= (scaledRect.height – height) / 2.0
	case (.portrait, .landscape), (.square, .landscape):
	scaledRect.size.height = width / targetSize.aspectRatio
	scaledRect.size.width = width
	if scaledRect.height > height {
	scaledRect.size = size
	}
	scaledRect.origin.y -= (scaledRect.height – height) / 2.0
	case (.landscape, .portrait), (.square, .portrait):
	scaledRect.size.height = height
	scaledRect.size.width = height * targetSize.aspectRatio
	if scaledRect.width > width {
	scaledRect.size = size
	}
	scaledRect.origin.x -= (scaledRect.width – width) / 2.0
	case (.landscape, .landscape), (.landscape, .square):
	scaledRect.size.height = height
	scaledRect.size.width = height * targetSize.aspectRatio
	if scaledRect.size.width > width {
	scaledRect.size = size
	}
	scaledRect.origin.x -= (scaledRect.width – width) / 2.0
	case (.square, .square):
	return self
	}
	return scaledRect.integral
	}
	}

view raw CGRectAspectScale.swift hosted with ❤ by GitHub

Scaling rect to the target size with keeping the initial aspect ratio.

Finalizing the ImageScaler

We can proceed with creating a single static method which takes care of scaling the original image to the target size while keeping the aspect ratio. The whole implementation looks like this:

	struct ImageScaler {
	static func scaleToFill(_ image: UIImage, in targetSize: CGSize, from fromRect: CGRect = .zero) -> UIImage {
	let rect = fromRect.isEmpty ? CGRect(origin: .zero, size: image.size) : fromRect
	let scaledRect = rect.scaled(toFillSize: targetSize)
	return scale(image, fromRect: scaledRect, targetSize: targetSize)
	}

	private static func scale(_ image: UIImage, fromRect: CGRect = .zero, targetSize: CGSize) -> UIImage {
	let renderer = UIGraphicsImageRenderer(size: targetSize)
	return renderer.image { context in
	// UIImage and CGContext coordinates are flipped.
	var transform = CGAffineTransform(translationX: 0.0, y: targetSize.height)
	transform = transform.scaledBy(x: 1, y: -1)
	context.cgContext.concatenate(transform)
	// UIImage -> cropped CGImage
	let makeCroppedCGImage: (UIImage) -> CGImage? = { image in
	guard let cgImage = image.cgImage else { return nil }
	guard !fromRect.isEmpty else { return cgImage }
	return cgImage.cropping(to: fromRect)
	}
	if let cgImage = makeCroppedCGImage(image) {
	context.cgContext.draw(cgImage, in: CGRect(origin: .zero, size: targetSize))
	}
	else if let ciImage = image.ciImage {
	var transform = CGAffineTransform(translationX: 0.0, y: image.size.height)
	transform = transform.scaledBy(x: 1, y: -1)
	let adjustedFromRect = fromRect.applying(transform)
	let ciContext = CIContext(cgContext: context.cgContext, options: nil)
	ciContext.draw(ciImage, in: CGRect(origin: .zero, size: targetSize), from: adjustedFromRect)
	}
	}
	}
	}

view raw

ImageScaler.swift

hosted with ❤ by GitHub

Summary

While UIImageView supports cropping and scaling images, we’ll need to do this on our own. It becomes handy especially when dealing with larger images.

If this was helpful, please let me know on Mastodon@toomasvahter or Twitter @toomasvahter. Feel free to subscribe to RSS feed. Thank you for reading.

Tags aspectRatio, crop, resize, scale, scaleToFill, UIGraphicsImageRenderer, UIImage

iOS macOS Swift

Publishing API documentation in GitHub with Jazzy

Post author By Toomas Vahter
Post date October 11, 2020
2 Comments on Publishing API documentation in GitHub with Jazzy

Jazzy is an excellent tool for generating API documentation for Swift and Objective-C projects. Let’s take a look how to generate and publish API documentation in GitHub with Jazzy.

Installing Jazzy

Installation: sudo gem install jazzy

Jazzy config file for a Swift package

Configuration options can be passed into Jazzy directly with the command or adding them to the a file, by default it is .jazzy.yaml. We’ll use the default path as then we can run Jazzy without any command line arguments: the configuration is read from the configuration file. For seeing all the available configuration options run jazzy config -h. Just note that the configuration file expects snakecase (build-tool-arguments becomes build_tool_arguments). Let’s take a look on Swift package IndexedDataStore which can be built both for macOS and iOS. It has some additional functions for iOS and therefore it is preferred to build iOS target when running Jazzy. Otherwise API documentation would not contain those public functions meant for iOS. Typically Swift package is built using swift build command. The current state is that there is no easy way for just specifying the target OS to the swift build command. What we can do instead is using xcodebuild command which knows how to build Swift packages as well. We’ll just need to specify the scheme, sdk, and destination arguments. If we now run jazzy command without any arguments, it will read the configuration file, and generate API documentation which includes functions which require UIKit.

	author: Toomas Vahter
	author_url: https://www.augmentedcode.io
	github_url: https://github.com/laevandus/IndexedDataStore
	output: Docs
	swift_build_tool: xcodebuild
	build_tool_arguments:
	– -scheme
	– IndexedDataStore
	– -sdk
	– iphoneos
	– -destination,platform=iOS Simulator,OS=latest,name=iPhone 11 Pro

view raw .jazzy.yaml hosted with ❤ by GitHub

Configuration file for Jazzy which builds documentation for iOS.

GitHub action for publish API documentation

Thankfully there is a GitHub action available for publishing API documentation with Jazzy. We can set up a GitHub action with a name PublishDocumentation and store it in the repository’s .github/workflows folder.

	name: PublishDocumentation
	on:
	workflow_dispatch:
	release:
	types: [ published ]
	jobs:
	publish:
	runs-on: macos-latest
	steps:
	– uses: actions/checkout@v2
	– name: Publish Jazzy Docs
	uses: steven0351/publish-jazzy-docs@v1
	with:
	personal_access_token: ${{ secrets.ACCESS_TOKEN }}
	config: .jazzy.yaml

view raw publish_docs.yml hosted with ❤ by GitHub

GitHub action which publishes API documentation to GitHub pages.

The GitHub action is triggered either manually or when publishing a release. Manual trigger is called workflow_dispatch and when it is set, GitHub webpage will display a “Run workflow” button. This is very handy when testing GitHub actions. Another thing to note is that publish-jazzy-docs requires repository access because it needs to write the documentation files to the gh-pages branch. For giving repository access we’ll need to set up personal access token with repo scope. Secondly, we’ll need to paste the created token to the repository’s secrets. In this example, we have added a secret named ACCESS_TOKEN and the value is the personal access token. Now, if we have committed and pushed the GitHub action then we can open the repository on GitHub.com, navigate to actions, selecting PublishDocumentation, and using Run workspace button for triggering the wokrflow. If everything goes well, then the workspace creates a gh-pages branch which in turn creates a new GitHub page. In this case the URL to the new GitHub page looks like: https://laevandus.github.io/IndexedDataStore/ (link). This is what we wanted to achieve, API documentation publiched on GitHub.

Summary

We set up Jazzy for a Swift package and used it to generate API documentation. Generated API documentation was published to a GitHub page.

If this was helpful, please let me know on Mastodon@toomasvahter or Twitter @toomasvahter. Feel free to subscribe to RSS feed. Thank you for reading.

Tags documentation, GitHub, Jazzy, Swift, Swift Package, Xcode

iOS macOS Swift SwiftUI

Animating a custom wave shape in SwiftUI

Post author By Toomas Vahter
Post date September 27, 2020
No Comments on Animating a custom wave shape in SwiftUI

Shape protocol in SwiftUI is used for defining views which render custom shapes. Shapes have one required method which takes in a rect and returns a Path. In addition to view protocol, shape conforms to Animatable protocol as well. Therefore we can quite easily make our custom shape to animate from one state to another. We’ll use two parameters for defining our Wave shape: amplitude and frequency. Amplitude dictates the height of the wave and frequency the distance between wave peaks.

Animating wave shape by changing amplitude and frequency — Animating wave shape.

SwiftUI view displaying an animatable wave shape

Let’s take a look on an example view which displays custom Wave shape. We’ll use @State property wrappers for storing amplitude and frequency because we want to change those values when running the app. Those properties are updated with random values when pressing a button. The wave has blue fill color, fixed height, and basic easeInOut animation. The animation is used when amplitude and/or frequency change.

	struct ContentView: View {
	@State private var amplitude = 10.0
	@State private var frequency = 0.1

	var body: some View {
	ZStack {
	Wave(amplitude: amplitude, frequency: frequency)
	.fill(Color.blue)
	.frame(height: 300.0)
	.animation(.easeInOut(duration: 3))
	Button(action: toggleAnimation, label: {
	Text("Animate")
	})
	.padding(4)
	.background(Color.red)
	.cornerRadius(8)
	.foregroundColor(.white)
	}
	}

	func toggleAnimation() {
	amplitude = amplitude <= 15.0 ? Double.random(in: 30.0…60.0) : Double.random(in: 5.0…15.0)
	frequency = frequency <= 0.2 ? Double.random(in: 0.2…0.4) : Double.random(in: 0.05…0.2)
	}
	}

view raw ContentView.swift hosted with ❤ by GitHub

Content view rendering a wave shape with a button starting an animation.

Animatable wave shape

Like mentioned in the introduction, the Shape protocol defines a required method which has a rect argument and returns a Path. The path starts from the top left edge. Sine function is used for calculating y coordinates for every x coordinate with a 1 point step. Right, bottom and left edges are just straight lines.

Animatable protocol defines an animatableData property and because we have two parameters (amplitude and frequency) we’ll need to use AnimatablePair type. If there would be more parameters then AnimatablePair should contain one or more AnimatablePair types (and so on). Note that values in animatableData must conform to VectorArithmetic protocol which Double type already does.

When animation is running then SwiftUI calculates amplitude and frequency values based on the current animation frame and sets it to the animatableData property. Then new Path value is calculated and rendered.

	struct Wave: Shape {
	var amplitude: Double
	var frequency: Double

	func path(in rect: CGRect) -> Path {
	let sinCenterY = amplitude
	let path = CGMutablePath()
	path.move(to: CGPoint(x: 0, y: sinCenterY))
	let width = Double(rect.width)
	for x in stride(from: 0, through: width, by: 1) {
	let y = sinCenterY + amplitude * sin(frequency * x)
	path.addLine(to: CGPoint(x: x, y: y))
	}
	path.addLine(to: CGPoint(x: rect.maxX, y: rect.maxY))
	path.addLine(to: CGPoint(x: rect.minX, y: rect.maxY))
	path.addLine(to: CGPoint(x: Double(rect.minX), y: sinCenterY))
	return Path(path)
	}

	var animatableData: AnimatablePair<Double, Double> {
	get {
	return AnimatablePair(amplitude, frequency)
	}
	set {
	amplitude = newValue.first
	frequency = newValue.second
	}
	}
	}

view raw Wave.swift hosted with ❤ by GitHub

Animatable Wave shape.

Summary

We took a look at the Shape protocol and created a wave shape. In addition, we made the wave to animate from one amplitude and frequency state to a new state.

If this was helpful, please let me know on Mastodon@toomasvahter or Twitter @toomasvahter. Feel free to subscribe to RSS feed. Thank you for reading.

Tags Animatable, animatableData, AnimatablePair, animation, Shape, sine, SwiftUI

iOS macOS Swift Xcode

Adding SwiftLint to a project in Xcode

Post author By Toomas Vahter
Post date September 13, 2020
1 Comment on Adding SwiftLint to a project in Xcode

SwiftLint is a tool for validating the style and conventions in Swift files. It is easy to integrate to a project. Minimum set up consists of installing SwiftLint and adding a build phase to your app target in Xcode. SwiftLint comes with a default list of rules, but if you would like to change the rules then it is required to create a configuration file in yaml. Let’s take a look on how to install, add build step, and use a separate configuration file with a custom set of rules.

SwiftLint is available in homebrew so the easies way is to install it with brew install swiftlint command. Next step is to add the build phase to a target. I am gonna use one of my example app which is available on GitHub: SwiftPackageAppWorkspace. This project uses a workspace and includes an app project and Swift package.

	git clone https://github.com/laevandus/SwiftPackageAppWorkspace.git
	open ButtonGallery.xcworkspace

view raw homebrew.sh hosted with ❤ by GitHub

Cloning example project and opening it in Xcode.

Click on the ButtonGallery project in the file navigator, then on the iOS target and build phases. Will use the + button for adding a new run script phase. Note that we already use the config argument for letting SwiftLint know where the config file exists (by default SwiftLint looks for .swiftlint.yml file in the same folder the project file is).

	if which swiftlint >/dev/null; then
	# Relative path from the .xcodeproj which contains this script
	swiftlint lint –config ../swiftlint.yml
	else
	echo "warning: SwiftLint not installed"
	fi

view raw LintSources.sh hosted with ❤ by GitHub

Build phase calling swiftlint with custom configuration file in one folder up from the .xcodeproj.

Build phase which triggers swiftlint with custom configuration.

Last step is to add a custom configuration file to the repository checkout. We’ll add it to the checkout’s root folder which is the parent folder of the ButtonGallery.xcodeproj. I have went through the full list of rules available for SwiftLint and picked the ones which match with my coding style. SwiftLint has a list of default rules. The list of evaluated rules can be expanded with opt_in_rules and rules from default list can be disabled with disabled_rules list. Also I prefer to have else on a newline so I added statement_position configuration with statement_mode: uncuddled_else. Included defines a list of folder paths relative to the .xcodeproj calling swiftlint.

	included:
	– ../ButtonKit
	– ../ButtonGallery

	disabled_rules:
	– compiler_protocol_init
	– cyclomatic_complexity
	– file_length
	– force_cast
	– function_body_length
	– function_parameter_count
	– identifier_name
	– multiple_closures_with_trailing_closure
	– notification_center_detachment
	– line_length
	– trailing_whitespace
	– type_body_length
	– type_name
	– todo

	opt_in_rules:
	– anyobject_protocol
	– array_init
	– closure_end_indentation
	– closure_spacing
	– collection_alignment
	– contains_over_filter_count
	– contains_over_filter_is_empty
	– contains_over_first_not_nil
	– contains_over_range_nil_comparison
	– convenience_type
	– discouraged_object_literal
	– discouraged_optional_boolean
	– empty_collection_literal
	– empty_count
	– empty_string
	– empty_xctest_method
	– enum_case_associated_values_count
	– expiring_todo
	– explicit_init
	– fallthrough
	– fatal_error_message
	– file_name_no_space
	– first_where
	– flatmap_over_map_reduce
	– identical_operands
	– joined_default_parameter
	– last_where
	– legacy_multiple
	– legacy_random
	– literal_expression_end_indentation
	– lower_acl_than_parent
	# useful for frameworks with public interface – missing_docs
	– multiline_function_chains
	– multiline_parameters
	– multiline_parameters_brackets
	– nslocalizedstring_key
	– operator_usage_whitespace
	– optional_enum_case_matching
	– overridden_super_call
	– override_in_extension
	– pattern_matching_keywords
	– prefer_self_type_over_type_of_self
	– prefer_zero_over_explicit_init
	– private_outlet
	– prohibited_super_call
	– reduce_into
	– redundant_nil_coalescing
	– redundant_type_annotation
	– single_test_class
	– sorted_first_last
	– sorted_imports
	– static_operator
	– toggle_bool
	– unneeded_parentheses_in_closure_argument
	– unused_declaration
	– unused_import
	– vertical_parameter_alignment_on_call
	– vertical_whitespace_closing_braces

	# if {
	# }
	# else {
	# }
	statement_position:
	statement_mode: uncuddled_else

view raw swiftlint.yml hosted with ❤ by GitHub

Custom configuration file for SwiftLint.

The next time the target is built it will run SwiftLint with custom configuration and show warnings and/or errors in Xcode.

Warnings generated by SwiftLint in the example project.

Summary

SwiftLint is easy to set up and helps to keep the code style consistent in projects. In additional to style SwiftLint is capable of suggesting different coding conventions like use enum instead of struct with only static functions. For making it easy to add custom configuration to new project I have set up a command alias in ~/.zshrc which looks like this: alias xcode_lint_add='cp ~/Dev/swiftlint.yml swiftlint.yml && mate swiftlint.yml' Run xcode_lint_add in the root of the cloned project.

If this was helpful, please let me know on Mastodon@toomasvahter or Twitter @toomasvahter. Feel free to subscribe to RSS feed. Thank you for reading.

Tags build phase, linter, style, swiftlint, Xcode

Foundation iOS macOS Swift Xcode

Creating a pre-push git hook in Swift script

Post author By Toomas Vahter
Post date August 30, 2020
No Comments on Creating a pre-push git hook in Swift script

Git hooks are scripts written in any scripting language and are triggered when important actions occur. Hooks are stored in the repository’s .git/hooks folder. The script needs to have an appropriate filename without a path extension and also have executable permissions. Push event is an excellent time for triggering unit-tests and making sure local changes have not broken any. Therefore we’ll look into how to create a pre-push script for an iOS project in Swift.

Quick introduction to scripts written in Swift

Setting up a simple script in Swift follows steps familiar from other languages. The script file needs to start with #!/usr/bin/swift followed by the actual script. A simple example script can look like this.

	#!/usr/bin/swift
	print("Example")

view raw Script.swift hosted with ❤ by GitHub

Example script written in Swift.

The command for running the script is swift Script.swift (if the filename is Script.swift). Another way is making the script executable by adding executable permissions to the file by running chmod +x Script.swift command. Then the script can be run with ./Script.swift (makes sense to drop the file extension).

Building a Xcode project for testing

The pre-push script contains of 3 steps: building the project for testing, running tests, and finally printing out the code coverage results. The first step catches build errors, the second step test failures, and the third step prints out code coverage results. Code coverage can be enabled in the scheme’s test action or adding -enableCodeCoverage YES to the xcodebuild command. Before we jump into creating a xcodebuild command with correct arguments then we’ll need to tackle the problem of calling the xcodebuild command line application from the Swift script. Command line applications can be invoked with the Foundation’s Process class. We’ll add an extension which deals with launching a specified command with zsh and printing out the standard output and error.

	extension Process {
	@discardableResult
	static func runZshCommand(_ command: String) -> Int32 {
	let process = Process()
	process.launchPath = "/bin/zsh"
	process.arguments = ["-c", command]
	process.standardOutput = {
	let pipe = Pipe()
	pipe.fileHandleForReading.readabilityHandler = { handler in
	guard let string = String(data: handler.availableData, encoding: .utf8), !string.isEmpty else { return }
	print(string)
	}
	return pipe
	}()
	process.standardError = {
	let pipe = Pipe()
	pipe.fileHandleForReading.readabilityHandler = { handler in
	guard let string = String(data: handler.availableData, encoding: .utf8), !string.isEmpty else { return }
	print(string)
	}
	return pipe
	}()
	process.launch()
	process.waitUntilExit()
	(process.standardOutput as! Pipe).fileHandleForReading.readabilityHandler = nil
	(process.standardError as! Pipe).fileHandleForReading.readabilityHandler = nil
	return process.terminationStatus
	}
	}

view raw Process.swift hosted with ❤ by GitHub

Launching command line application with Process.

The next step in the script is to define the project related configuration and create the xcodebuild command. All the user defined arguments are wrapped in quotes for avoiding any issues with whitespaces. The command is pretty straight-forward. If there are any build errors then the result code is not equal to 0. Then we can use the same error code for exiting the Swift script with exit() function.

	#!/usr/bin/swift

	import Foundation

	let projectType = "-workspace"
	let projectPath = "SignalPath.xcworkspace"
	let scheme = "SignalPathiOS"
	let destinationDevice = "platform=iOS Simulator,name=iPhone 11 Pro Max"
	let resultBundlePath = "PrePush.xcresult"

	removeResultBundle(at: resultBundlePath)

	print("Building for testing…")
	let buildCommand = [
	"xcodebuild",
	"build-for-testing",
	"-quiet",
	projectType, projectPath.wrappedInQuotes,
	"-scheme", scheme.wrappedInQuotes,
	"-destination", destinationDevice.wrappedInQuotes
	].joined(separator: " ")
	let buildStatus = Process.runZshCommand(buildCommand)
	if buildStatus != 0 {
	exit(buildStatus)
	}

	extension String {
	var wrappedInQuotes: String {
	return "\"\(self)\""
	}
	}

view raw pre-push-1.swift hosted with ❤ by GitHub

Building a Xcode project for testing.

Running unit-tests

The command used for running unit-tests is fairly similar. Instead of build-without-testing we are using test-without-building argument and additionally provide a path where the result bundle is written to. This bundle contains information about the test run. Note that this path must not exist, otherwise xcodebuild stops with an error. Therefore we delete the existing file before running the command. Moreover, when there is a failure, we’ll clean up the path as well – pre-push script should not leave any temporary files.

	removeResultBundle(at: resultBundlePath)

	print("Running tests…")
	let testCommand = [
	"xcodebuild",
	"test-without-building",
	"-quiet",
	projectType, projectPath.wrappedInQuotes,
	"-scheme", scheme.wrappedInQuotes,
	"-destination", destinationDevice.wrappedInQuotes,
	"-resultBundlePath", resultBundlePath.wrappedInQuotes
	].joined(separator: " ")
	let testStatus = Process.runZshCommand(testCommand)
	if testStatus != 0 {
	removeResultBundle(at: resultBundlePath)
	exit(testStatus)
	}

	func removeResultBundle(at path: String) {
	guard FileManager.default.fileExists(atPath: path) else { return }
	try? FileManager.default.removeItem(atPath: path)
	}

view raw pre-push-2.swift hosted with ❤ by GitHub

Running unit-tests in a pre-built project.

Printing out code coverage

Last step is optional but it is nice to see code coverage information when pushing changes to a server. Xcode provides a command line application for viewing coverage data in human readable form. One of the options is printing out code coverage per target which gives a nice and concise overview.

	let coverageCommand = [
	"xcrun",
	"xccov",
	"view",
	"–only-targets",
	"–report", resultBundlePath.wrappedInQuotes
	].joined(separator: " ")
	Process.runZshCommand(coverageCommand)

	removeResultBundle(at: resultBundlePath)

	print("Success")
	exit(0)

view raw pre-push-3.swift hosted with ❤ by GitHub

Printing out code coverage per target.

Summary

We looked into how to create a pre-push script in Swift. It called other command line applications for building the project, running the tests, and printing out code coverage information. The full script is available below, feel free to copy-paste it to your projects. The one last thing to consider is adding an alias in Terminal for easy installation: alias xcode_pre_push_add='cp ~/Dev/pre-push .git/hooks/pre-push && mate .git/hooks/pre-push' This just copies it from predefined location to the repository checkout and opens it in an editor for setting project related settings (replace mate with any editor).

	#!/usr/bin/swift

	import Foundation

	let projectType = "-workspace"
	let projectPath = "SignalPath.xcworkspace"
	let scheme = "SignalPathiOS"
	let destinationDevice = "platform=iOS Simulator,name=iPhone 11 Pro Max"
	let resultBundlePath = "PrePush.xcresult"

	print("Building for testing…")
	let buildCommand = [
	"xcodebuild",
	"build-for-testing",
	"-quiet",
	projectType, projectPath.wrappedInQuotes,
	"-scheme", scheme.wrappedInQuotes,
	"-destination", destinationDevice.wrappedInQuotes
	].joined(separator: " ")
	let buildStatus = Process.runZshCommand(buildCommand)
	if buildStatus != 0 {
	exit(buildStatus)
	}

	removeResultBundle(at: resultBundlePath)

	print("Running tests…")
	let testCommand = [
	"xcodebuild",
	"test-without-building",
	"-quiet",
	projectType, projectPath.wrappedInQuotes,
	"-scheme", scheme.wrappedInQuotes,
	"-destination", destinationDevice.wrappedInQuotes,
	"-resultBundlePath", resultBundlePath.wrappedInQuotes
	].joined(separator: " ")
	let testStatus = Process.runZshCommand(testCommand)
	if testStatus != 0 {
	removeResultBundle(at: resultBundlePath)
	exit(testStatus)
	}

	let coverageCommand = [
	"xcrun",
	"xccov",
	"view",
	"–only-targets",
	"–report", resultBundlePath.wrappedInQuotes
	].joined(separator: " ")
	Process.runZshCommand(coverageCommand)

	removeResultBundle(at: resultBundlePath)

	print("Success")
	exit(0)

	// MARK: –

	extension String {
	var wrappedInQuotes: String {
	return "\"\(self)\""
	}
	}

	extension Process {
	@discardableResult
	static func runZshCommand(_ command: String) -> Int32 {
	let process = Process()
	process.launchPath = "/bin/zsh"
	process.arguments = ["-c", command]
	process.standardOutput = {
	let pipe = Pipe()
	pipe.fileHandleForReading.readabilityHandler = { handler in
	guard let string = String(data: handler.availableData, encoding: .utf8), !string.isEmpty else { return }
	print(string)
	}
	return pipe
	}()
	process.standardError = {
	let pipe = Pipe()
	pipe.fileHandleForReading.readabilityHandler = { handler in
	guard let string = String(data: handler.availableData, encoding: .utf8), !string.isEmpty else { return }
	print(string)
	}
	return pipe
	}()
	process.launch()
	process.waitUntilExit()
	(process.standardOutput as! Pipe).fileHandleForReading.readabilityHandler = nil
	(process.standardError as! Pipe).fileHandleForReading.readabilityHandler = nil
	return process.terminationStatus
	}
	}

	func removeResultBundle(at path: String) {
	guard FileManager.default.fileExists(atPath: path) else { return }
	try? FileManager.default.removeItem(atPath: path)
	}

view raw pre-push.swift hosted with ❤ by GitHub

Full pre-push script for building, running, and printing code coverage.

If this was helpful, please let me know on Mastodon@toomasvahter or Twitter @toomasvahter. Feel free to subscribe to RSS feed. Thank you for reading.

Tags code coverage, git, hooks, pre-push, Swift, testing, unit-test, Xcode

CoreData iOS macOS Swift WidgetKit

Sharing data from CoreData storage with a Widget on iOS

Post author By Toomas Vahter
Post date August 16, 2020
No Comments on Sharing data from CoreData storage with a Widget on iOS

WWDC’20 introduced WidgetKit which is a new framework for building widgets on iOS, iPadOS, and macOS. Widgets provide a quick way for displaying content from your app either on the home screen on iOS or on the notification center on macOS. As I have an iOS app which stores data with CoreData then let’s see what it takes to share it with a widget. Note that we’ll only concentrate on sharing data between the app and the widget. For adding a widget to an existing project I would recommend taking a look at Apple’s excellent article: “Creating a Widget Extension”.

Configuring the project for sharing data with the widget

The project I have is an iOS app which keeps track of plants. Therefore, we’ll look into providing plants to a simple widget which just displays one of the plants which needs to be watered next. CoreData store contains all the plants with previous and next watering date. As widgets are meant to be lightweight extensions to your app we’ll aim at passing the minimum amount of data to the widget. WidgetKit does not provide a connectivity framework like WatchOS does because widgets are not running all the time. Therefore we will store data in a file and write the file to a shared container which the app and the widget can access. This can be done by adding app groups capability to both targets. The group name could be something like group.com.company.appname.widget. When this is set, then the url to a shared container can be created using FileManager like shown below.

	extension WidgetPlantProvider {
	static let sharedDataFileURL: URL = {
	let appGroupIdentifier = "group.com.company.appname.widget"
	if let url = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: appGroupIdentifier) {
	return url.appendingPathComponent("Plants.plist")
	}
	else {
	preconditionFailure("Expected a valid app group container")
	}
	}()
	}

view raw WidgetPlantProvider.swift hosted with ❤ by GitHub

Creating an URL for shared file.

Updating the shared file

The iOS app has a class named WidgetPlantProvider which is responsible of updating the shared file and letting WidgetKit know when the data has changed. This class uses NSPersistentContainer for accessing CoreData storage and fetches dictionary representations of Plant entities. As those dictionaries contain NSDate objects then we’ll need to convert dates to double values which represent dates as seconds from the year of 1970. This enables us to archive the list of dictionaries to a data object with NSKeyedArchiver and writing the data object into the shared container. Last step is letting WidgetKit to know that timelines should be reloaded because data has changed. The implementation of the class is available below including observing managed object save notification.

	final class WidgetPlantProvider {
	private var cancellables = [AnyCancellable]()
	private let plantContainer: PlantContainer // NSPersistentContainer subclass

	init(plantContainer: PlantContainer, notificationCenter: NotificationCenter = .default) {
	self.plantContainer = plantContainer

	let notificationCancellable = notificationCenter.publisher(for: .NSManagedObjectContextDidSave, object: plantContainer.viewContext).sink { [weak self] _ in
	self?.reloadData()
	}
	cancellables.append(notificationCancellable)
	}

	// Called when NSPersistentContainer is first loaded
	func reloadData() {
	plantContainer.performBackgroundTask { context in
	let descriptors = [NSSortDescriptor(keyPath: \Plant.nextWateringDate, ascending: true)]
	// fetchDictionaries is convenience method which creates and executes NSFetchRequest<NSDictionary> and sets resultType = .dictionaryResultType
	let dictionaries = Plant.fetchDictionaries(context, sortDescriptors: descriptors, fetchLimit: 3) as! [[String: Any]]

	// NSDate -> double conversion
	let converted = dictionaries.map { (plantDictionary) -> [String: Any] in
	return plantDictionary.mapValues { (value) -> Any in
	guard let date = value as? Date else { return value }
	return date.timeIntervalSince1970
	}
	}
	do {
	let needsFileReload: Bool = {
	guard let storedData = try? Data(contentsOf: Self.sharedDataFileURL) else { return true }
	guard let storedDictionaries = try? NSKeyedUnarchiver.unarchiveTopLevelObjectWithData(storedData) as? [NSDictionary] else { return true }
	return storedDictionaries != converted as [NSDictionary]
	}()
	if !needsFileReload {
	os_log(.debug, log: .widget, "Plants already up to date for widget")
	return
	}
	let data = try NSKeyedArchiver.archivedData(withRootObject: converted, requiringSecureCoding: true)
	try data.write(to: Self.sharedDataFileURL)
	os_log(.debug, log: .widget, "Reloading widget because plants changed")
	WidgetCenter.shared.reloadAllTimelines()
	}
	catch {
	os_log(.debug, log: .widget, "Failed updating plants for widget with error %s", error.localizedDescription)
	}
	}
	}
	}

view raw WidgetPlantProvider.swift hosted with ❤ by GitHub

WidgetPlantProvider which stores Plant entities as dictionaries in the shared file.

Reading the shared file in the widget

Reading the file in the widget requires us to create an URL pointing at the shared container, reading the data, and converting the data to a list of plants. As the data contains a list of dictionary objects then we can take advantage of JSONDecoder and convert dictionaries to PlantRepresentation value type. PlantRepresentation struct conforms to Codable protocol which enables converting dictionary object to a JSON data representation and then decoding the JSON data to a value type. Date properties are represented as seconds from the year of 1970, then JSONDecoder’s dateDecodingStrategy must be set to DateDecodingStrategy.secondsSince1970. This approach of converting dictionary to a value type is discussed in detail in “Storing struct in UserDefaults”. An example provider type with described approach is available below.

	struct Provider: TimelineProvider {
	// …

	func getTimeline(in context: Context, completion: @escaping (Timeline<Entry>) -> ()) {
	let plants = loadPlants()
	let entry = PlantEntry(date: Date(), plants: plants)
	let timeline = Timeline(entries: [entry], policy: .atEnd)
	completion(timeline)
	}

	private func loadPlants() -> [PlantRepresentation] {
	do {
	let data = try Data(contentsOf: Self.sharedDataFileURL)
	let plantDictionaries = try NSKeyedUnarchiver.unarchiveTopLevelObjectWithData(data) as? [[String: Any]]
	let decoder = JSONDecoder()
	decoder.dateDecodingStrategy = .secondsSince1970
	return plantDictionaries?.compactMap({ PlantRepresentation(dictionary: $0, decoder: decoder) }) ?? []
	}
	catch {
	print(error.localizedDescription)
	return []
	}
	}

	private static var sharedDataFileURL: URL {
	let identifier = "group.com.company.appname.widget"
	if let url = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: identifier) {
	return url.appendingPathComponent("Plants.plist")
	}
	else {
	preconditionFailure("Expected a valid app group container")
	}
	}
	}

	// DictionaryDecodable: https://augmentedcode.io/2019/05/12/storing-struct-in-userdefaults/
	struct PlantRepresentation: Identifiable, Decodable, DictionaryDecodable {
	let id: String
	let name: String
	let lastWateringDate: Date
	let nextWateringDate: Date
	}

	struct PlantEntry: TimelineEntry {
	let date: Date
	let plants: [PlantRepresentation]
	}

view raw Provider.swift hosted with ❤ by GitHub

Timeline provider for a Widget which reads the data from the shared file.

Summary

We went through the steps of setting up app groups and sharing data in CoreData store with a widget. Next steps would be to use the timeline and polishing the Widget’s appearance.

If this was helpful, please let me know on Mastodon@toomasvahter or Twitter @toomasvahter. Feel free to subscribe to RSS feed. Thank you for reading.

Tags CoreData, iOS, SwiftUI, TimelineProvider, Widget

iOS macOS Swift SwiftUI

@StateObject and MVVM in SwiftUI

Post author By Toomas Vahter
Post date August 2, 2020
3 Comments on @StateObject and MVVM in SwiftUI

A while ago I wrote about using MVVM in a SwiftUI project. During the WWDC’20 Apple announced @StateObject property wrapper which is a nice addition in the context of MVVM. @StateObject makes sure that only one instance is created per a view structure. This enables us to use @StateObject property wrappers for class type view models which eliminates the need of managing the view model’s lifecycle ourselves.

Comparing @StateObject and @ObservableObject for view model property

The most common flow in MVVM is creating and configuring a view model, which includes injecting dependencies, and then passing it into a view. This creates a question in SwiftUI: how to manage the lifecycle of the view model when view hierarchy renders and view structs are recreated. @StateObject property wrapper is going to solve this question in a nice and concise way. Let’s consider an example code.

	import SwiftUI

	struct ContentView: View {
	@EnvironmentObject var dependencyContainer: DependencyContainer
	@StateObject var viewModel = ContentViewModel()

	var body: some View {
	VStack(alignment: .center) {
	VStack(spacing: 32) {
	Text(viewModel.refreshTimestamp)
	Button(action: viewModel.refresh, label: {
	Text("Refresh")
	})
	}
	Spacer()
	BottomBarView(viewModel: BottomBarViewModel(entryStore: dependencyContainer.entryStore))
	}
	}
	}

view raw ContentView.swift hosted with ❤ by GitHub

ContentView which has a subview.

ContentView is a simple view which has a view model managing the view state and DependencyContainer used for injecting a dependency to the BottomBarViewModel when it is created. As we can see, ContentView’s view model is managed by @StateObject property wrapper. This means that ContentViewModel is created once although ContentView can be recreated several times. BottomBarView has a little bit more complex setup where the view model requires external dependency managed by the DependencyContainer. Therefore, we’ll need to create the view model with a dependency and then initialize BottomBarView with it. BottomBarView’s view model property is also annotated with @StateObject property wrapper.

	import Combine
	import SwiftUI

	struct BottomBarView: View {
	@StateObject var viewModel: BottomBarViewModel

	var body: some View {
	Text(viewModel.text)
	}
	}

	final class BottomBarViewModel: ObservableObject {
	@Published var text: String = ""

	private var cancellables = [AnyCancellable]()
	private let entryStore: EntryStore

	init(entryStore: EntryStore) {
	self.entryStore = entryStore
	print(self, #function)

	cancellables.append(Timer.publish(every: 2, on: .main, in: .default).autoconnect().sink { [weak self] (_) in
	self?.text = "Random number: \(Int.random(in: 0..<100))"
	})
	}
	}

view raw BottomBarView.swift hosted with ❤ by GitHub

BottomBarView and its view model.

Magical aspect here is that when the ContentView’s body is accessed multiple times then BottomBarViewModel is not recreated when the BottomBarView struct is initialized. Exactly what we need – view will manage the lifecycle of its view model. This can be verified by adding a print to view model initializers and logging when ContentView’s body is accessed. Here is example log which compares BottomBarView’s view model property when it is annotated with @StateObject or @ObservableObject. Note how view model is not created multiple times when BottomBarView uses @StateObject.

BottomBarView uses @StateObject for its view model property
SwiftUIStateObject.ContentViewModel init()
1 ContentView.body accessed
SwiftUIStateObject.BottomBarViewModel init(entryStore:)
Triggering ContentView refresh
2 ContentView.body accessed
Triggering ContentView refresh
3 ContentView.body accessed

BottomBarView uses @ObservableObject for its view model property
SwiftUIStateObject.ContentViewModel init()
1 ContentView.body accessed
SwiftUIStateObject.BottomBarViewModel init(entryStore:)
Triggering ContentView refresh
2 ContentView.body accessed
SwiftUIStateObject.BottomBarViewModel init(entryStore:)
Triggering ContentView refresh
3 ContentView.body accessed
SwiftUIStateObject.BottomBarViewModel init(entryStore:)

Summary

WWDC’20 brought us @StateObject which simplifies handling view model’s lifecycle in apps using MVVM design pattern.

If you are looking more information about the MVVM design pattern then please check: MVVM in SwiftUI and MVVM and @dynamicMemberLookup in Swift.

If this was helpful, please let me know on Mastodon@toomasvahter or Twitter @toomasvahter. Feel free to subscribe to RSS feed. Thank you for reading.

Example

SwiftUIStateObject (GitHub) Xcode 12.0 beta 3