DEV Community: Maarek

Deploy your smart contracts on any Ethereum network

Maarek — Mon, 03 Jan 2022 23:59:02 +0000

So you finally wrote your smart contract, it works fine, you’ve tested it locally, maybe wrote a cool wep app that goes along with it and want to deploy it live? I got you covered.

In this article, we will se how to use Truffle to deploy any contract on a test network or the main Ethereum network.

Choosing a network

First let’s enumerate our network options. Ethereum has a few public test network that we can work on, you can find their name and their specificity on the official Ethereum webiste.
We could also work on the Polygon network which is a Layer 2 network.

Setup a wallet

Once you’ve decided where to deploy, we need to have a wallet on that network with some funds on it. Deploying a contract, like any other operation on the Ethereum blockchain isn’t free. If we are working on a public test network, you can create a wallet and claim some free Ether on it with faucets. I would suggest to use a new wallet that you’ll use only for contract deployment.

Infura: your way to the blockchain

For the next steps, we will work with Infura. Infura provides a suite of tools for developers to work on the Ethereum blockchain.

It allows you to develop anything on the Ethereum network without having to host or setup any of the complexity that working with a large blockchain come with, hosting Ethereum nodes. Essentially Infura is a Blockchain nodes provider.

To create a infura project, go on the Infura website, create an account. Once done, login and go to your dashboard. There you have the option to create a new project. Select Ethereum in the product option and give it a name (you can change the name latter if you want). Infura will generate an API key and a project secret Key. The API key will be required for the next steps.

Configure Truffle for your network

First of all, we need a wallet provider. As told before, you need a wallet with a few Ether (or MATIC if you work with the Polygon network) to deploy a contract.

We will use hdwallet-provider that does the job well enough.

In a Terminal on the root of your project type:

npm install --save truffle-hdwallet-provider

For the next step, I’ll assume you’ve setup your project with the command truffle init, which implies that you have, on your project’s root, a file named truffle-config.js. That is the file we will work on.

Before the module.export statement, import the freshly installed wallet provider :

const HDWalletProvider = require('truffle-hdwallet-provider');

For now, every time you’ve deployed your contracts, truffle automatically went for the development environment, and has used your local blockchain (probably run with Ganache). We need to add a new network. For now, your file should look like this :

module.exports = {
  networks: {
    development: {
        host: "127.0.0.1",
        port: 7545,
        network_id: "*",
    },
    },
    mocha: {
    timeout: 100000
  },
  compilers: {
    solc: {
      version: "0.8.11"
    }
  },
  db: {
    enabled: false
  }
};

As you would guess, we will add the network we want to deploy to in the networks object, after development. For the rest of the post, I will work with the Ropsten network.

So I will add the following under networks:

ropsten: {
    provider: function() {
      return new HDWalletProvider("YOUR_WALLET_MNEMONIC", "https://ropsten.infura.io/YOUR_API_KEY")
    },
    network_id: 3,
    gas: 4000000      //make sure this gas allocation isn't over 4M, which is the max
}

If you are deploying on the main network, name the network “main” instead of “ropsten”, the network id should be 1. For the gas price, you should be able to get an idea of reasonable price checking out the Ether Gas Station.

Obviously, replace the mnemonic and the infura URL with the one that goes with the network you are deploying to followed by your project’s API key. You can get the URL from your Infura project setting, there should be a dropdown menu with all the supported networks, just select one and copy past the URL.

⚠️ Do not commit your mnemonic ⚠️

Make sure it’s stored in a .env file, or something that is in the .gitignore file.

You could put your mnemonic on a .secret file, that is listed in the .gitignore and access like :

const fs = require('fs');
const mnemonic = fs.readFileSync(".secret").toString().trim();

Then you would be good to go! Just run the following :

truffle deploy --network <network name>

Here I would replace <network name> by ropsten.

Happy deployments 🙂

Testing your smart contract with Truffle

Maarek — Fri, 31 Dec 2021 09:48:10 +0000

As you might know testing is very important, especially when working with smart contract and blockchain, as anything in the blockchain is immutable. There is ways to make upgrades to a contract but we’ll get to that in another post.

For this article, I’ll be working with the fundraiser contract I wrote in my last post. Here is the full code:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract Fundraiser {
    address public owner;
    address[] public backers;

    constructor() {
        owner = msg.sender;
    }

    function sendMoney() public payable {
        require(msg.value > 0, "No Ether were sent.");
        backers.push(msg.sender);
    }

    function getBalance() public view returns (uint256) {
        return address(this).balance;
    }

    function endFundraising() public {
        require(msg.sender == owner, "Only the owner is allowed to end the fundraising.");
        payable(owner).transfer(address(this).balance);
    }
}

And I’m assuming you’ve used truffle init to setup your project, meaning, you have a test directory in your workspace. This directory should be empty by now.

Creating a test file

We’ll start by creating a new file called fundraiser.js. We are going to write our test in Javascript. If you are familiar with it, Truffle uses the Mocha testing framework, with a few differences, it uses contract() instead of describe().

That contract method is just used to logically group the tests by contract. Before executing your tests, the function make sure the contract is redeployed to the running environment.

Here, I’m assuming you have Ganache installed and running.

So in this empty JavaScript file, we will first get our compiled contract and call the contract method to start writing test cases:

const Fundraiser = artifacts.require("./Fundraiser.sol");

contract("Fundraiser", (accounts) => {

});

The contract method has two parameter, the first one would be the name of the contract and the second one is a function that gives you a parameter with a list of account that your environment provided for testing. That’s in that function that we will describe out test cases with Mocha’s it function.

Just like contract, two parameters, a description of the test and the actual test.
We can describe as many tests as we need.

const Fundraiser = artifacts.require("./Fundraiser.sol");

contract("Fundraiser", (accounts) => {
    it("some test", async () => {
        // ...
    });
    it("some other test", async () => {
        // ...
    });
});

Interacting with our contract

While testing a contract you will need to interact with it. The first thing you would want is to access an instance. From the artifact, you can call the .deployed().

const contract = await Fundraiser.deployed();

To access a public variable from your contract, we will use the call() function.

const owner = await contract.owner.call();

Finally, to call a public function just call the function like you would to on any object.

let balance = await contract.getBalance();

To add a value or specify the caller’s address, add an optional object :

await contract.sendMoney({from: '0x0...', value: 1});

Note: value is in Gwei (1 Gwei = 0,00000001 Ether), to send Ether, just multiply the value by 10 to the power of 18 (10**18 in JavaScript).
You can also the gas and some data as parameter. More on the Truffle documentation.

Now you should have anything needed to test our contract.

Writing some tests

The first one will verify if the backers array get properly populated after a backer would have sent some Ether.

    it("check the participants array after participation", async () => {
        // Get the first account
        let account = accounts[0];
        // Retreive the deployed contract
        const contract = await Fundraiser.deployed();
        // Make the account send 14 gwei
        await contract.sendMoney({from: account, value: 14});
        // Get the particpant at index 0
        let backer = await contract.backers.call(0);
        // Check if that participant is the same as the addess we used
        assert.equal(backer, account);
    });

We will write another test to check the balance increase.

    it("check the balance increase", async () => {
        // Get the first account
        let account = accounts[0];
        // Retreive the deployed contract
        const contract = await Fundraiser.deployed();
        // Get the balance before the operation
        let balanceBefore = await contract.getBalance();
        // Send 1 gwei
        await contract.sendMoney({from: account, value: 1});
        // Get the balance after the gwei was sent
        let balanceAfter = await contract.getBalance();
        // Check if the balance after is equal to the balance before plus 1
        assert.equal(balanceAfter.toString(), parseInt(balanceBefore.toString())+1);
    });

One last test to check the end of the fundraising.

    it("check the balance after the fundraising ends", async () => {
        // Retreive the deployed contract
        const contract = await Fundraiser.deployed();
        // Get the contract owner by accessing the owner attribute
        const contractOwner = contract.owner.call();
        let contractsBalanceBefore = await contract.getBalance();
        let ownersBalanceBefore = await web3.eth.getBalance(contractOwner);
        // End the fund raising
        await contract.endFundraising({from: contractOwner});
        let contractsBalanceAfter = await contract.getBalance();
        let ownersBalanceAfter = await web3.eth.getBalance(contractOwner);
        // Check if the contract balance is now zero
        assert.equal(contractsBalanceAfter, 0);
        // Check if the owner account received the contract's balance
        assert.equal(ownersBalanceBefore >= ownersBalanceAfter+contractsBalanceBefore, true);
    });

Looks like we now have a decent code coverage for our contract.

We can just run the tests with the command truffle test.

Dont hesitate to check out the amazing documentation from the truffle website. You can also check the Mocha documentation.

Feel free to comment if you have any question, or contact me via Twitter.

Happy coding!

Write your first smart contract in Solidity

Maarek — Thu, 30 Dec 2021 23:55:03 +0000

Few month ago, I started my journey on Ethereum development. I discovered an amazing and very promising ecosystem that is placing the foundation stones of the futur of the internet as we know it.

So today, I decided to write a series of article to get started in this environment that may sound very obscure to a lot of people right now.

Before we start...

In this article I will cover how to setup a development environment to start working with the Solidity programming language and write a smart contract, then deploy it on a local network. I will assume you know the basics of programming (eg: variables, functions, control flows and loops, class...).

Installing everything you need:

Firstly, you need to get a NodeJS environment set up. If you don’t already have that, you can download NodeJS from the official website or use your favorite package manager.

Now we can install Truffle, an open source tool suite that will allow you to develop, test and deploy your contract.
Use npm install -g truffle and you’re all set.

Then, download Ganache from the Truffle website. This tool will allow you to setup a personal Ethereum blockchain that you can use to run and test your contract.

Finally, you can fire up any IDE, time to code. I would recommend VSCode with the Solidity plugin.

Time to code!

Alright, the first thing to do once you’ve downloaded everything is to init a project. To do so, create a new directory and let truffle do his thing:

mkdir fundraiser-contract
cd fundraiser-contract
truffle init

Directory and files will be created :

├── contracts
│   └── Migrations.sol
├── migrations
│   └── 1_initial_migration.js
├── test
└── truffle-config.js

We’ll quickly go over these files :

contracts/ will contains your solidity sources. It already have a contract in it, called Migration (.sol is the solidity extension). This contract keeps track of migrations and deployment in the network you’re working on.
migrations/ contains your smart contracts deployments logic.
test/ as you can guess is here for your testing environment.

Good, we’re all set. Now we’re going to create a new contract. Let’s work on a simple fundraiser contract.

So let’s start by creating a new solidity file, say Fundraiser.sol in the contract directory. Then we’ll add a license, a version directive and create a contract:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract Fundraiser {

}

Specifying a license is mandatory in solidity. The pragma statement is used to tell the compiler which Solidity version it should use.

This contract will have few things :

The owner’s address, which deployed the contract & the one who will get the money collected by the contract.
An array of the backers, so the owner can personally thank them.

So we will add these as attributes like you would on a regular class:

contract Fundraiser {
    address public owner;
    address[] public backers;
}

In this example, I’ll set all the variables’ access to public.

To get the owner’s address we will just implement the contract’s constructor and get his address from here. In solidity there is a few global variable that you can access. Here we will use msg, which contains the address of the one who calls the functions: msg.sender.

Our constructor would look like :

constructor() {
    owner = msg.sender;
}

Now we need a function accessible to anyone to send some Ether to this contract. We’ll call it sendMoney cause that’s what it actually does.

function sendMoney() public payable {
    require(msg.value > 0, "No Ether were sent.");
    backers.push(msg.sender);
}

The first statement is a require call. He's here to check if the condition given as its first argument is true, otherwise, the function will stop its execution and the transaction will be reverted with the error message passed as second argument. Here we want to make sure the caller actually sent some Ether: we check if the function caller attached a value: msg.value.

Note that the function is marked public and payable so anyone can call it, and send Ether.

Then, we just add the sender’s address to the backers list.

Next we want to let the owner get it’s freshly raised money. So let’s make a function called endFundraising that will collect the money.

function endFundraising() public {
    require(msg.sender == owner, "Only the owner is allowed to end the fundraising.");
    payable(owner).transfer(address(this).balance);
}

That function will be public but we are going to make sure that the caller (msg.sender) is the owner with a require statement.
Then, we can just transfer its funds to the owner with the Solidity transfer method.

Just for fun, I’ll also add a get balance function:

function getBalance() public view returns (uint256) {
    return address(this).balance;
}

Every contract has a balance and can hold funds.

And we’re done! You just wrote your first contract 😎.

Here is the full code :

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract Fundraiser {
    address public owner;
    address[] public backers;

    constructor() {
        owner = msg.sender;
    }

    function sendMoney() public payable {
        require(msg.value > 0, "No Ether were sent.");
        backers.push(msg.sender);
    }

    function getBalance() public view returns (uint256) {
        return address(this).balance;
    }

    function endFundraising() public {
        require(msg.sender == owner, "Only the owner is allowed to end the fundraising.");
        payable(owner).transfer(address(this).balance);
    }
}

As you can see, this contract is quite simple, and I bet you can see a lot of evolutions, such as locking the fundraising once the funds has been transferred, also, wouldn’t it be nice to have a cool web app that would allow any user to send the funds?

Let’s deploy!

Ok, so the contract should work right? The next step would be to deploy it on your personal network.

And, hey, I can ear you: “Woow!! Are we about to deploy this? Shouldn’t we write tests before and make sure it passes all? What kind of developer is this guy!”...
And you are right. But I keep the testing part for another post. This one is getting quite long already - don’t be mad.

Earlier, you installed Ganache. Launch it, click on Quickstart, it will automatically start and setup an Ethereum blockchain on your local network and give you 10 accounts loaded with 100 fake Ether to play with it. Once started, we can prepare our deployment.

Remember that migration directory? Create a new JavaScript file called 2_deploy_contracts.js.

In this file we will write the deployment/migration code for our contract. It’s pretty standard, you can just copy past it:

var Fundraiser = artifacts.require("./Fundraiser.sol");

module.exports = function(deployer) {
    deployer.deploy(Fundraiser);
};

Now you’re really done. You would just need to type the command truffle migrate, in you terminal (make sure you’re in your project’s root).

Now what? Testing time! Deployment? And, wouldn’t it be nice to test it with a small web app? Yup, that’s what’s next!

Don’t hesitate to comment or contact me via Twitter if you have any question.

Happy coding!

Create your own command line tools in Swift

Maarek — Tue, 15 Dec 2020 17:25:31 +0000

Swift is certainly a great programming language for developing apps made for the Apple ecosystem. But as you know, Swift, as a language, is not Apple specific. You can use Swift in many other areas such as backend (with Vapor). Swift runs on Linux and Windows too.
Today I would like to present a quick "Getting started" post about how to make your own command line tools with Swift.

As a developer there is many tasks that I'm sure you have already made your own tools for, to automate them.
Cropping images, scrapping stuff from the internet, generating all kind of files or config stuff... You name it.
Today I'll try to demonstrate how to create your own tool using Swift, the Swift package manager, and the argument parser.

Building a command line tool using the Swift Package Manager

I find very useful to have an image comparison tool on my computer. I have a lot of UITests on my apps and while the tests are running, they automatically take screenshots of the screen. There are many use-cases such as upload them to iTunes Connect, but I also use it to compare screens over time and over versions of my apps. If I see any unexpected difference between my "Base" screenshots and the one taken while testing, I know something is wrong with my UI.

So today we'll be building an image comparison command line tool

Let's start by creating the project :

$ mkdir img_cmp
$ cd img_cmp
$ swift package init --type executable

Nothing crazy here; I create an img_cmp directory for my project and initilize the project.
A folder structure hase been created for me :

Creating executable package: img_cmp
Creating Package.swift
Creating README.md
Creating .gitignore
Creating Sources/
Creating Sources/img_cmp/main.swift
Creating Tests/
Creating Tests/LinuxMain.swift
Creating Tests/img_cmpTests/
Creating Tests/img_cmpTests/img_cmpTests.swift
Creating Tests/img_cmpTests/XCTestManifests.swift

Awesome, now you can build and run the project with command line :

swift build
swift run

If you're on a macOS machine and have XCode installed, you can double click on Packaged.swift, it will open the project.
Otherwise you can simply open Sources/img_cmp/main.swift in you favorite text editor.

Now we are going to import the Argument Parser. This is a Swift package made by Apple to get simple user input via arguments while running the program.

In your Package.swift file, you will add the dependancy as follow :

let package = Package(
    name: "img_cmp",
    dependencies: [
        .package(url: "https://github.com/apple/swift-argument-parser", from: "0.3.0"),
    ],
    targets: [
        .target(
            name: "img_cmp",
            dependencies: [
                .product(name: "ArgumentParser", package: "swift-argument-parser"),
            ]),
        .testTarget(
            name: "img_cmpTests",
            dependencies: ["img_cmp"]),
    ]
)

Now you have added the Argument Parser framework. If you are on XCode, it will automatically update the dependancy package and resolve the dependancy versions.

In the main.swift, we can now import the framework :

import ArgumentParser

Creating the program

We need to start by creating a parsable command. Nothing simpler: make a struct that conforms to ParsableCommand, a protocol defined in the Argument Parser framework.
Here I'll call it ImgCmp.
After that, we'll call the static main function, that will take care of running the program for me.

struct ImgCmp: ParsableCommand {

}
ImgCmp.main()

Great, now to make our program do something, I will implement the function run in our struct (also defined in the protocol ParsableCommand). This will be the method used to execute the command.

struct ImgCmp: ParsableCommand {
    func run() throws { }
}
ImgCmp.main()

Notice this command can throw error, so the OS can catch the exit status of your program.

Get all the arguments !

Alright now we want the user to input two images to compare one to another. So we'll need (at least) 2 arguments.
The ArgumentParser let use input 3 type of arguments :

Arguments
That's a required input needed for the program to run.
Options
An option is an extra value that the user can input for a specific behaviour.
Flag
A Flag is a simple option that the user can add or not.

Example :

nano -L /path/to/file --tabsize=1

Here we use the command nano which is used to edit a file.
-L is a flag (Don't add newlines to the ends of files).
/path/to/file is an argument (The file to edit).
--tabsize=1 is an option (Set the size (width) of a tab to cols columns).

To parse argument, the framework makes everything for us.
It's based on property wrappers - that you might have used with SwiftUI and it's pretty simple :
Every argument is an attribute of the struct (here ImgCmp) and the propery wrapper takes parameters to define and specify the argument.
Let's start with our two main arguments :

@Argument(help: "The reference image.")
var base: String

@Argument(help: "The image to compare.")
var image: String

Now if you run the command without two arguments it should say:

$ img_cmp swift run img_cmp
Error: Missing expected argument '<base>'

USAGE: img-cmp <base> <image>

ARGUMENTS:
  <base>                  The reference image. 
  <image>                 The image to compare. 

OPTIONS:
  -h, --help              Show help information.

But add some strings and you're good :

$ img_cmp swift run img_cmp /Users/me/Desktop/a.png /Users/me/Desktop/b.png

Now for me, this is not enough. I want the user to be able to specify a tolerance for comparing. Say if A is 99% B, it's okay for me.
For that we'll add an option

@Option(name: [.customLong("tolerance"), .customShort("t")], help: "The tolerance to consider an image identical as a value from 0 to 1.\n 0 is strictly identical.")
    var tolerence: Float?

With the Option property wrapper, you can specify a long and a short name (here "tolerance" and "t").
Now we can use execute :

$ img_cmp swift run img_cmp /Users/me/Desktop/a.png /Users/me/Desktop/b.png -t 0.01

Let's also add a verbose flag. If the user would like to display more information and non blocking messages. A basic "-v" will work for me.

@Flag(name: [.customLong("verbose"), .customShort("v")], help: "Show logs, information and non blocking messages.")
var verbose = false

Back the to run function : to exit a program, just throw an ExitCode (.success, .failure...). Just add an exit statement to the function : throw ExitCode.success

There you go!

Now I wont (unless you ask for it in the comment) write about the program's body because it's kind of out of subject (and in real life, you would probably use imagemagick ^^), but here how your code should look like so far:

import ArgumentParser

struct ImgCmp: ParsableCommand {

    @Argument(help: "The reference image.")
    var base: String

    @Argument(help: "The image to compare.")
    var image: String

    @Flag(name: [.customLong("verbose"), .customShort("v")], help: "Show logs, information and non blocking messages.")
    var verbose = false

    @Option(name: [.customLong("tolerance"), .customShort("t")], help: "The tolerance to consider an image identical, as a value from 0 to 1.\n 0 is stricly identical.")
    var tolerance: Float?

    func run() throws {
        // here you would compare the images, log stuff and return the right status code.
        throw ExitCode.success
    }
}

ImgCmp.main()

I hope you enjoyed this simple post. Don't hestitate to ask any question in the comment section, I'll be glad to help :).

Happy coding!

View Controller containment in Swift

Maarek — Sat, 14 Nov 2020 17:56:56 +0000

Containment of view controllers is an often used technique in UIKit.
It allows to drastically reduce the complexity of a view controller, very easily, simply by splitting it into multiple smaller ones.
Having smaller view controllers, with a reduced functional scope, makes testing easier, so as reusability across your codebase.

Pratical example

Let’s say you have a video player in your app. The first third of the screen would be used for the actual video player, with the controls and everything (play/pause, time indicator), and the rest of the screen would display the playlist. A very common layout - the exact one you would find on the YouTube app.

I would be very suitable to split this PlayerViewController into :

VideoPlayerViewController
PlaylistViewController

The two smaller view controller would have simple interfaces like delegates :

    func playerDidEndPlaying(player: Player, media: Media)
    func playlistDidSelect(playlist: Playlist, media: Media)

Allowing you to build a “main” view controller that would implement these methods and be used as data source for your two child view controller.
The best part is if you wish you swap the playlist for a comment section - say, after a user action, you would just replace the Playlist child view controller by a CommentViewController.

You would then be able to test independently the comment, player and playlists view controllers.
As you can see, view controller containment is great for reusability, a better code organization, reducing complexity and better testing.

Here is a very helpful extension to add and remove a child view controller.

extension UIViewController {
    /// Add a child UIViewController to a given UIView. If `view` is set to nil or not set, it will add the child the ViewController's view.
    /// - Parameters:
    ///   - child: Child view controller as a UIViewController
    ///   - view: Target UIVew that will contain the child
    func add(_ child: UIViewController, view: UIView? = nil) {
        let view: UIView = view ?? self.view
        addChild(child)
        child.view.translatesAutoresizingMaskIntoConstraints = false
        view.addSubview(child.view)
        NSLayoutConstraint.activate([
            child.view.topAnchor.constraint(equalTo: view.topAnchor),
            child.view.bottomAnchor.constraint(equalTo: view.bottomAnchor),
            child.view.leftAnchor.constraint(equalTo: view.leftAnchor),
            child.view.rightAnchor.constraint(equalTo: view.rightAnchor),
        ])
        child.didMove(toParent: self)
    }


    /// Remove a child viewController from it's container
    func remove() {
        guard parent != nil else {
            return
        }
        willMove(toParent: nil)
        view.removeFromSuperview()
        removeFromParent()
    }
}

A simple use-case based on the given example with a PlayerViewController would render as follow :

class PlayerViewController: UIViewController {
    let player = VideoPlayerViewController()
    let playlist = PlaylistViewController()
    let comment = CommentViewController()

    let playerViewContainer = UIView()
    let bottomViewContainer = UIView()

    override func viewDidLoad() {
        super.viewDidLoad()
        self.add(self.player, view: self.playerViewContainer)
        self.add(self.playlist, view: self.bottomViewContainer)
    }

    func showComment() {
        self.playlist.remove()
        self.add(self.comment, view: self.bottomViewContainer)
    }
}

As you can see, it is very simple and makes the "main" view controller clean, and free from player, playlist or comment related business logic!
Aside of the reusability and cleanness of view controllers containment, the main benefit is that the child view controllers can interact with the parent's life cycle (didLoad, didAppear...).

I hope you enjoyed this little post. I like sharing about my way of coding, if you have any question, feel free to hit me on Twitter or use the comment section :)

Happy coding!

Dependency Inversion Principle in Swift

Maarek — Thu, 12 Nov 2020 10:30:44 +0000

You may have heard about the Dependency Inversion principle from the OOP’s SOLID design guidelines.
The idea behind this principle is that an implementation should only be dependant of interfaces and abstractions - never of another implementation.
It also brings us the concept that a higher level module should never be dependant of a lower level module.

Protocol to the rescue

In Swift, with protocols, you can get rid of any implementation dependency and instead rely on the implementation of a protocol.

Real life example

Let say you have a network stack :

class AppServices {
    // AppServices will keep an instance of network and any other lower stack
    // that must have a shared instance. Eg: Persistence.
    static let network: AppNetwork = AppNetwork()
}

class AppNetwork {
    // This class is in charge of auth, holds the token and requests queue
    func fetch(_ operation: NetworkOperation, completion: NetworkCompletion)
}

And a controller that requests a list of data from an API, using the network stack :

class ViewController: UIViewController {
    func loadData() {
        AppServices.network.fetch(ListData) {
            self.view.refresh(listData)
        }
    }
}

The Network stack is a low level module, and the ViewController is tightly coupled with AppNetwork’s implementation throughout AppServices.

We can solve this dependency issue by recreating the Network as a protocol :

protocol Network {
    func fetch(_ operation: NetworkOperation, completion: NetworkCompletion) {}
}

and make the AppNetwork conforms to Network :

class AppServices {
    static let network: Network = AppNetwork()
}

class AppNetwork: Network { … }

Now, AppServices wont hold a AppNetwork implementation but an abstract implementation of Network.
Another benefit of this is you can easily mock your networks stack, simply by replacing the implementation of Network.

class MockedNetwork: Network {
    func fetch(_ operation: NetworkOperation, completion: NetworkCompletion) {
        completion(stubResult, fakeError)
    }
}

// make sure you set the static as a `var` and not a `let`
AppService.network = MockedNetwork()

Following this principle in this specific scenario is a very nice and clean way to improve the testability of any network dependant code, the flexibility and the scalability of your network stack, and you can remove any coupling of your app's controllers or view to your app's lower stacks.

I hope you enjoy this little post.
I chose to cover the dependency inversion principle as I feel it is a very useful and important principle to follow while coding and a great way to improve code and product's quality. I would be happy to answer any question in the comment section or feel free to reach via my Twitter ;)

Happy coding!

Add iPad OS multiple windows support

Maarek — Mon, 28 Oct 2019 14:28:01 +0000

iPad OS 13 introduces the support of multi windows. You can now have multiple “instances” or copies of the same app through separated windows.

The implementation of such a feature requires some re-work of the current app life cycle.

The first step is to add a SceneDelegate to your app. If you don't know how to, I suggest my previous post about it.

Now, understand that a window, in iOS, is a scene and as Apple's documentation says :

A scene contains the windows and view controllers for presenting one instance of your UI. Each scene also has a corresponding UIWindowSceneDelegate object, which you use to coordinate interactions between UIKit and your app.

So how it's going to work will be pretty basic :

The user will drag and drop an item to create a new window of your app.
The system will instantiate a new Scene, requesting a scene to connect to your app's session.
The app's SceneDelegate will be notified that a scene has been requested to connect to it's session. It will evaluate what kind of scene is requested by it's connection options, and will present the correct view controller.

Therefore, all of your presentation logic will gravitate around your SceneDelegate's sceneWillConnectToSession function.

You will get the connection options object (of type ConnectionOptions) in parameter of the sceneWillConnectToSession function.
It's prototype looks like this :

    open class ConnectionOptions : NSObject {
        open var urlContexts: Set<UIOpenURLContext> { get }
        open var sourceApplication: String? { get }
        open var handoffUserActivityType: String? { get }
        open var userActivities: Set<NSUserActivity> { get }
        open var notificationResponse: UNNotificationResponse? { get }
        open var shortcutItem: UIApplicationShortcutItem? { get }
        open var cloudKitShareMetadata: CKShareMetadata? { get }
    }

The property that we will work with is the userActivities.
This is how we will differentiate our Scenes.
So we need to set our different activites types.

In your project's info.plist, add a new array called NSUserActivityTypes in which you will create every type of window you will want to be presentable with a string identifier.

To illustrate this article I will make a restaurants list app.
In this app, there is only one window type I will need : the one for a restaurant detail page, displaying the info, address, and reviews of a restaurant.

So I will create one type "restaurant". This is what I have.

    <key>NSUserActivityTypes</key>
    <array>
        <string>restaurant</string>
    </array>

Now to make it easier to work with activity types in the code I will create an enum (of strings) with every activity type specified.

enum ActivityType: String {
    case restaurant
}

Now all I have to do in my SceneDelegate, is go in the SceneWillConnectToSession method and distinguish the requested scene and present the right ViewController.

Here is how to do this :

    func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
        guard let _ = (scene as? UIWindowScene) else { return }
        if let userActivity = connectionOptions.userActivities.first ?? session.stateRestorationActivity {
            // User request new window with userActivity
            switch MyActivityType(rawValue: userActivity.activityType) {
            case .restaurant:
                // Present the restaurant view controller
            case .none:
                // Present the hone view controller
            }
        } else {
            // This is an initial app launch
            self.present(viewController: ViewController(), scene: scene)
            // You don't need an else case if you have a main storyboard
        }
    }

To present a ViewController from here, if you are using a main storyboard, the window property will automatically be loaded with the storyboard's initial view controller.
So you just need to check if the rootViewController is present (and is a NavigationController) and then push your ViewController on it, like this :

if let navigationController = window?.rootViewController as? UINavigationController {
    navigationController.pushViewController(yourViewController, animated: false)
}

If you are not using a main storyboard, you need initialize the window and set the root, like this :

if let windowScene = scene as? UIWindowScene {
    self.window = UIWindow(windowScene: windowScene)
    let mainNavigationController = UINavigationController(rootViewController: yourViewController)
    self.window!.rootViewController = mainNavigationController
    self.window!.makeKeyAndVisible()
}

🥳 Now your app can open windows ! 🎉

Requesting new windows from the code

Having a "Open in a new window" button right in your view could be interesting in some cases.
To request a new window, you just need to request a scene session, with the activity you want.

If you want a new "restaurant" window :

let activity: NSUserActivity = NSUserActivity(activityType: ActivityType.restaurant.rawValue)
UIApplication.shared.requestSceneSessionActivation(nil, userActivity: activity, options: nil, errorHandler: nil)

You can use userInfo dictionary to pass more data such as an id.

And that's it : a new window will automatically be opened.

Enabling drag and drop from a Table/Collection view to open your detail view controller in a new window

Let’s say you have a TableView (or a CollectionView) of items which, on tap, will push some kind of detail ViewController, a pretty useful scenario.
In your CollectionView or TableView, you need to set a dragDelegate, and conform to the method itemForBeginningSessionAtIndexPath and return a DragItem containing the requested UserActivty.

Here is an example :

    func collectionView(_ collectionView: UICollectionView, itemsForBeginning session: UIDragSession, at indexPath: IndexPath) -> [UIDragItem] {
        // Create a userActivity with the activity type you want
        let userActivity = NSUserActivity(activityType: ActivityType.restaurant.rawValue)
        // You can use userInfo dictionary to pass more data such as an id.
        userActivity.userInfo!["id"] = self.data[indexPath.row].id()

        // Create an item provider with our activity
        let itemProvider = NSItemProvider()
        itemProvider.registerObject(userActivity, visibility: .all)

        // Create a drag item containing the itemProvider and return it in an array
        let dragItem = UIDragItem(itemProvider: itemProvider)
        return [dragItem]
    }

Now you can just drag any of you collection/table view cells to open windows.

Hope you enjoyed this multiple windows on iPad OS overview.
A sample app, with a restaurant list is available on my GitHub.

I will be glad to try to help if you have any question or issues.

Happy coding ! 😊

Add a Scene Delegate to your current project

Maarek — Mon, 28 Oct 2019 14:26:58 +0000

With iOS 13's introduced UIWindowScene and multiple window support for iPad OS, you might be looking to add Scene Delegate to your existing app (if you are willing to add support of multi window support, for example 😉).

Before iOS 13, the main entry point for your app was the AppDelegate, and it was in charge of many logic and state handling. Now the work of the AppDelegate has been split, between the AppDelegate and the SceneDelegate.

The AppDelegate being only responsible for the initial app setup, the SceneDelegate will handle and manage the way your app is shown.
As an app could have multiple instances, a SceneDelegate will be called every time an instance of your app is created.

To add a scene delegate, first, create a new Swift file that you’ll call "SceneDelegate" containing a subclass of UIResponder, just like the AppDelegate, and that conforms to UIWindowSceneDelegate. As your app might supports other versions than iOS 13, make this class only available for iOS 13.

This is what you should have :



//
//  SceneDelegate.swift
//
import UIKit

@available(iOS 13.0, *)
class SceneDelegate: UIResponder, UIWindowSceneDelegate {
    // ...
}

To this class, add a UIWindow property. That will be your main window, you will need it to present your View Controllers.



var window: UIWindow?

Finally, you need to implement the SceneWillConnectToSession method in your class.
This method is the way that notifies us about the addition of a scene to the app, a scene could be seen as a window.



    func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {

    }

If you are working a project that is storyboard based,

you could leave this method empty.
That means that you have a UIMainStoryboardFile specified in your info.plist with a ViewController set as initial (with an arrow on it's side).

If you are not working with a main storyboard,

you should have your view hierarchy set in you AppDelegate's applicationDidFinishLaunchingWithOptions method. Then you want to add the same code in your SceneWillConnectToSession function, and instead of working with a UIWindow, it's a UIWindowScene that will host your root.
You will also want to wrap your AppDelegates code into an #available check to make sur it wont be executed if your SceneDelegate does it.

So this is what you should have in your AppDelegate :
(ViewController being your app's "Home"/"Main")



    // AppDelegate

    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
        if #available(iOS 13.0, *) { } else {
            self.window = UIWindow(frame: UIScreen.main.bounds)
            let mainViewController = ViewController()
            let mainNavigationController = UINavigationController(rootViewController: mainViewController)
            self.window!.rootViewController = mainNavigationController
            self.window!.makeKeyAndVisible()
        }
        return true
    }

And in your SceneDelegate :



    // SceneDelegate

    func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
        guard let _ = (scene as? UIWindowScene) else { return }
        if let windowScene = scene as? UIWindowScene {
            self.window = UIWindow(windowScene: windowScene)
            let mainNavigationController = UINavigationController(rootViewController: viewController)
            self.window!.rootViewController = mainNavigationController
            self.window!.makeKeyAndVisible()
        }
    }

Finally, to make your app to use this Scene Delegate, you need to configure it as your main scene delegate. Just go in your info.plist file and add these lines :



<key>UIApplicationSceneManifest</key>
    <dict>
        <key>UIApplicationSupportsMultipleScenes</key>
        <true/>
        <key>UISceneConfigurations</key>
        <dict>
            <key>UIWindowSceneSessionRoleApplication</key>
            <array>
                <dict>
                    <key>UISceneConfigurationName</key>
                    <string>Default Configuration</string>
                    <key>UISceneDelegateClassName</key>
                    <string>$(PRODUCT_MODULE_NAME).SceneDelegate</string>

                    <!-- ONLY IF YOU HAVE A MAIN STORYBOARD -->
                    <key>Storyboard Name</key>
                    <string>Main</string>
                </dict>
            </array>
        </dict>
    </dict>

We make a SceneManifest in which we declare our SceneDelegate as being the default configuration for a scene.

⚠️ If you have a Main storyboard don't forget to specify it in the Storyboard Name field. If you don't, just remove the lines.

And there you are!
Now, if you execute your app on iOS/iPad OS 13, it will use the SceneDelegate, for iOS 12 and under, it will use your good old AppDelegate!

Hope you enjoyed this quick post.
If you need any help, don't hesitate to ping me on Twitter, or just leave a comment below! 😇

Happy coding!

Replicating the AppStore's CollectionViewLayout (orthogonal) in Swift 5

Maarek — Fri, 27 Sep 2019 09:36:04 +0000

Building a simple bi-directional scrolling UICollectionView

In a precedent post I scratched the surface of the freshly released CollectionView Compositional Layout API to get simpler and more complex CollectionViewLayout.
The today's challenge is to replicate this orthogonal scrolling CollectionView layout that you might have seen in your iDevice's AppStore ("Apps" or "Games" tab).

Basically we have some featured content in wide cards, with horizontal scroll, the app list that scrolls vertically, just like a regular TableView, and some basic blocks of content, maybe headers or footers with text.

So let's start by building our cells :

the "featured cell" card, having the "card" look, rounded corner, shadow and stuff with a large title and a smaller label ;
an "app cell", that contains an app icon, title and some category ;
and a "text cell" : just a basic cell with a multi-line label.

I am not going to detail this part as it's not the point of this post but you can check the code, at the end of the article.

Right now the ViewController is empty, I'm going to add a simple function that will return a UICollectionViewLayout that we will use in the CollectionView initializer.

    func makeLayout() -> UICollectionViewLayout {
        let layout = UICollectionViewCompositionalLayout { (section: Int, environment: NSCollectionLayoutEnvironment) -> NSCollectionLayoutSection? in
            //
        }
        return layout
    }

Now you know, the UICollectionViewCompositionalLayout block should return a NSCollectionLayoutSection. And here we have 3 section : the one with the features card, the one with the app list and the one with our text cell.

The horizontal scrolling sections' Layout

        let item = NSCollectionLayoutItem(layoutSize: NSCollectionLayoutSize(widthDimension: .fractionalWidth(1.0), heightDimension: .fractionalHeight(1.0)))
        item.contentInsets = NSDirectionalEdgeInsets = NSDirectionalEdgeInsets(top: 0.0, leading: 12.0, bottom: 0.0, trailing: 12.0)
        let group = NSCollectionLayoutGroup.vertical(layoutSize: NSCollectionLayoutSize(widthDimension: .fractionalWidth(0.9), heightDimension: .fractionalHeight(0.25)), subitem: item, count: 1)
        let section = NSCollectionLayoutSection(group: group)
        section.contentInsets = NSDirectionalEdgeInsets(top: 16.0, leading: 0.0, bottom: 16.0, trailing: 0.0)
        section.orthogonalScrollingBehavior = .continuousGroupLeadingBoundary
        return section

Let's detail every line of this sample of code, but first, try to keep in mind what is an item, a group and a section, as seen on my previous post about compositional layout :

I first declare our NSCollectionLayoutItem, with it's size, saying it's going to take 100% of the parent's width and height.
I give this item the insets I want.
Then, I initialize a group, a NSCollectionLayoutGroup, with the size I want each cell to take horizontally. In this case : 90% of the total collectionView width, 25% of the collectionView height. (I want 90% so users can see there is more on the left so they want to scroll 😇)
I finally create my section with my group.
Add some insets.
This continuousGroupLeadingBoundary allows the vertical scrolling, but we can put .paging or any OrthogonalScrollingBehavior.

That's all it takes for the Featured Card's section. We'll put all that in an isolated piece of function that we'll call something like buildHorizontalSectionLayout() and simply return it in our block like so :

    func makeLayout() -> UICollectionViewLayout {
        let layout = UICollectionViewCompositionalLayout { (section: Int, environment: NSCollectionLayoutEnvironment) -> NSCollectionLayoutSection? in
            if section == 0 {
                return self.buildHorizontalSectionLayout()
            }
        }
        return layout
    }

The vertical scrolling sections' Layout

Now for the vertical scrolling, we'll simply mimic the tableView behaviour with self sizing cells. We want full with rows with an estimated height, adjustable according it's content's constraints.

        let item = NSCollectionLayoutItem(layoutSize: NSCollectionLayoutSize(widthDimension: .fractionalWidth(1.0), heightDimension: .fractionalHeight(1.0)))
        item.contentInsets = NSDirectionalEdgeInsets(top: 0, leading: 0, bottom: 0, trailing: 0)
        let groupSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1.0),  heightDimension: .estimated(70))
        let group = NSCollectionLayoutGroup.horizontal(layoutSize: groupSize, subitem: item, count: 1)
        let section = NSCollectionLayoutSection(group: group)
        section.contentInsets = NSDirectionalEdgeInsets(top: 10, leading: 12, bottom: 0, trailing: 12)

An Item that takes 100% of width/height of it's superview.
A group that will have an estimated height, say 70, and 1 item per group.
Finally the section with the group and I specified insets.

I will also encapsulate this piece of code in a buildVerticalSectionLayout func, so now we now can update our makeLayout func :

    func makeLayout() -> UICollectionViewLayout {
        let layout = UICollectionViewCompositionalLayout { (section: Int, environment: NSCollectionLayoutEnvironment) -> NSCollectionLayoutSection? in
            if section == 0 {
                return self.buildHorizontalSectionLayout()
            } else {
                return self.buildVerticalSectionLayout()
            }
        }
        return layout
    }

The viewController will be pretty basic, and I am not going to detail the code. Basically just add a CollectionView, init with a frame and a layout (calling the makeLayout func), place it with constraints, register your cells, and set the delegate and dataSource.

    lazy var collectionView: UICollectionView = {
        let collectionView: UICollectionView = UICollectionView(frame: CGRect.zero, collectionViewLayout: self.makeLayout())
        collectionView.backgroundColor = UIColor.white
        collectionView.delegate = self
        collectionView.dataSource = self
        collectionView.register(Cell.self, forCellWithReuseIdentifier: "cell")
        collectionView.register(Featured.self, forCellWithReuseIdentifier: "featured")
        collectionView.register(Text.self, forCellWithReuseIdentifier: "text")
        collectionView.translatesAutoresizingMaskIntoConstraints = false
        return collectionView
    }()

And there you go !
Here is the final result :

Bonus : you can easily build an horizontal scrolling vertical list like so

by mixing the two layout examples shown above. Just use a vertical NSCollectionLayoutGroup and set an orthogonalScrollingBehavior (in the gif, it's .groupPaging). Don't forget to specify how many items you want in your group (how many "app cell" in a paged block) in the parameter count of you NSCollectionLayoutGroup.

Bonus 2 : You can use compositional Layouts with iOS 12 using IBPCollectionViewCompositionalLayout 😋

Hope you enjoyed this quick walkthrough of UICollectionViewCompositionalLayout. Of course you can download the code.
Play with it, tweak it and make something great! ☺️

Happy coding!

My first iOS Framework 🎉

Maarek — Wed, 17 Jul 2019 15:42:40 +0000

Big day for me today.

I just released my first public iOS framework !

Called UIDrawer.
It's custom UIPresentationController that display modals like a bottom drawer, a component you may have seen in several system iOS apps (like maps) and on multiple Android apps.

For a recent project, I needed this component. It wasn't the first time I encountered that kind of product request and I decided to make a distributed framework out of it.

I am very proud of it. I feel like there is a gap between writing your lines of code for projects and exposing publicly those lines, as a framework anyone could use.

What about you?
When did your write your first Open Source framework ?

Forms made easy with SwiftUI

Maarek — Mon, 01 Jul 2019 13:18:04 +0000

In this post, we will build a registration form with SwiftUI.

Let's start by creating a new Xcode Project : Choose a single view app, and dont forget to check "Use SwiftUI".

Xcode creates a ContentView for you, we'll work with this struct as our main view. First, we will add our registration fields values. Let's say name, email, and password. We need to use the property wrapper @State for our values. If you don't know what @State property wrapper is, I highly recommande to read my post about Properties Wrappers.
This is what we should have by now :

struct ContentView : View {

    @State private var name: String = ""
    @State private var email: String = ""
    @State private var password: String = ""

    var body: some View {
        Text("Hello World!")
    }
}

Now in our view, we want to make a NavigationView that will contain a Form.

struct ContentView : View {

    @State private var name: String = ""
    @State private var email: String = ""
    @State private var password: String = ""

    var body: some View {
        NavigationView {
            Form {
                Text("Hello World!")
            }
            .navigationBarTitle(Text("Registration Form"))
        }
    }
}

By now, if you build and run you should see this :

As you can see, the form object creates a List and every View in it will be a cell, just like our text here, Hello World!.

In this form, we will remove the Hello World text and add instead some sections, three sections actually. One that we will use for the name and mail text fields, another for the password and the last one for our call to action validation button.
A Section takes 3 parameters : a header, a footer and the content (View). Here, we will set headers to our 2 first sections :

struct ContentView : View {

    @State private var name: String = ""
    @State private var email: String = ""
    @State private var password: String = ""

    var body: some View {
        NavigationView {
            Form {
                Section(header: Text("Your Info")) {
                    TextField($name, placeholder: Text("Name"))
                    TextField($email, placeholder: Text("Email"))
                }
                Section(header: Text("Password")) {
                    TextField($password, placeholder: Text("Password"))
                }
                Section {
                    Button(action: {
                                print("register account")
                            }) {
                                Text("OK")
                            }
                }
            }
            .navigationBarTitle(Text("Registration Form"))
        }
    }
}

Which would result into that :

That's it. We now have a simple form made with SwiftUI. Note that we passe the fields values with a $ so that we have a 2 ways binding : the textfields read and write the value we pass to them.

Now, let's try to add a few more things to this...
I would like to add an indicator for the security level of the password.

First, we are going to create an enum for the password security level :

enum PasswordLevel: Int {
    case none = 0
    case weak = 1
    case ok = 2
    case strong = 3
}

And a view :

struct SecureLevelView : View {
    var level: PasswordLevel
    var body: some View {
        HStack {
            RoundedRectangle(cornerRadius: 8).foregroundColor(self.getColors()[0]).frame(height: 10)
            RoundedRectangle(cornerRadius: 8).foregroundColor(self.getColors()[1]).frame(height: 10)
            RoundedRectangle(cornerRadius: 8).foregroundColor(self.getColors()[2]).frame(height: 10)
        }
    }

    func getColors() -> [Color] {
        switch self.level {
        case .none:
            return [.clear, .clear, .clear]
        case .weak:
            return [.red, .clear, .clear]
        case .ok:
            return [.red, .orange, .clear]
        case .strong:
            return [.red, .orange, .green]
        }
    }
}

We can init our view with a level and depending on the level it will display the right colors like so :

From the top to the bottom : .none (no colors), .weak, .ok, .strong.

Now instead of having a simple value for the password, we will make a class that will handle holding and checking the password.
We need this class to be bindable so it can notify the view for the changes of the protection level.

class PasswordChecker: BindableObject {
    public let didChange = PassthroughSubject<PasswordChecker, Never>()
    var password: String = "" {
        didSet {
            self.checkForPassword(password: self.password)
        }
    }

    var level: PasswordLevel = .none {
        didSet {
            self.didChange.send(self)
        }
    }

    func checkForPassword(password: String) {
        if password.count == 0 {
            self.level = .none
        } else if password.count < 2 {
            self.level = .weak
        } else if password.count < 6 {
            self.level = .ok
        } else {
            self.level = .strong
        }
    }
}

Don't forget to import Combine.

The class has 2 attributes : the password and the level.
It also has a didChange property to conform to BindableObject. I you don't know what a BindableObject is, here is the post where I explain what this is and how it works.
What we want here is to update the password level on the didSet of the password, so that when the password's value is updated, we set the level according to the setted password. When the level is setted, we want to notify the view that the password level has changed so it can update the SecureLevelView.

So here, in the checkForPassword method, I choose to make simple rules : the protection level depends on the number of characters in the password, but you might need to use actual rules, checking on capitalized letters, numbers or special characters with a regexp.

Now we want to use that class in our view, we just need to remove the password property and replace it with a PasswordChecker.

struct ContentView : View {

    @State private var name: String = ""
    @State private var email: String = ""
    @ObjectBinding var passwordChecker: PasswordChecker = PasswordChecker()

    var body: some View {
        NavigationView {
            Form {
                Section(header: Text("Your Info")) {
                    TextField($name, placeholder: Text("Name"))
                    TextField($email, placeholder: Text("Email"))
                }
                Section(header: Text("Password")) {
                    TextField($passwordChecker.password, placeholder: Text("Password"))
                    if !self.passwordChecker.password.isEmpty {
                        SecureLevelView(level: self.passwordChecker.level)
                    }
                }
                Section {
                    Button(action: {
                                print("register account")
                            }) {
                                Text("OK")
                            }
                }
            }
            .navigationBarTitle(Text("Registration Form"))
        }
    }
}

I chose to hide the SecureLevelView when the password is empty.

Now this is what we have :

The last feature I'd like to have is a toggle to make the user accepts the terms and conditions.
I added a new @State Boolean property :

@State private var terms: Bool = false

and in the section :

                    if self.passwordChecker.level.rawValue >= 2 {
                        Toggle(isOn: $terms) {
                            Text("Accept the terms and conditions")
                        }
                        if self.terms {
                            Button(action: {
                                print("register account")
                            }) {
                                Text("OK")
                            }
                        }
                    }

Meaning : if the password protection level is higher than ok (ok or strong), we show the "Accept the terms and conditions" Toggle and only if the toggle is on, then show the validation button.

I agree, this is a terrible UX. But now you know how to build easy forms and dynamically show info as user types in, using combine.

Hope you enjoyed this little post. You can download the full source here on my github.

Happy coding !

Property Wrappers in SwiftUI

Maarek — Fri, 28 Jun 2019 15:36:16 +0000

With Swift 5 and SwiftUI, Apple introduced property wrappers. You might have saw one of them on some SwiftUI articles or tutorials : @State, @BindableObject, @EnvironmentObject.
In this post, we’ll try to explain what are these wrappers and when to use them.

Everything in SwiftUI is struct based. And structs are immutable, those are fixed values.
When a property has an @State property wrapper, it just tells your struct that the memory management won’t be handled by the struct itself but by another memory manager entity : the SwiftUI Framework.
Let’s picture a practical use case :

struct ContentView : View {
    var buttonTapped: Bool = false
    var body: some View {
        Button(action: {
            self.buttonTapped.toggle()
        }) {
            Text("Tap the button")
        }
    }
}

Here, we want the buttonTapped value to toggle on the tap of the button.
Xcode won’t let me do that saying :

Cannot use mutating member on immutable value: 'self' is immutable

Of course, we’re in a struct!
That’s where you want to use the @State wrapper. The memory, the creation and the storage of the property won’t be managed by the struct itself.
What it actually does is it will be notified that the value has changed and it will re-create the struct with the new value, therefore, the view will be invalidate and be refreshed with the updated value.

A $ sign before a value means a two way binding. Passing a $value to a View will enable to read the value and update it. Might be useful for TextFields for example, which will read and write the value you passed. Just like that :

struct ContentView : View {
    @State var input: String = ""
    var body: some View {
        TextField($input)
    }
}

@State is great for these simple cases. When your view has simple properties like String, Int or Bool value. But what about when you have more complicated objects you want to use ?
Let’s say you have this registration form, that owns 3 fields : email, username, password.
First thing would be to make a struct with these Strings attributes, right ?

struct Registration {
var email: String = ""
var username: String = ""
var password: String = ""
}

And just store it in your view with a @State wrapper.

struct ContentView : View {
    @State var registration: Registration = Registration()
    var body: some View {
        Text(“Hello”)
    }
}

It would actually works great as long as you’re using this struct in only one view, but let’s imagine you would have one view, say InfoView, with the email and username fields and another, that would be PasswordView, for the password field. That is where you would be stucked. Both view would need the same Registration model.
The Registration object will be passed to these two views, but remember, structs have one owner, because structs works as value and not reference. The Registration is a struct. You can’t have an instance of a struct like an object instance. If multiple views (or any kind of objects) owns a struct, every view would have it's own version of it.

So to make our registration form complete, we would need to transform the struct into a class. So we can work with references. Pass it to every view we would need to. But the thing is : with the @State wrapper, the the view (struct) gets re-created with updated values, but you can’t do that with a class. The class won’t be “listened” like an @State property would be.
It’s time to import Combine !
In the Getting started with SwiftUI and Combine post, we discovered the Bindable protocol. This is what we need to use in this situation. We’ll make our Registration class Bindable.

class Registration: Bindable {
    var email: String = ""
    var username: String = ""
    var password: String = ""
}

As any Bindable object, you will need a didChange property and call it on any value updated.
We don’t need to pass a Registration object or an error. We just need to notify that the object’s values has changed.

class Registration: Bindable {
    var didChange = PassthroughSubject<Void, Never>()
        var email: String = "" {
        didSet {
            didChange.send()
        }
    }
    // do the same for each property
}

Now we need to tell SwiftUI to watch for these changes and, juste like with the @State, update the UI by recreating the view.
So just replace @State in your view by @ObjectBinding :

struct ContentView : View {
    @ObjectBinding var registration: Registration = Registration()
    var body: some View {
        Text(“Hello”)
    }
}

Now we solve the problem of having a complex, referenced type, object to be listened by SwiftUI to update our view. But what about passing this object to another view, just like in our practical use case with the two pages registration form ?
Well, Apple made something really cool for passing object through views : Environment. This is a way to share objects to make them available where needed.

Here is how it works :
You just add your Registration object with @EnvironmentObject :

struct ContentView : View {
    @EnvironmentObject var registration: Registration
    var body: some View {
        Text(“Hello”)
    }
}

You don’t need to initialize it, as your view will assume it's value will be available in the Environment. To add a value into the Environment it is quite simple :

ContentView.environmentObject(Registration())

You can do so in you sceneDelegate or anywhere you call your view.
Every view that gets to use the Registration object need to have a Registration property wrapped with @EnvironmentObject.

I hope this post helped you to understand the mechanics of SwiftUI and how to use the property wrappers.
I you have any questions, don’t hesitate to leave a comment.

Happy coding! :)