Forem: marinbenc🐧

Implementing Facebook Login on iOS without the Facebook SDK

marinbenc🐧 — Mon, 18 May 2020 08:37:17 +0000

Adding Facebook Login to your iOS app is a quick way to boost signup conversion rates. Lots of people already have Facebook accounts and aren't in the mood of going through a registration page. Plus, if you only use social login you can save yourself a lot of time by removing the need to handle authentication on your backend. Sounds like a win-win, right?

Well, there are some caveats. The "golden path" of implementing Facebook Login is to install the Facebook SDK. It's a great way to simplify the login flow, provides some good UX improvements for the user and saves you time. At least in theory. In practice, there are a few problems with Facebook's SDK.

What's wrong with the Facebook SDK?

Build and app size. An empty iOS app archive is around 1 MB. I added the necessary Facebook SDK dependencies for Facebook login (v7.0.0), and the archive grew to 8 MB. That's 7 megs of code for the simple task of showing a few text fields and initiating a web request.
User privacy. Facebook wouldn't be Facebook if it didn't use its SDK to collect your user's data. According to their FAQ, Facebook Login collects all kinds of user data like app launches, user IDs, your user's user agent information, IP address, time zone, carries, disk space and other information. This is all user-identifying data that can be used to track your users across apps and websites. In other words, Facebook can use this data to build out your users' app and browsing history, without them even knowing.
SDK bugs. Recently, Facebook's SDK broke multiple million-user apps, as well as a bunch of tiny ones. Considering the amount of complex code the closed-source SDK runs, their terrible code practices and the sensitivity of the user data they collect, it'll make your life a lot easier if you could avoid adding their SDK in the first place.
GDPR compliance. Some of the data Facebook collects is personally-identifiable information. If you don't get consent from your users before collecting their information, you violate GDPR – not Facebook.

If all this makes you worried about how you can provide Facebook login to your users without their SDK – don't fret! You can use Facebook login without Facebook SDK. What you have to do is use their web APIs instead. This post is all about how to use Facebook login in your iOS app without the Facebook SDK.

Note: You can find the full implementation of this tutorial on GitHub.

Facebook Login without the SDK

Here's how the process works, step-by-step:

First, your app will show a web view of Facebook's login page.
Once the user logs in, Facebook will redirect the web view to a URL that you specify, and append the authentication token as a URL parameter.
You will read that parameter and send it to your backend service.
Your backend service will verify Facebook's authentication token and give you credentials for making authorized requests.

The process is similar to how the SDK works, except we'll use iOS-provided web views to show the login. The web view will act as a sandbox, making sure your user's data stays as private as possible and saving you from having to include Facebook's SDK into your app.

However, getting the security right can be a bit tricky, and the information on Facebook's docs and the Internet is scattered and incomplete. This is why I wrote this guide to arm you with the knowledge and trust to ditch Facebook's SDK securely. Let's get started!

Initiating an Authentication Session

To make the process as secure as possible, you'll use ASWebAuthenticationSession, a class from the built-in AuthenticationServices framework specifically created for authenticating your users inside a web view. AuthenticationServices runs in a separate process from your app, making sure that there's no way for your app to spy on the user while they're logging in. This makes it more secure than a regular WebKit view.

Another big advantage of AuthenticationService's web view is that it can access cookies on your device. This means that if you had logged into Facebook earlier, you won't need to type in your email and password again.

Additionally, the web authentication session will pop up a dialog informing the user their authentication data will be shared with your app, making sure your users are informed about what's going on.

Let's get going! I'm going to assume you have a view controller with an IBAction to a Facebook login button. In this example, that IBAction function is called continueWithFacebookTapped.

Open your view controller file and, before anything else, add a new import to the top of the file:

import AuthenticationServices

You'll see this come into play later.

Next, add the following implementation to continueWithFacebookTapped:

@IBAction func continueWithFacebookTapped(_ sender: Any) {
  let facebookAppID = "YOUR_APP_ID"
  let permissionScopes = ["email"]
}

You'll start by declaring these two lines. The first line is your Facebook app ID. Make sure to replace the value with your app ID. You can find it by going to Facebook Developer, opening My Apps in the top-right and selecting your app. You'll get to your app's dashboard. You can find your app ID top-left, right next to your app's name.

Copy it over and paste it as the value of facebookAppID in the code.

In the second line, you declare permissionScopes – a list of permissions you'll need to access. In this case, you're only looking for the user's email. You can see a list of available permissions on Facebook's documentation page.

Next, continue writing the function by adding the following code:

let state = UUID().uuidString
let callbackScheme = "fb" + facebookAppID
let baseURLString = "https://www.facebook.com/v7.0/dialog/oauth"
let urlString = "\(baseURLString)"
  + "?client_id=\(facebookAppID)"
  + "&redirect_uri=\(callbackScheme)://authorize"
  + "&scope=\(permissionScopes.joined(separator: ","))"
  + "&response_type=code%20granted_scopes"
  + "&state=\(state)"
let url = URL(string: urlString)!

This code builds out the URL you'll show in the web view. The URL points towards Facebook's login page, but includes a couple of URL parameters that tell Facebook how to log your user in:

Your client (app) ID. This is a unique, but non-secret, string identifying your app.
A callback URL. When Facebook is done with logging your user in, it will redirect the web view to this URL. In your case, it will call fb12345678://authorize, but instead of 1234567 it will be your Facebook app ID.
The permission scopes you want to get.
What the response should look like. In this case, a combination of an authentication code and the permissions your user has granted.
Finally, a unique state string. Later on, you'll verify that this state was left unchanged during the login process, to verify that nobody was spoofing a login attempt.

Next, you'll initialize an authentication session with this URL:

let session = ASWebAuthenticationSession(
  url: url, callbackURLScheme: callbackScheme) {
  [weak self] (url, error) in
  guard error == nil else {
    print(error!)
    return
  }

  print(url)
}

When the session starts, it will pop up a web view. Once it detects a redirect with the callback scheme you provided (a URL starting with fb12345678://) it will dismiss the web view and call the trailing closure declared above with the redirect URL. Facebook will append a bunch of parameters to the redirect URL, giving you access to the login code.

Before the authentication session can show a web view, though, it needs access to a view. Add the following extension to the bottom of the file:

extension ViewController: ASWebAuthenticationPresentationContextProviding {
  func presentationAnchor(
    for session: ASWebAuthenticationSession) -> ASPresentationAnchor {
    return view.window!
  }
}

This declares the view controller as the authentication session's context provider. In this case, the context is the current window. The authentication session will use the window to present a web view.

Finally, add the following two lines to the bottom of continueWithFacebookTapped:

session.presentationContextProvider = self
session.start()

The above code adds a context provider to the session and starts it. Run the project and tap the Continue with Facebook button.

You should see a Facebook login page pop up.

Getting the authentication code

After logging in, the web view will close and you'll see a URL printed to the console that looks something like this:

fb1234567://authorize/?code=AUTHORIZATION_CODE&granted_scopes=email%2Cpublic_profile&denied_scopes&state=694B3393-34CD-47B7-AF79-B78D29A1EBCD#_=_

The first bit of the URL, fb1234567://authorize/ is the URL you told Facebook to redirect to. The rest of the URL is a couple of query parameters that Facebook added for you:

First, there's a code. This is the authorization code for your user. You can send this code to your backend service, which will then exchange the code for a Facebook authorization token.
Next, the granted_scopes parameter tells you which permission scopes the user granted. Scopes that were denied will be inside denied_scopes.
Finally, the state parameter is a string that should match the original state you sent when you initialized the login process.

To parse this URL, you'll create a struct to encapsulate the data mentioned above. Add the following struct to your project:

public struct FacebookLoginResponse {
  let grantedPermissionScopes: [String].
  let code: String
  let state: String
}

Next, add a new function to your view controller that will get a component from a URL:

func getComponent(
  named name: String, 
  in items: [URLQueryItem]) -> String? {

  items.first(where: { $0.name == name })?.value
}

This is a small helper function that you'll use in a bit. For now, all you need to know is that you'll split the URL parameters into an array of URLQueryItems. To get the value of a parameter by the parameter name, you'll find the first item in the array that matches that name.

Next, add a new function that parses the URL into an instance of FacebookLoginResponse:

func response(from url: URL) -> FacebookLoginResponse? {
  guard
    // 1
    let items = URLComponents(
      url: url, 
      resolvingAgainstBaseURL: false)?.queryItems,
    // 2
    let state = getComponent(named: "state", in: items),
    let scope = getComponent(named: "granted_scopes", in: items),
    let code = getComponent(named: "code", in: items)
  else {
    return nil
  }
  // 3
  let grantedPermissions = scope
    .split(separator: ",")
    .map(String.init)
  // 4
  return FacebookLoginResponse(
    grantedPermissionScopes: grantedPermissions,
    code: code,
    state: state)
}

Here's what's going on in the function:

First, you create an array of URL components from the provided URL. This will parse all the parameters of the provided URL and fill up the array.
Next, you use the helper function you declared earlier to get the state, permission scopes, and code values from the URL query parameters.
The permission scopes are all in one comma-separated string, so you split the string on commas to get a String array of permissions.
Finally, you create the login response with the data you parsed from the URL.

Now that you have a way of extracting information from the redirect URL, you can call this function from ASWebAuthenticationSession's completion closure. Change the declaration of session to the following:

let session = ASWebAuthenticationSession(
  url: url, callbackURLScheme: callbackScheme) { 
  [weak self] (url, error) in

  guard error == nil else {
    print(error!)
    return
  }

  guard 
    let receivedURL = url, 
    let response = self?.response(from: receivedURL) else {

    print("Invalid url: \(String(describing: url))")
    return
  }

  guard response.state == state else {
    print("State changed during login! Possible security breach.")
    return
  }

  // At this point, you should send this code to your backend 
  // service and get regular authentication credentials that 
  // you use in the rest of your app.
  print(response.code)
  self?.sendCodeToServer(response.code)
}

If the URL is not nil, grab the response. Before doing anything else, you should check that the state you got in the redirect URL matches the one you sent when initializing the login flow. If these are different, someone might have tried to spoof a login request. However, you're smarter than them: You won't let them go through.

Finally, after all the checks, you can access the authentication code. This a string that uniquely identifies your user's login request. You should send this code to your backend service, at an endpoint akin to POST login/facebookCode (or similar, depending on your backend implementation) with the code attached to the body of the request.

From then on, the backend service should take over. Here's what needs to happen on the backend service:

The server receives the code you sent and calls Facebook's endpoint for exchanging a code for an authentication token.
The server should then respond with either an app-specific access token that's unrelated to Facebook, or send the Facebook authentication token back to the app if the app needs to perform further requests to the Facebook API.

Initiating this request would look something like this:

func sendCodeToServer(_ code: String) {
  let url = URL(string: "https://example.com/login/facebookCode")!
  var request = URLRequest(url: url)
  request.httpBody = code.data(using: .utf8)
  request.httpMethod = "POST"

  URLSession.shared.dataTask(with: request) { 
    [weak self] (data, response, error) in

    guard let data = data else {
      print("An error ocurred.")
      return
    }

    let receivedToken = String(decoding: data, as: UTF8.self)
    guard !receivedToken.isEmpty else {
      print("An error ocurred.")
      return
    }

    self?.store(token: receivedToken)
  }
}

Note that this is a fake web request. In your app, you'd change both the URL and how you send the token to match your server's expected request format. Once you receive a token in your response, you'll store it by calling the store(token:) function, which you'll implement in the section "Storing your login information".

Getting an access token instead of a code

Note: This section is optional. You only need to perform these steps if your backend service is not set up to receive a code, but expects an access token instead.

By default, Facebook returns a code instead of an access token. This is different from the login SDK which returns the access token. Your backend service might already be set up for this, so in some cases, you want to get the access token directly.

Luckily, the API allows you to get an access token. First, inside facebookLogin, change the declaration of urlString to the following:

let urlString = "\(baseURLString)"
  + "?client_id=\(facebookAppID)"
  + "&redirect_uri=\(callbackScheme)://authorize"
  + "&scope=\(permissionScopes.joined(separator: ","))"
  + "&response_type=token%20granted_scopes"
  + "&state=\(state)"

The only change here is setting response_type to token instead of code.

The response will change, so you need to update the FacebookResponse struct to match:

public struct FacebookLoginResponse {
  let grantedPermissionScopes: [String].
  let acessToken: String
  let state: String
}

Next, in response(from:), change the line where you grab code to the following:

let accessToken = getComponent(named: "access_token", in: items)

Finally, at the bottom of the function, change the return statement to set the access token instead of the code:

return FacebookLoginResponse(
  grantedPermissionScopes: grantedPermissions,
  accessToken: accessToken,
  state: state)

Your app is now ready to receive an access token instead of a code. Once you get the access token, you should send it to your backend service.

Once the backend service receives the token, it must verify the token. Facebook exposes a fairly straight-forward request to verify that the token is valid.

Storing your login information

When storing tokens, don't use UserDefaults. UserDefaults is not encrypted and therefore your user's token is out there in plain text, and easily accessible from a jailbroken device. Instead, store the token inside Keychain. The keychain services API is a built-in iOS API that lets you store small bits of user data in an encrypted, secure location.

Unfortunately, the keychain services API was originally written in C and the API is a little bit cumbersome to use. That's why many Swift libraries wrap around Keychain and make your life easier. I recommend KeychainAccess by Kishikawa Katsumi since it's frequently updated and supports new iOS features.

If you're using KeychainAccess, you can store the token by first importing the library into the view controller file:

import KeychainAccess

Next, add the following code to the controller:

let keychain = Keychain(service: "com.marinbenc.FacebookLogin")

func store(token: String) {
  keychain["accessToken"] = token
}

First, you create an instance of Keychain with an ID, which could be any string you like. Inside the function, you'll store the token inside the keychain instance.

Once you store this information, you can check if the user is logged in, based on whether you have a stored token or not.

var isLoggedIn: Bool {
  keychain["accessToken"] != nil
}

If there's a stored token, your user is logged in, and you don't need to prompt them with a login screen. However, make sure to check that their token hasn't expired. (See Checking token validity below.)

Logging out

To log out, delete the stored access token and you're good!

func logOut() {
  keychain["accessToken"] = nil
}

Since the token is the only bit of user-identifiable information you store, deleting it will make it impossible for your app to perform further requests on your user's behalf.

Checking token validity

Access tokens live for around 60 days. However, they can be invalidated even before that. Here's how a token can become invalid:

your user changes their password
your user logs out from your app in Facebook's setting
your users completely de-authorizes your app
the token expires

Because of this, you must check if the token is valid at least once a day.

You can check token validity either from the server or from your iOS app (provided you store the access token). One way to check token validity is to perform a Facebook Graph API request and check the response for errors.

func checkTokenValidity(_ accessToken: String) {
  let url = URL(string: 
    "https://graph.facebook.com/me?access_token=\(accessToken)")!
  URLSession.shared.dataTask(with: url) { (data, response, error) in
    guard let response = response as? HTTPURLResponse else {
      return
    }

    if response.statusCode < 200 || response.statusCode >= 300 {
      self.logOut()
    }
  }.resume()
}

The above function makes a request to the Facebook Graph API with the user's access token. If the response is outside the successful range (200 to 300) you'll log the user out.

Additionally, the response will contain JSON data that usually explains what kind of error happened inside an error object. If the token is invalid you'll get the following response:

{
    "error": {
        "message": "Invalid OAuth access token.",
        "type": "OAuthException",
        "code": 190,
        "fbtrace_id": "SOME_ID"
    }
}

You'll get different messages if the token has expired, the user revoked your access, the user logged out or the user changed their password. To see all the possible responses, take a look at this post on Facebook's blog.

A good time to perform this check would be when your app starts. You can call this function from inside AppDelegate.swift, from application(_:didFinishLaunchingWithOptions:):

func application(
  _ application: UIApplication, 
  didFinishLaunchingWithOptions launchOptions:
  [UIApplication.LaunchOptionsKey: Any]?) -> Bool {

  let keychain = Keychain(service: "com.marinbenc.FacebookLogin")
  if let storedToken = keychain["accessToken"] {
    checkTokenValidity(storedToken)
  }

  return true
}

Can I log the user in without a backend service?

Logging in through a web view means there are additional security concerns you need to keep in mind. Web browsers are made to load any webpage you throw at them, and they're vulnerable to phishing attacks, cross-site scripting attacks, or cross-site request forgery attacks.

Because of these concerns, when you log in with Facebook's web login, you receive a short-term access token that is usually valid for only a couple of hours. Storing this token wouldn't mean much since your user would have to log in again in 2 hours – not the best user experience!

However, if you verify the access token from your backend service, you get a brand new long-lived access token that is good for a couple of months, instead of mere hours.

You might be tempted to simply verify the token from your app instead of from your backend service. And, technically, this would work: But it's a bad security practice. To verify the token, you need access to your Facebook app's secret. If your app ID is your app's username, you can think of the secret as your app's password. The app ID is public and can be known to all, but the secret should remain, well, secret.

If you want to verify tokens from your app, you'll have to store the API token somewhere in your app. If you do this, someone could decompile your app and find the app token. Additionally, when you make requests, you have to send the secret along with the request. Anyone sniffing web requests could find your attached secret and use it to not only hijack your users token but also your apps token, letting them change your Facebook App settings!

So, to sum up, never store or send your app secret from a client device. All calls that need the secret should be done from your server.

I hope this helps you ditch the SDK and give your users a better experience while not putting their security at risk. If you find any issues with this post, feel free to reach out.

Sources and further reading

A general overview of building a manual Facebook login flow:
https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow/

Facebook security best practices:
https://developers.facebook.com/docs/facebook-login/security

How to handle expired access tokens:
https://developers.facebook.com/blog/post/2011/05/13/how-to--handle-expired-access-tokens/

General information about access tokens:
https://developers.facebook.com/docs/facebook-login/access-tokens

Handling access token errors:
https://developers.facebook.com/docs/facebook-login/access-tokens/debugging-and-error-handling

Networking in SwiftUI

marinbenc🐧 — Tue, 11 Feb 2020 07:53:17 +0000

By now, you did all there is do with your app's UI. You have a way to log in, show contacts and display incoming messages. But one crucial bit is missing: Your app is not connected to anything.

In this final part of the SwiftUI course, you'll breathe life into your app by adding networking to send and receive messages to a web server!

To help you, you'll use CometChat Pro. CometChat Pro is a cross-platform chat SDK that lets you build chat apps that work on iOS, Android and the web at the same time. It takes care of storing, receiving and sending messages to your users' devices. There's no need to deal with servers, backend code or WebSockets.

You can find a link to the finished project code on GitHub.

Installing CometChat

Before you can use CometChat, you'll first need to install the SDK as a dependency. To do this, you'll use CocoaPods, a dependency manager for iOS.

Note: If you don't have CocoaPods installed, enter the following command in Terminal:
sudo gem install cocoapods

Open Terminal and, using cd, navigate to your project's root folder. (The one that contains the .xcodeproj file.)

Enter the following command:

pod init

This will initialize CocoaPods for your project and create a new file called Podfile. Open this file in your favorite text editor, and update its contents to the following:

target 'CometChat' do
  use_frameworks!
  pod 'CometChatPro', '~> 2.0.5'
end

Save the file and head back to Terminal to enter the following command:

pod install

This will install CometChat into your app, and create a new file with the .xcworkspace extension. Close any Xcode projects you might have active, and open the .xcworkspace file. From this point on, you'll use the workspace, instead of the project file, to develop your app.

Setting up

Now that CometChat is in the app, let's begin using it. First, you'll create a CometChat account — don't worry, it's free!

Head over to CometChat's registration page and sign up. Once you sign up, you'll get taken to a dashboard. Create a new app under Add New App. Select USA as the region and enter CometChat as the app's name. Click the + button to create the app.

After 15 or so seconds, you'll have an up-and-running chat service online! All you need to do is connect to it.

Open your new app's dashboard by clicking Explore. Head over to API Keys in the sidebar. Take a look at the keys names API Key with full access scope. Note down the API Key and App ID — you'll need these in a second.

Back in Xcode, create a new plain Swift file named ChatService.swift. This file will be the bridge between CometChat's SDK and your app. All SDK-related code will go in this file.

Add the following contents to the file:

import Foundation
import Combine
import CometChatPro

extension String: Error {}

Since we're working with cool new tools like SwiftUI, it makes sense to also build ChatService using Combine. So, you'll import Combine as well as CometChat's SDK.

Next, create the ChatService class:

class ChatService {

  private enum Constants {
    #warning("Don't forget to set your API key and app ID here!")
    static let cometChatAPIKey = "API_KEY"
    static let cometChatAppID = "APP_ID"
  }

}

You declare this class and an enum to hold some necessary constants. These will be your CometChat app ID and API key. Make sure to replace the placeholders with the values you saw earlier in the online dashboard.

Next, add a static function to the class that will initialize CometChat:

static func initialize() {
  let settings = AppSettings.AppSettingsBuilder()
    .subscribePresenceForAllUsers()
    .setRegion(region: "us")
    .build()

  _ = CometChat(
    appId: Constants.cometChatAppID,
    appSettings: settings,
    onSuccess: { isSuccess in
      print("CometChat connected successfully: \(isSuccess)")
    }, onError: { error in
      print(error)
    })
}

This sets up CometChat so that it works with your app. Make sure that the region matches the one you set in the online dashboard (us and eu, respectively).

You'll call this function whenever your app launches. The perfect place for this is in SceneDelegate.swift. Add the following line to the top of scene:

ChatService.initialize()

Now CometChat will get initialized when a user starts your app.

There's one more step to finish your setup. To use ChatService, your views need a way to access it. Thankfully, you already created an object that you add to your root view's environment — AppStore.

Head to AppStore.swift and add a new property to the nested AppState struct:

struct AppState {
  var currentUser: Contact?
  let chatService: ChatService
}

Next, modify the declaration of state to include ChatService:

@Published private(set) var state = AppState(
  currentUser: nil, 
  chatService: ChatService())

Now, any view can fetch the ChatService by getting it from the AppStore environment object. Convenient!

Run the app and check the console. You should see a message saying that you connected to CometChat. It lives!

Logging in

With our setup done, it's time to move onto some real features. We'll start with logging in. You already implemented the UI for this, all that's left is telling CometChat a user wants to log in.

Open up ChatService.swift and add a new property:

private var user: Contact?

This property will store the currently logged in user. Because there's one shared ChatService instance in the environment, all views will have access to the same user.

CometChat has its own User class, but you won't be using this in your app. Instead, you'll add a way to convert CometChat's Users to Contacts.

Open Contact.swift and import CometChat at the top of the file:

import CometChatPro

Next, add the following extension to the bottom of the file:

extension Contact {
  init(_ cometChatUser: User) {
    self.id = cometChatUser.uid ?? "unknown"
    self.name = cometChatUser.name ?? "unknown"
    self.avatar = cometChatUser.avatar.flatMap(URL.init)
    self.isOnline = cometChatUser.status == .online
  }
}

This initializes a Contact with a CometChat User instance.

Combine's Futures and Promises

Next, get back to ChatService.swift and add a method to log the user in:

func login(email: String) -> Future<Contact, Error> {

}

You might be wondering, what the hell is a Future? If you're coming from React or a similar JavaScript-based framework, you might be familiar with a thing called promises. Promises and futures are terms that are used in different ways in different languages, but they generally achieve the same thing: Replacing callbacks with a more sane programming model.

Future is a Combine publisher that will eventually produce a single value. For instance, if you're making a network request to fetch a user, you can represent that value as Future<User, Error>. Right now, there's no value, but in the future, there'll be a user or an error.

Put another way, a Future promises a value. That's why promises and futures are often used interchangeably.

Futures are usually a replacement for callbacks. Before Combine, each network request had a callback function that it would call when the request completes. Instead of returning a value, the functions would receive a callback.

Futures allow you to return a value (a future) right away — even if the data isn't yet loaded. This gives the caller more flexibility. They can get the future and do whatever they want with it: Attach callbacks, perform transformations with map or compactMap, cancel the request mid-way through, ignore the result and so on.

I think it's safe to say futures are the future of asynchronous code in Swift.

Creating a Future

Let's get back to login. Since login returns a Future, you'll have to create one in the function. Add the following to login:

return Future<Contact, Error> { promise in

}

Here, you'll immediately return a Future from the function. A Future is initialized with a closure. This closure has one argument: A function called a promise. The promise is a function that you'll call when you get the data you want to load.

To sum up: Future is a struct that gets initialized with a closure. This closure is a function that takes another function as its argument called a promise. Within the closure, you'll call this promise to push data through the promise to the caller.

It may sound complex, but after a few goes at creating futures, you'll get the hang of it!

Add the code to login inside Future's closure:

// 1
CometChat.login(
  UID: email,
  apiKey: Constants.cometChatAPIKey,
  onSuccess: { [weak self] cometChatUser in

    // 2
    guard let self = self else { return }
    self.user = Contact(cometChatUser)
    DispatchQueue.main.async {
      // 3
      promise(.success(self.user!))
    }
  },
  onError: { error in

    // 4
    print("Error logging in:")
    print(error.errorDescription)
    DispatchQueue.main.async {
      promise(.failure("Error logging in"))
    }
  })

Here's what's going on in the closure:

You call CometChat's login function and pass it the user's unique ID (email) and the app's API key.
If CometChat manages to log the user in, you'll convert the user to a Contact and set the property you created earlier to store the user.
After dispatching back to the main queue, you'll call promise with a successful value. This notifies anyone listening to the Future that new data has arrived.
On the other hand, if something goes wrong, you'll call promise with an unsuccessful value, giving anyone listening an error.

Using Futures

Now you can hook up your login UI with the function you just created. Open up LoginView.swift and add an import to the top of the file:

import Combine

Next, add the following property to the struct:

@State private var subscriptions: Set<AnyCancellable> = []

You've already learned about cancellables. Here, you declare a set to hold all of LoginView's subscriptions. Since LoginView is a struct (and thus immutable), you'll need to mark the set as @State before you can add new items to the set.

Next, modify login so that it calls the function you created in ChatService:

func login() {
  store.state.chatService.login(email: email)
    .sink(receiveCompletion: { error in
      print(error)
    }, receiveValue: { user in
      self.store.setCurrentUser(user)
      self.showContacts = true
    })
    .store(in: &subscriptions)
}

login returns a Future, so you call that future's sink method. sink is not specific to futures, though. It's the way you attach closures to Combine Publishers. Whenever the publisher publishes a new event, the closure you provide in sink gets called.

In this case, you provide two closures: One for a failed, and one for a successful result. On failure, you'll print out the error. If the user is logged in successfully, however, you'll set the current user on the AppStore and initiate a transition to the contacts screen. Finally, you'll store the cancellable inside the set you added to the struct.

Build and run the app and try to log in. If you try to use your email you'll get an error. This is expected — your email doesn't exist in the database of users! Thankfully, there are some values you can use to test out your chat app.

CometChat gives you five default users with user IDs superhero1 through superhero5. You can see these users if you navigate to the Users page on CometChat's online dashboard.

Enter superhero1 as the email. This is Iron Man's top-secret username, so don't share it with anyone!

If everything goes correctly, you'll get sent to the contacts screen. This means your app logged in to CometChat! You're successfully communicating with an online chat service.

The contacts you see are still fake, though. Let's take care of that.

Fetching Contacts from CometChat

CometChat stores each registered contact for you. This means you can easily fetch all existing users to display them on the contacts screen.

Head back to ChatService.swift and add the following code to the class:

private var usersRequest: UsersRequest?
func getUsers() -> Future<[Contact], Error> {
  usersRequest = UsersRequest.UsersRequestBuilder().build()

}

You create a UsersRequest and store a reference to it. You do this using a UsersRequestBuilder: It allows you to configure your request in different ways. For instance, you can only fetch the user's friends, hide blocked users, paginate the request and so on.

Next, you'll create another future and use the request to fetch all users in your app:

return Future<[Contact], Error> { promise in
  self.usersRequest?.fetchNext(
    onSuccess: { cometChatUsers in
      let users = cometChatUsers.map(Contact.init)
      DispatchQueue.main.async {
        promise(.success(users))
      }
    },
    onError: { error in
      let message = error?.errorDescription ?? "unknown"
      promise(.failure(message))
      print("Fetching users failed with error:")
      print(message)
    })
}

If the request returns successfully, you'll convert each user to a Contact and pass all the users to the caller. Otherwise, if something goes wrong, you'll print out an error.

Let's call this function from ContactsView.swift. First, import Combine in the file:

import Combine

Next, add a set of cancellables to the struct:

@State private var subscriptions: Set<AnyCancellable> = []

Then, add the following function:

private func getContacts() {
  store.state.chatService.getUsers()
    .sink(receiveCompletion: { error in
      print(error)
    }, receiveValue: { contacts in
      self.items = contacts.map {
        ContactRow.ContactItem(
          contact: $0,
          lastMessage: "",
          unread: false)
      }
    })
    .store(in: &subscriptions)
}

Here, you use sink to respond to the future as you did earlier. In this case, when you get users you'll set them into your state variable, letting the view update itself. If you get an error, you'll print it to the console.

Next, call this method when the view appears by adding the following line to the bottom of body:

.onAppear(perform: getContacts)

Finally, change the declaration of items to remove hard-coded contacts:

@State private var items: [ContactRow.ContactItem] = []

You won't be needing these anymore. Run the app, log in as superhero1 and move on to the contacts screen. Instead of seeing hard-coded contacts, you'll see the users CometChat created for you, including Captain America, Spiderman and even a few of the X-Men!

Updating a contact's online status in real-time

Currently, all of your contacts are showing as offline. There are two reasons for that: One, nobody else is using your app yet. But, more importantly, you also haven't implemented a way to track their online status. CometChat tracks this and notifies you when they come online. You'll use that to update your views.

Converting delegates into Combine publishers with passthrough subjects

CometChat uses the delegate pattern to notify you of changes to a contact's online status. This is a useful pattern that is used universally in UIKit. In SwiftUI, we can take advantage of Combine and its declarative nature for code that is more straightforward than delegates. To do this, we'll use Combine's Subjects to convert the delegate methods into Combine publishers.

Back in ChatService.swift, add the following two properties to the top of the class:

private let userStatusChangedSubject = PassthroughSubject<Contact, Never>()
let userStatusChanged: AnyPublisher<Contact, Never>

You just declared your first subject! Subjects are a special kind of Combine publisher that is a bridge between imperative and reactive programming. Subjects let you manually send events to their subscribers. This is useful for wrapping code that doesn't support Combine into a neat Combine wrapper.

Next, add an initializer to the class:

init() {
  userStatusChanged = userStatusChangedSubject.eraseToAnyPublisher()
}

Notice that you declared a private subject and a public AnyPublisher. Since anyone can add their events to a subject, it's good practice to make it private. The same way you would make setters private and getters public for regular variables. By calling eraseToAnyPublisher, you get a version of the subject that is immutable.

Next, add the following line to the top of login, just before the return statement:

CometChat.userdelegate = self

You register as CometChat's user delegate so that it notifies you when a user's status changes.

There's one final bit to add to ChatService. Add the following extension that implements CometChatUserDelegate to the bottom of the file:

extension ChatService: CometChatUserDelegate {

  func onUserOnline(user cometChatUser: CometChatPro.User) {
    DispatchQueue.main.async {
      self.userStatusChangedSubject.send(Contact(cometChatUser))
    }
  }

  func onUserOffline(user cometChatUser: CometChatPro.User) {
    DispatchQueue.main.async {
      self.userStatusChangedSubject.send(Contact(cometChatUser))
    }
  }
}

Here, you use the subject's send method to send the updated contact through the subject. Anyone listening to the subject (or the erased version) will receive this contact.

Head back to ContactsView.swift to connect it to the code you just wrote. First, add the following method:

private func updateContactsOnChange() {
  store.state.chatService.userStatusChanged.sink {
    newContact in

    guard let index = self.items.firstIndex(
      where: { $0.contact.id == newContact.id }) else {
      return
    }

    self.items[index] = ContactRow.ContactItem(
      contact: newContact,
      lastMessage: "",
      unread: false)
  }.store(in: &subscriptions)
}

This method adds a sink to the publisher you exposed earlier. When an updated contact appears, you find that contact's index and update it. Because items is a state variable, the view will automatically update.

Finally, call this function from the end of body:

.onAppear(perform: updateContactsOnChange)

Build and run the app and log in as superhero1. All contacts will still be offline because nobody else is using your app yet. You can open another Simulator instance and log in as superhero2.

You'll see the user's online badge turn green. When you exit the app, it will turn grey after a while. Neat!

Messages

Okay, that was enough preamble. It's time to get to the bread and butter of your app: Sending and receiving messages. Thankfully, since you are now fetching contacts as well as listening to contact changes, implementing support for messages will be similar. You'll use the same patterns you used for contacts: A request to fetch existing messages and a subject for when new messages arrive in real-time.

First, you'll add a way to convert CometChat's TextMessage into your own Message. Open Message.swift and import CometChat into the file:

import CometChatPro

Next, add the following extension to the bottom of the file:

extension Message {
  init?(_ message: CometChatPro.BaseMessage) {
    guard let message = message as? TextMessage,
      let sender = message.sender else {
      return nil
    }

    self.id = message.id
    self.text = message.text
    self.contact = Contact(sender)
  }
}

This is an optional initializer that tries to create a Message based on CometChat's TextMessage.

Receiving messages

You'll start by receiving messages from CometChat. The same way you did for your contacts, add two new properties to track new messages:

private let receivedMessageSubject = PassthroughSubject<Message, Never>()
let receivedMessage: AnyPublisher<Message, Never>

Next, erase the subject at the end of init:

receivedMessage = receivedMessageSubject.eraseToAnyPublisher()

You need to set ChatService as CometChat's message delegate. Do so by adding a new line at the top of login:

CometChat.messagedelegate = self

Next, implement this delegate in an extension at the bottom of the file:

extension ChatService: CometChatMessageDelegate {
  func onTextMessageReceived(textMessage: TextMessage) {
    DispatchQueue.main.async {
      guard let message = Message(textMessage) else {
        return
      }

      self.receivedMessageSubject.send(message)
    }
  }
}

When you get a new message, you'll convert it to your own Message struct and send it through the subject.

Now, open ChatView.swift to add code that listens for new messages. First, add an import to the top of the file:

import Combine

Then, fetch AppStore from the environment so you get access to the chat service:

@EnvironmentObject private var store: AppStore

Next, add a set of cancellables to the struct:

@State private var subscriptions: Set<AnyCancellable> = []

With those pieces in place, you can create a new function that listens for new messages:

private func updateMessagesOnChange() {
  store.state.chatService.receivedMessage.sink { message in
    guard message.contact.id == self.receiver.id ||
      message.contact.id == self.currentUser.id else {
      return
    }

    self.messages.append(message)
  }.store(in: &subscriptions)
}

You add a sink to the messages publisher. First, you check that the message is relevant for this view: The message has to either come from the logged-in user, or this screen's receiver. This prevents messages from other users from showing up on this screen. If the message is relevant, you'll add it to the list of messages.

Call this method when the view appears by adding the following line to the bottom of body:

.onAppear(perform: updateMessagesOnChange)

Finally, remove all hard-coded messages from the declaration of messages:

@State private var messages: [Message] = []

You can run the project now to check everything is working, but you have no way of testing receiving messages: You can't send them yet! Let's fix that.

Sending messages

Now that you can receive messages, it's time to start sending them!

Back in ChatService.swift, add a new function to the class:

func send(message: String, to reciever: Contact) {
  guard let user = user else {
    return
  }

  let textMessage = TextMessage(
    receiverUid: reciever.id,
    text: message,
    receiverType: .user)

}

The send(message:to:) function will, naturally, send your messages. It receives the message you'll send as well as the user you're sending it to. In the function, you'll construct a new TextMessage with the necessary information. This is a class from CometChat. Besides text messages, CometChat also supports media messages and even custom messages where you can pass any data you like.

Next, add the following code to the function to send the message:

CometChat.sendTextMessage(
  message: textMessage,
  onSuccess: { [weak self] sentMessage in
    DispatchQueue.main.async {
      self?.receivedMessageSubject.send(Message(
        id: sentMessage.id,
        text: message,
        contact: user))
    }
  },
  onError: { error in
    print("Error sending message:")
    print(error?.errorDescription ?? "")
})

You send the message by calling CometChat's sendTextMessage. If it's sent successfully, you'll add the message to your subject. The view will respond to the message by adding it to the list of messages.

Now you can test this. Run the app and log in as superhero1. When you reach the contacts screen, start chatting with Captain America (superhero2). Launch another simulator instance and, this time, log in as superhero2. Open Iron Man and chat away!

The fact that you're chatting with yourself doesn't make your app any less impressive: You now have a functioning chat app that lets you communicate with another person over a web server! Congrats!

Note: You might notice that, after you get a few messages, new messages appear off-screen. This can be solved by scrolling to the last message whenever a new one appears. In pure SwiftUI, that's easier said than done! Currently, there's no API to manipulate the scroll position of a scroll view. The best way to do this is to wrap UIScrollView in a UIViewControllerRepresentable. This allows SwiftUI to use UIKit's UIScrollView. Check out Apple's official tutorial on how to do this.

Loading past messages

There's only one final thing to add to your app. If you reset the app, all the messages that you sent and received are gone! Don't worry, they're still saved on CometChat — you just need to fetch them.

Back in ChatService.swift, add one final method to the class:

private var messagesRequest: MessagesRequest?
func getMessages(from sender: Contact) -> Future<[Message], Error> {
  let limit = 50

  messagesRequest = MessagesRequest.MessageRequestBuilder()
    .set(limit: limit)
    .set(uid: sender.id)
    .build()

}

Similarly to how you fetched the contacts, you'll create a message request using a builder. In this case, you'll fetch the last 50 messages sent to and from a specific user.

Next, add the following code to the method:

return Future<[Message], Error> { promise in
  self.messagesRequest!.fetchPrevious(
    onSuccess: { fetchedMessages in
      let messages = (fetchedMessages ?? [])
        .compactMap(Message.init)

      DispatchQueue.main.async {
        promise(.success(messages))
      }
    },
    onError: { error in
      let message = error?.errorDescription ?? "unknown"
      print("Fetching messages failed with error:")
      print(message)
      promise(.failure(message))
    })
}

You create a future like before. When you successfully get the messages, you'll send them through the future by calling promise. If something goes wrong, however, you'll send an error.

Now, open ChatView.swift and add a new method:

private func getMessages() {
  store.state.chatService.getMessages(from: receiver)
    .sink(receiveCompletion: { error in
      print(error)
    }, receiveValue: { messages in
      self.messages = messages
    })
    .store(in: &subscriptions)
}

You call the function to get the messages and, on success, update the state variable. On failure, you'll print out an error.

Finally, call this method when the view appears at the bottom of body:

.onAppear(perform: getMessages)

Run the app one final time, login in as superhero1 and start chatting with Captain America. You'll see all of your past messages load.

Conclusion

After 7 parts of this SwiftUI course and, really not that much code, you made a fully working chat app!

Throughout this course you've learned:

How to create, compose and layout SwiftUI views.
How to think in a SwiftUI mindset.
How to manage state in SwiftUI.
How to thread data through your app using Combine.
How to use the Environment.
How to initiate network calls and return Futures.

This is more than you need to start going off on your own and discovering SwiftUI for yourself. But, if you want some more in-depth knowledge, here's some reading material:

Apple's WWDC 2019 sessions on SwiftUI are great learning resources in video form. However, some information may be a little outdated now.
SwiftUI by Tutorials, RayWenderlich.com's book on SwiftUI provides some more in-depth knowledge on SwiftUI and might give a different viewpoint than I did.
Additionally, there's also a bundle of SwiftUI, Combine and Catalyst books, so you can learn everything new and shiny in one go.
SwiftUI by Example is a free online book by Paul Hudson, though might be less in-depth than other resources.

SwiftUI is still fairly young so the biggest learning resource you have is your head. Go out, experiment, challenge yourself and figure stuff out! When you do, don't forget to write about it! (Or at least answer StackOverflow questions. :])

Good luck and have fun on your SwiftUI journeys! If you have any questions, feel free to comment below or message me on Twitter.

SwiftUI Architecture: Observable Objects, the Environment and Combine

marinbenc🐧 — Tue, 11 Feb 2020 07:53:03 +0000

By now you already have a good understanding of how SwiftUI views work. You create a state variable and a body computed variable that spits out a view based on that state. Whenever the state changes, SwiftUI calls body and updates what's on the screen.

This paradigm works incredibly well, but there are some special cases in this paradigm that need extra care. One of those cases is when you want to share a piece of state between two views.

There are a couple of ways to share state in SwiftUI:

Pass the current value of the state in the initializer.
Use a binding.
Use observable environment objects.

In this part of the SwiftUI course, you'll take a look at these ways to share data. You'll get an understanding of when and how to share data, as well as the advantages and disadvantages of these three approaches.

As always, you can find a link to the finished project code on GitHub.

Sharing data with View children and stateless Views

First, let's take a look at the simplest possible way to share data: Passing it in the initializer of a view. You already used the pattern when you created the AvatarView:

let isOnline: Bool

init(url: URL?, isOnline: Bool) {
  ...
  self.isOnline = isOnline
  ...
}

var body: some View {
  ...
  Circle()
    .foregroundColor(isOnline ? .green : .gray)
  ...
}

You gave AvatarView a property called isOnline that you pass in its initializer. You made the online indicator green or gray based on this property.

You later called this initializer from ContactRow with a value of whether the user is online or not:

AvatarView(url: nil, isOnline: item.contact.isOnline)

Because SwiftUI is reactive, whenever the contact's status changes to offline, SwiftUI will know to rebuild the avatar view with the new value.

This isn't anything fancy, it's just plain old Swift initializers. That's the biggest advantage of this approach: Simplicity. Here, AvatarView has no state, all properties are marked with let, which means it's completely immutable. Instead of responding to state changes, it will be rebuilt when the state changes. This type of immutable view has different names in different reactive frameworks: functional, stateless... dumb. (Yes, dumb.)

Using stateless views has a lot of advantages. For starters, they're simple. You don't have to track or debug state changes. You can easily preview and test the view without having to modify its state. Stateless views are decoupled from your frameworks and libraries, whether it's networking with Alamofire or a database framework like Core Data. They're easy to reuse and even copy and paste to different parts of the app or entirely different projects.

As you can see, statelessness is a good thing. You can't always use this pattern, though. To pass state into the initializer, you need to be the view creating the stateless view. If you think of the view hierarchy as a tree, passing state in the initializer is only possible to the view's direct children.

Think hard about whether a view needs to track its internal state variables or if you can get away with passing the state in the initializer. Try to use stateless views as much as you can.

I am creating this course in collaboration with CometChat, a modern chat platform to help you add chat to you Swift app. During the next few weeks, we’ll be releasing installments of our free SwiftUI course here on dev.to! In the course, you’ll dive deep into SwiftUI by building a real-world production-scale chat app, learning SwiftUI in a practical way, on a scale larger than a simple example app. Follow me to get notified of future parts of this course! You can also follow @CometChat on Twitter see the course of CometChat’s blog.

Using `Binding` for two-way data sharing between a view and its children

In families, just like in SwiftUI, parents are usually the ones telling kids the state of the world. Sometimes, however, your dad might not know how to install Viber to call your uncle. In that case, you're the one passing information to your parents.

This happens in SwiftUI too. Passing data in the initializer is great if you want to pass data to the view's children. If you want the reverse, however, you need a binding.

Bindings enable two-way communication between your views. They're usually used with interactive views like text fields, toggles, checkboxes and similar. They allow two views to share a single piece of state.

For instance, when you created ErrorTextField, you used a binding to a String instead of a state variable.

struct ErrorTextField: View {
  ...
  let text: Binding<String>
  ...
}

Later, you initialized this view in the login screen by passing it the binding:

struct LoginView: View {

  @State private var email = ""

  var body: some View {
    ErrorTextField(
      ...
      text: $email,
      ...)
  }
}

In the above code, the $ operator converted a state to a binding. A binding is a kind of pointer to a piece of state. LoginView owns the state, but by giving ErrorTextField a binding to that state, it lets the text field change the value of the state.

This means that both LoginView and ErrorTextField can change the value of the email, and both will always update to match the latest value.

Passing bindings, just like passing the state values directly, is used when you want to share state between a parent view and its direct children. As opposed to passing state values, though, a binding adds statefulness to the component, making it more complex to read, write, test and preview. Keep that in mind when using this approach.

Sharing data between unrelated views

The above two ways of sharing data have all been between two directly linked views. Sometimes, you want to share data between two unrelated screens. For instance, the currently logged in user is shared between the feed, the settings screen and the profile screen. Or, there might be a registration flow with multiple screens that stores the data of each screen at a shared location.

One way to do this is to use bindings or passing the user directly to child views. The disadvantage of that approach is that it's far too cumbersome. You'd have to pass the user to each child separately. For any change that one of the child views make, you'd have to roll back up to the main view to update the user, and then propagate back down the hierarchy so all views update.

Instead, it's much easier to have a single place where the user is stored. Whenever any view changes the user, all other views update instantly.

You can do this type of global state sharing using a combination of Combine and SwiftUI features: Observable objects and environment objects.

Creating Combine's Observable Objects in SwiftUI

Even though this is a SwiftUI course, we'll take a brief detour and talk a little about Combine. Combine is a Swift framework that enables you to track changes to some value over time. Instead of using a plain String, Combine gives you a Publisher that emits a series of strings over time. If you're familiar with RxSwift or ReactiveCocoa, Combine does the same thing, but it's built into Swift.

SwiftUI uses Combine to track changes to state variables. While you might see the email as a String, SwiftUI sees it as a series of different string values over time. Using Combine, it can listen for changes to the value and update the view accordingly.

You can do the same thing SwiftUI does by using Combine's ObservableObject to track changes to any value, whether it's in a View or an entirely different object. ObservableObject object tracks changes to its properties and publishes a Combine event whenever a change occurs.

Let's create a new observable object to track the currently logged in user. Create a new plain Swift file and name it AppStore.swift. No, you're not building the iOS App Store, instead, you're making a shared storage location for different views in your app.

Add the following class to the file:

import SwiftUI
import Combine

class AppStore: ObservableObject {

  struct AppState {
    var currentUser: Contact?
  }

  @Published private(set) var state = AppState(currentUser: nil)

  func setCurrentUser(_ user: Contact?) {
    state.currentUser = user
  }

}

First, you import both Combine and SwiftUI. Then, you declare a class that conforms to the ObservableObject protocol. Inside the class, you write a nested struct that will hold the current user and create a property of that type.

The ObservableObject protocol has one requirement: objectWillChange. This is a Combine Publisher, an object that fires a series of events whenever the observed object changes. Thankfully, you don't have to implement this yourself.

By marking state with @Published, you tell Combine to automatically generate an implementation of objectWillChange that tracks changes to state and publishes an event whenever you change the state. Thanks, Combine!

You also mark the property with private(set). If you haven't seen this before, this is an access control modifier in Swift that makes the property private for modification, but public for access. This means that everyone can read state, but only AppStore can change the state. This is just an insurance policy: When dealing with shared state, it's always a good idea to limit how other objects can change that state.

Finally, you add a method that lets users of this class change the state by setting a new user. Whenever this method is called, currentUser is changed, and AppStore publishes an event telling everyone that's listening that the state has changed.

For instance, a profile screen could listen to these changes and update the user it's showing when a new one is set. Since you can have multiple listeners, different unrelated views can be updated all at once whenever AppState changes.

Adding Observable Objects to the Environment in SwiftUI

Writing the observable object is only one part of the equation, though. You still need a way to create the object and share it with different views in your app. You'll do this using SwiftUI's Environment.

Each view and all of its children exist in an environment. The environment is a shared pool of floating objects and values that the view or any of its children can grab and use at any time.

You'll add an instance of AppStore to the environment of your root view. This will enable any view in your app to grab the store and its data.

Remember, the SceneDelegate is where you create your root view, so open SceneDelegate.swift and add a new property:

let store = AppStore()

This is the store you'll add to the environment. Since you need to add it to your root component, call the environmentObject method on the contentView:

let contentView: some View = NavigationView {
  WelcomeView()
}.environmentObject(store)

This will add the store to the environment.

Now that the store is in there, it's time to fetch it from different views in your app. Start by opening LoginView.swift. Add the following property to the struct:

@EnvironmentObject private var store: AppStore

By declaring the property an @EnvironmentObject, you tell SwiftUI to automatically look for an object of that type in the environment. No need to manually instantiate or look for it!

At the bottom of login, add a line to save a new user in the store:

store.setCurrentUser(Contact(name: "Me", avatar: nil, id: "me", isOnline: true))

When a user logs in, they will get saved in the app store. This same app store is shared with other views, which will update automatically. One of those is ContactsView: Open ContactsView.swift.

Instead of hard-coding a user, you'll change the view to grab the user in the app store. First, fetch the store the same way you did for LoginView:

@EnvironmentObject private var store: AppStore

Then, inside body, replace the ForEach block with a ZStack of the contact row and a navigation link to the chat screen:

List {
  ForEach(0..<items.count) { i in
    // New code from here
    ZStack {
      ContactRow(item: self.items[i])

      self.store.state.currentUser.map { currentUser in
        NavigationLink(destination: ChatView(
          currentUser: currentUser,
          receiver: self.items[i].contact
        )) {
          EmptyView()
        }
      }
    }
    .background(Color.white)
    .shadow(
       color: i == self.items.count - 1 ? Color.shadow : Color.clear,
       radius: 10, x: 0, y: 2)
    .listRowInsets(EdgeInsets())
    // ... to here
    ...
  }
}.navigationBarTitle("Contacts", displayMode: .inline)

You might be confused by the use of map. store.state.currentUser is optional, so you need to unwrap it before you can use it. However, writing if let inside a body will result in a compiler error because Swift will get confused about what kind of view you're trying to make. To get around this, you can use map on the optional. It will work the same way as if let: The function passed to map will only get called if the optional is not nil. If the current user is nil, the function won't get called, and no navigation link will get created.

Build and run the project now.

You now have the app store, an observable object, inside the environment. When you log in, the view will update the store in the environment with a new user. Since the store is an observable object, all other views will get notified of the change. This includes ContactView, which will use the currently logged in user to create a chat screen.

Sharing data like this is perfect for global state of your app, like the currently logged in user, whether or not the user is logged in, does the user have a premium or regular account and other app-level data.

When to use which approach

Stateless views, bindings, environment objects... All of these approaches have advantages and disadvantages and should be used at different times. To give you a better understanding of when to use which, I prepared a little cheat sheet. Don't worry, I won't take your exam away for using it!

Using Combine to track the keyboard height

Run your app and navigate to the chat screen. When you start typing your message, you'll see the keyboard appear. Only, it appears on top of the text field, so you can't even see what you're typing! That's no good. Let's dive further into Combine with another use case for observable objects: Observing the keyboard.

You'll fix this issue by creating an observable object that will listen to NotificationCenter notifications for changes to the keyboard's height. As the keyboard rises or falls, you'll publish events to everyone that's listening.

You'll listen to this event in the chat screen. When the keyboard pops up, you'll increase the padding of the text field so that it's always above the keyboard.

Create a new plain Swift file and call it KeyboardObserver.swift. Add a new ObservableObject class to the file:

import Combine
import SwiftUI

class KeyboardObserver: ObservableObject {
  @Published private(set) var keyboardHeight: CGFloat = 0
}

Just like earlier, you use @Published to automatically publish events whenever that value changes.

You'll update the height based on two notifications: keyboardWillShowNotification and keyboardWillHideNotification. Notification Center has Combine extensions that use Publishers instead of manually subscribing to the notification. Add the following property to the class:

let keyboardWillShow = NotificationCenter.default
  .publisher(for: UIResponder.keyboardWillShowNotification)
  .compactMap { ($0.userInfo?[UIResponder.keyboardFrameEndUserInfoKey] as? CGRect)?.height }

You call publisher(for:) on the default Notification Center to get a publisher that emits that notification's events. Remember, Combine lets you deal with streams of values over time. These streams, just like arrays, are collections. This means that all of the collection methods you're used to, like map, compactMap and others, are already there. In the above example, you use compactMap to get a value from the userInfo of the notification that corresponds to the keyboard's height. This makes keyboardWillShow a stream of CGFloat values over time.

Next, you'll add another property that tracks when the keyboard hides. Add it below the one you just created:

let keyboardWillHide = NotificationCenter.default
  .publisher(for: UIResponder.keyboardWillHideNotification)
  .map { _ -> CGFloat in 0 }

Whenever you receive a notification that the keyboard has hidden, you'll convert that notification to a CGFloat of 0, since a hidden keyboard has no height. Essentially, keyboardWillHide is a stream of zeros.

Now that you are publishing events for those two notifications, it's time to merge them together to update the keyboard height property. Add the following initializer to the class:

init() {
  Publishers.Merge(keyboardWillShow, keyboardWillHide)
    .subscribe(on: RunLoop.main)
    .assign(to: \.keyboardHeight, on: self)
}

keyboardWillShow and keyboardWillHide are both Publishers. Publishers emit values. To listen and respond to those values, you have to subscribe to the publishers. Subscribing allows you to call a function or closure (using the sink method), or update a value whenever a Publisher emits a new event (using assign(to:on:)).

In the above case, you first merge the two publishers into one. That way, you'll get the keyboard's height when it raises and a zero when it falls. You'll subscribe to the new publisher on the main thread because it's responsible for updating the UI. By calling assign, you tell Combine to set keyboardHeight whenever to whichever value the Publisher emits.

At this point, you'll get a warning that the result of assign is unused. This is because assign returns a cancellable that you're not using. A cancellable doesn't do much, it's more of a reference to the subscription. If you used Notification Center, you might remember that you need to eventually remove observers to avoid memory loops. The same is true for Combine: If you don't remove subscriptions from KeyboardObserver, it will never get deallocated.

If you store the cancellable in a property of the class, the cancellable will get deallocated when the class does. Upon deallocation, the cancellable automatically destroys the subscription, removing all reference cycles that were created and letting the object die peacefully, as opposed to going on forever as a zombie.

Add a new property to the class:

private var cancellables: Set<AnyCancellable> = []

This is a Set which will house all of your cancellables for this class.

Next, add the following line to the bottom of init:

.store(in: &cancellable)

This method will store the cancellable in the set. No more warnings, no more memory leaks!

Now that you have the keyboard observer, it's time to use it ChatView.swift. Open the file and add a new property to the struct:

@ObservedObject private var keyboardObserver = KeyboardObserver()

By using @ObservedObject you tell SwiftUI to update the UI whenever the object changes. Next, use the observer to grab the keyboard's height in body:

ZStack {
  Color.background.edgesIgnoringSafeArea(.top)

  VStack {
    List {
      ...
    }

    ChatTextField(sendAction: onSendTapped)
      // These two lines are new:
      .padding(.bottom, keyboardObserver.keyboardHeight)
      .animation(.easeInOut(duration: 0.3))
  }
}.navigationBarTitle(Text(receiver.name), displayMode: .inline)

When the keyboard pops up, you'll raise the text field by the height of the keyboard. Since everything is in a VStack, the List will get shorter automatically. You'll also animate this change by calling animation after padding. SwiftUI will calculate the to and from values to animate without you having to do anything. Pretty neat, right?

Run the project and navigate to the chat screen. As you start typing, you'll see the keyboard pop up and the text field raises to match it. Now you can see what you're typing.

Conclusion

You are now almost done with your chat app! In this section of the SwiftUI course, you went one step further from static, hard-coded values. You used initializers, bindings and observable objects to pass data between your views and breathe a bit of life into your app.

You learned that passing data in the initializer is the simplest way to give a bit of state to a direct child of a view. You also learned that you can use bindings for two-way communication between a child and its parent. Using environment objects, you added global state to your app that any view can access. Finally, using Combine you converted a Notification Center notification into an observable object that updates the UI. All in a day's work, right?

Now that you have an understanding of how to deal with data, there's only one final step: Getting the data. The next section of the SwiftUI course deals with connecting everything up to CometChat, a chat SDK that will let you send and receive messages over the Internet. Keep reading to see your app come to life!

Creating a chat screen in SwiftUI

marinbenc🐧 — Tue, 11 Feb 2020 07:52:42 +0000

A chat app wouldn't be a chat app without a chat screen. In this part of the SwiftUI course, you'll put everything you've learned so far together, and build a cool looking chat screen.

Here's what you'll build:

The chat screen consists of two main views: a list of messages and a text field. Each message contains the user's avatar and a text bubble displaying the message. The text area holds a text field and a send button side-by-side.

Looking at this screen, it might seem like a daunting task to build it. Don't worry! We'll tackle it piece-by-piece. Once you put those pieces together, you'll be surprised at how great everything turned out! Let's get going.

As always, you can find a link to the finished project code on GitHub.

Modifying the avatar

Earlier in the course, you created an avatar view that you can reuse across your app. Now, it's time to reap the benefits of that investment. Instead of recreating a whole new view, you'll slightly tweak the avatar view to fit the needs of the chat message rows.

You'll change the avatar view so that the online indicator can be hidden. Open AvatarView.swift and add a new property to the class:

private let showsOnlineStatus: Bool

You'll use this variable to determine whether or not the online badge will be shown. Set this property to true at the bottom of a new initializer that you'll add to the class:

init(url: URL?, isOnline: Bool) {
  self.url = url
  self.isOnline = isOnline
  showsOnlineStatus = true
}

Next, add another initializer to the class, this time without isOnline:

init(url: URL?) {
  self.url = url
  self.isOnline = false
  showsOnlineStatus = false
}

You will call this initializer when you don't need to know if the user is online or not.

Finally, make a few changes to body to only show the online badge if showsOnlineStatus is set to true:

var body: some View {
  ZStack {
    Image("avatar_placeholder0")
      .resizable()
      .frame(width: 37, height: 37)

    // Wrap the Circle in an if block:
    if showsOnlineStatus {
      Circle()
        .frame(width: 10, height: 10)
        .foregroundColor(isOnline ? .green : .gray)
        .padding([.leading, .top], 25)
    }
  }
}

With that in place, you can get started on creating the message item.

I am creating this course in collaboration with CometChat, a modern chat platform to help you add chat to you Swift app. During the next few weeks, we’ll be releasing installments of our free SwiftUI course here on dev.to! In the course, you’ll dive deep into SwiftUI by building a real-world production-scale chat app, learning SwiftUI in a practical way, on a scale larger than a simple example app. Follow me to get notified of future parts of this course! You can also follow @CometChat on Twitter see the course of CometChat’s blog.

Creating the view for chat messages

By the end of this section, you'll create a view that shows each message the user sends or receives.

When a user sends a message, it will have a blue background and be aligned to the right. If the user receives a message, it will have a white background and come from the left. When you receive or send a couple of messages, only the last one of those will show the avatar. Let's get started!

First, you'll create a new model struct for you messages. Crate a new plain Swift file and name it Message.swift. Add the following to the file:

import Foundation

struct Message: Identifiable {
  let id: Int
  let text: String
  let contact: Contact
}

Just like Contact, you'll make Message identifiable, so that you can later display it in a list view. Now you can start creating the view that shows this message.

Create a new SwiftUI view file and name it ChatMessageRow.swift. Change the struct to the following:

struct ChatMessageRow: View {

  let message: Message
  let isIncoming: Bool
  let isLastFromContact: Bool

}

The struct has three properties. One is the message you'd like to show. The second property determines if the message is incoming or if it was sent out from the currently logged in user. The final property determines if this message was last in a list of multiple messages from a single contact.

[TODO: Screenshot]

The latter two properties will determine the look of this view.

Displaying the content of the message

Instead of having a 300-lines-long body behemoth, you'll make this view piece by piece. You'll create a few computed variables where you'll return parts of the view and then combine those parts in body.

The first part will be the most important part of a message: the content. Add the following computed property to the bottom of the class:

private var text: some View {
  Text(message.text)
    .padding(10)
    .modifier(BodyText())
}

Just like body, you can create computed properties that return some View, and use this pattern to clean up your code so that it's more readable. For now, the text is a simple Text with some padding and styling applied.

Next, fill up body with a horizontal stack containing the avatar view and the text:

var body: some View {
  HStack(alignment: .bottom, spacing: 0) {
    AvatarView(url: message.contact.avatar)
    text
    Spacer()
  }
}

Alongside the two views in the stack, you add a spacer so that everything is aligned to the left. By setting the stack's alignment to .bottom, you make sure the items start at the bottom of the stack.

Before I show you what this looks like, let's modify the preview a bit. Scroll down to the PreviewProvider and add the following property to the struct:

private static let chatMessage = Message(
  id: UUID().hashValue,
  text: "Pellentesque ipsum. Mauris elem enes tumen mauris vitae tortor. Pellentesque ipsum.",
  contact: Contact(name: "Name", avatar: nil, id: "id", isOnline: true))

This is a dummy message that you'll use to preview the view. Next, modify previews to show three different permutations of what your view can look like:

static var previews: some View {
  Group {
    ChatMessageRow(
      message: chatMessage,
      isIncoming: true,
      isLastFromContact: true)
      .previewLayout(.fixed(width: 300, height: 200))

    ChatMessageRow(
      message: chatMessage,
      isIncoming: true,
      isLastFromContact: false)
      .previewLayout(.fixed(width: 300, height: 200))

    ChatMessageRow(
      message: chatMessage,
      isIncoming: false,
      isLastFromContact: true)
      .previewLayout(.fixed(width: 300, height: 200))
  }
}

You create one outgoing, one incoming, and one message row where the message is not the last message from that contact. Take a look at the preview to see your work so far:

That's a good start! You're showing the avatar and the message, but you're missing the bubble around the message.

Showing a chat bubble

To show the chat bubble, you'll use a rounded rectangle view that you'll set as the background of the text view.

To start, add another computed property to ChatMessageRow, right above text:

private var chatBubble: some View {
  RoundedRectangle(cornerRadius: 6)
    .foregroundColor(.white)
    .shadow(color: .shadow, radius: 2, x: 0, y: 1)
}

Remember the shape views I mentioned earlier in the course? Another one of those is RoundedRectangle, perfect for this use case: A chat bubble.

You'll set this chat bubble as the background of the text. Inside text, call the background method with the chat bubble:

Text(message.text)
  .padding(10)
  .modifier(BodyText())
  .background(chatBubble)

In SwiftUI, backgrounds can be infinitely complex. In this case, you're setting it to a rounded rect. You can also set it to colors, image views, other shape views or any other SwiftUI view!

The text now has a background, but to make it a true speech bubble it needs a tail from the user's avatar to the message, like in comic books.

To add this, you'll create a triangular view that you'll place between the avatar and the message in the stack. Add a new function to the struct:

private func chatBubbleTriange(
  width: CGFloat, 
  height: CGFloat, 
  isIncoming: Bool) -> some View {

}

This function receives a width and a height for the chat bubble tail, as well as whether the message is incoming or not. You'll use this information to construct the bubble and return it from the function.

Next, add the following code to the function:

Path { path in
  path.move(to: CGPoint(x: 0, y: height * 0.5))
  path.addLine(to: CGPoint(x: width, y: height))
  path.addLine(to: CGPoint(x: width, y: 0))
  path.closeSubpath()
}
.fill(Color.white)
.frame(width: width, height: height)
.shadow(color: .shadow, radius: 2, x: 0, y: 1)

You use a Path view to construct the triangle. Path is a special type of view that lets you create any arbitrary shape that you can think of.

If this sounds complex, don't worry. Path has a bunch of helper methods to construct shapes like straight lines, arcs, curves, rectangles, ellipses and more. By combining those simpler shapes, you can end up with shapes that would make Kandinsky jealous.

When constructing a path, think of it like drawing with an imagined pen. You move the pen to its start position by calling move(to:). Once it's in position, you can press it down and draw by calling one of the addX methods, where X can be anything from line, arc, curve and other shapes.

In this case, you first move the path to the center-left position of the view. You then draw a line to the top-right corner and then draw a line to the bottom-right corner. Finally, you call closeSubpath which closes the path by drawing a line back to the start position.

Now that you have the tail, add it to body:

var body: some View {
  HStack(alignment: .bottom, spacing: 0) {
    AvatarView(url: message.contact.avatar)

    chatBubbleTriange(width: 15, height: 14, isIncoming: isIncoming)

    text

    Spacer()
  }
}

The shape is good, but the view needs some tweaks. We need to trick the user into thinking the tail is a part of the message bubble. Add the following method calls to the bottom of chatBubbleTriangle:

.zIndex(10)
.clipped()
.padding(.trailing, -1)
.padding(.leading, 10)
.padding(.bottom, 12)

You modify the tail's z-index so that it's above the chat message. You then clip the view so that there's no shadow at the right edge. Finally, you adjust the padding so that it's overlapping with the chat message by one point.

Now it looks like a real speech bubble! This makes you one step closer to a real app since no chat app would be complete without speech bubbles. Let's tweak them a little bit more.

Adding color to the speech bubbles

Next, you'll color outgoing messages blue, and incoming messages white. Start by changing the text color in the text computed variable, so that it's visible on both backgrounds:

Text(message.text)
  .padding(10)
  .foregroundColor(isIncoming ? .body : .white)
  .modifier(BodyText())
  .background(chatBubble)

Make a similar modification to the chat bubble, except you can color it blue if the message is outgoing:

private var chatBubble: some View {
  RoundedRectangle(cornerRadius: 6)
    .foregroundColor(isIncoming ? .white : .cometChatBlue)
    .shadow(color: .shadow, radius: 2, x: 0, y: 1)
}

Finally, you need to match the tail's color to the bubble. In chatBubbleTriangle, replace the first method call to fill with the following line:

.fill(isIncoming ? Color.white : Color.cometChatBlue)

The preview now shows a blue message when it's not incoming. Nice!

Chaining messages

As we discussed earlier, if the same user sends a couple of messages, you'll only show the avatar at the last message. For other messages, you'll show a spacer of the same width as the avatar in its place.

Modify body to add this change:

var body: some View {
  HStack(alignment: .bottom, spacing: 0) {
    if isLastFromContact {
      AvatarView(url: message.contact.avatar)
      chatBubbleTriange(width: 15, height: 14, isIncoming: isIncoming)
    } else {
      Spacer().frame(width: 61)
    }
    text
    Spacer()
  }
}

If the message is last from this contact, you show the avatar and the tail. Otherwise, you show a blank space. Earlier you learned that spacers take up as much space as they can. By modifying the spacer's frame, you make sure it has a fixed width.

Now, only the last message in a chain shows the avatar. We're almost there!

Reversing a horizontal stack in SwiftUI

One final thing you need to tweak is to align outgoing messages to the right. To do this, you'll need to reverse the order of items in the HStack, as well as flip the chat bubble's tail.

You'll start by flipping the tail. Since you built it as a path, you can reverse the x coordinates of the path to mirror the triangle.

In chatBubbleTriangle, reverse the x-axis of the path if the message is outgoing by replacing the Path initializer with the following code:

Path { path in
  path.move(to: CGPoint(x: isIncoming ? 0 : width, y: height * 0.5))
  path.addLine(to: CGPoint(x: isIncoming ? width : 0, y: height))
  path.addLine(to: CGPoint(x: isIncoming ? width : 0, y: 0))
  path.closeSubpath()
}

You'll also need to reverse the padding by replacing the last three lines of the function with the following:

.padding(.trailing, isIncoming ? -1 : 10)
.padding(.leading, isIncoming ? 10 : -1)
.padding(.bottom, 12)

Now your tail is sufficiently flipped.

Next, you'll move on to the stack view by reversing the order of the items in the stack.

Right now, there's no easy way to do this in SwiftUI. The way to do this is to add an if check inside the stack, and repeat the views in the reverse order.

HStack(alignment: .bottom, spacing: 0) {
  if isIncoming {

    if isLastFromContact {
      AvatarView(url: message.contact.avatar)
      chatBubbleTriange(width: 15, height: 14, isIncoming: true)
    } else {
      Spacer().frame(width: 61)
    }
    text
    Spacer()

  } else {

    Spacer()
    text
    if isLastFromContact {
      chatBubbleTriange(width: 15, height: 14, isIncoming: false)
      AvatarView(url: message.contact.avatar)
    } else {
      Spacer().frame(width: 61)
    }
  }
}

Not the cleanest solution, but it's the best we can do right now.

Your messages are now aligned to the right if they're coming from the current user. This concludes creating the message row. You can now take a small break by creating the text field. Or, take a small break, and then create the text field. :)

Creating the chat text field

A chat screen is two things: The messages and a text field. In this section, you'll make a nice looking text field to let the user type in their messages.

Before we get started, you'll need to download another image. Download the send icon from here. Once downloaded, drag and drop the image inside you Assets.xcassets file and name it send_message.

Start creating the text field by creating a new SwiftUI View file called ChatTextField.swift. Add two properties and a method to the struct:

struct ChatTextField: View {

  let sendAction: (String) -> Void

  @State private var messageText = ""

  private func sendButtonTapped() {
    sendAction(messageText)
    messageText = ""
  }

}

The text field will receive a callback to call when the send button gets tapped. It will track the entered text inside a state variable, and pass the text via the callback back to the main chat screen.

Next, modify the preview so that it shows the text field with a bit of spacing on the top:

static var previews: some View {
  VStack {
    Spacer()
    ChatTextField(sendAction: { _ in })
  }.previewLayout(.fixed(width: 300, height: 80))
}

Now you can start working on the view. Inside body, add a horizontal stack that contains a text field and a button to send the message.

var body: some View {
  HStack {
    TextField("Type something", text: $messageText)
      .frame(height: 60)

    Button(action: sendButtonTapped) {
      Image("send_message")
        .resizable()
        .frame(width: 25, height: 25)
        .padding(.leading, 16)
    }
  }
  .padding([.leading, .trailing])
  .background(Color.white)
}

You fix the text field's size to 60 points. In the button, you show the send icon and make sure its size is 25 by 25 points. Finally, you add a bit of padding to the whole stack and give it a white background.

You should do one final modification by adding a shadow to the top of the view. Because you want the shadow only on top, you'll add a new thin rectangular view to the top, and apply a shadow to that rectangle.

var body: some View {
  VStack(spacing: 0) {
    Rectangle()
      .frame(height: 1)
      .foregroundColor(.white)
      .shadow(color: .shadow, radius: 3, x: 0, y: -2)

    HStack {
      ...
    }
    .padding([.leading, .trailing])
    .background(Color.white)
  }
  .frame(height: 60)
}

To add the rectangle, you first wrap the whole view inside of a vertical stack. You add the rectangle to the top of the stack and apply a shadow to the rectangle. You'll also set the VStack's frame to be 60 points high.

Looking good! You now have a text field and a view for each message. It's time to assemble them!

Putting it all together in a chat view

Now, it's time to cash in all of your hard work so far, and put together the pieces to form a great looking chat view.

Create a new SwiftUI view file named ChatView.swift. Add the following properties to the struct:

struct ChatView: View {

  let currentUser: Contact
  let receiver: Contact

}

The chat view will receive two users: One that's currently logged in, and one that the user will chat with.

You'll need to modify the previews to pass values for these two properties:

static var previews: some View {
  ChatView(
    currentUser: Contact(name: "Me", avatar: nil, id: "me", isOnline: true),
    receiver: Contact(name: "Other", avatar: nil, id: "other", isOnline: true))
}

Next, scroll back to the ChatView struct and add the following state property:

@State private var messages: [Message] = [
  Message(id: 0, text: "Morbi scelerisque luctus velit", contact: Contact(name: "Name", avatar: nil, id: "id", isOnline: true)),
  Message(id: 1, text: "Pellentesque ipsum. Mauris elem enes tumen mauris vitae tortor. Pellentesque ipsum. ", contact: Contact(name: "Name", avatar: nil, id: "id", isOnline: true)),
  Message(id: 2, text: "Phasellus enim erat esi, vestibulum veles?", contact: Contact(name: "Name", avatar: nil, id: "me", isOnline: true)),
  Message(id: 3, text: "Lorem ipsum dolor sit amet, consectetuer adipiscing elit.", contact: Contact(name: "Name", avatar: nil, id: "id", isOnline: true)),
  Message(id: 4, text: "Mauris tincidunt sem", contact: Contact(name: "Name", avatar: nil, id: "me", isOnline: true)),
]

These are the messages you'll show on the screen. Right now, you're hard-coding them in the struct. Later, you'll be listening to a WebSocket channel and adding messages to this array as they come in — but that's in a later part of this course.

Now you can add a list of messages to the view. Add a body to the struct:

var body: some View {
  List {
    ForEach(0..<messages.count, id: \.self) { i in
      ChatMessageRow(
        message: self.messages[i],
        isIncoming: self.messages[i].contact.id != self.currentUser.id,
        isLastFromContact: true)
    }
  }
}

As you learned earlier in the course, you combine a ForEach with a List to create a list of ChatMessageRows. You know the message is incoming if the message's sender is different from the current user.

Looks like you're having issues with the table view's separators. You've already learned a trick to deal with these: Using UIAppearance. Add an initializer to the top of the struct:

init(currentUser: Contact, receiver: Contact) {
  self.currentUser = currentUser
  self.receiver = receiver

  UITableView.appearance().tableFooterView = UIView()
  UITableView.appearance().separatorStyle = .none
  UITableView.appearance().backgroundColor = .clear
  UITableViewCell.appearance().backgroundColor = .clear
}

In the initializer, you use the global appearance proxies for the table view to remove the separators. You also remove all background colors from both the table view and the cells. This lets you change the background color in SwiftUI.

Remember that the chat message looks different for chained messages? You'll have to add a way to determine if each message was the lest message sent by a user or just another message in the chain. Add the following method to the struct:

private func isMessageLastFromContact(at index: Int) -> Bool {
  let message = messages[index]
  let next = index < messages.count - 1 ? messages[index + 1] : nil
  return message.contact != next?.contact
}

You fetch the message at that index, as well as the next message. If the next message has a different sender, the current message is the last in the chain.

Next, pass the result of this function to each chat message row. You'll also use this function to modify the spacing between the rows.

List {
  ForEach(0..<messages.count, id: \.self) { i in
    ChatMessageRow(
      message: self.messages[i],
      isIncoming: self.messages[i].contact.id != self.currentUser.id,
      isLastFromContact: self.isMessageLastFromContact(at: i))
      .listRowInsets(EdgeInsets(
        top: i == 0 ? 16 : 0,
        leading: 12,
        bottom: self.isMessageLastFromContact(at: i) ? 20 : 6,
        trailing: 12))
  }
}

If the message is the last in a chain, you'll add a larger spacing to the bottom. You'll also add a bigger top spacing to the first row in the list so that it doesn't bump into the navigation bar.

The list is looking great now! Let's move on to adding the text field you created earlier to the view.

Start by creating a new function that will get called when the text field's send button is tapped:

private func onSendTapped(message: String) {
  // TODO: Send message
}

Next, wrap body in a VStack and add the text field to the bottom of the stack:

VStack {
  List {
    ...
  }

  ChatTextField(sendAction: onSendTapped)
}

When wrapping views inside a stack, Xcode gives you several tricks you can use. If you Command-Click the view, you can select Embed in VStack to wrap a VStack around that view. If you decide to do it manually, by selecting a piece of text and hitting Control-i Xcode will reindent the text for you. Pretty nifty!

Since you made a reusable text field, this one line of code is all you need to add the text field to the view. Good job, you!

Changing the background of a SwiftUI List

Finally, you'll add a background to the screen. Previously, you used the background method to color a view. Another way to do this is to use a ZStack. After all, a ZStack stacks views one on top of the other. If the top view has a clear background, the bottom view will show through and act as a background.

Add the whole body to a ZStack, where you show the background color at the bottom of the stack:

ZStack {
  Color.background.edgesIgnoringSafeArea(.top)

  VStack {
    List {
      ...
    }

    ChatTextField(sendAction: onSendTapped)
  }
}

In SwiftUI, Color is not only a struct that represents a color. It can also be used as a standalone view by itself! You use this fact to add a background color to the ZStack. Because you set the table view's and the cells' background color to .clear, the background shows through them.

Conclusion

Our chat app is starting to take shape! We now have a way to log in, pick a person to chat with and, finally, a way to chat with them. At least, in theory.

The remainder of this course will deal with less visual aspects of your app. The next section will deal with propagating state and data through your app and sharing data between SwiftUI views. Once you master that, you'll move on to networking and hooking your app up to the Internet.

So, unless you want to keep chatting with dummy users forever, keep reading! :)

Creating a list in SwiftUI

marinbenc🐧 — Tue, 11 Feb 2020 07:52:26 +0000

By this part of the course, you've already built a couple of different SwiftUI screens using a bunch of SwiftUI views. You've used Texts, Images, Rectangles, VStacks and HStacks, but there's one type of screen we haven't yet built: A list.

Lists (AKA table views) are at the core of almost all iOS apps. The most popular apps like Instagram, Twitter or Reddit all show a big list of stuff on their main screen. In this part of this SwiftUI course, you'll learn how to show a list of items in SwiftUI.

You'll learn this by building a contacts screen. This screen will show all of the users your current user can chat with. By the end of this part, you'll have a screen that looks like this:

Before you can build that screen, though, you first need a way to navigate to it. Let's get started!

You can always find the finished project code on GitHub.

Navigating to the contacts screen

You'll start by creating a new SwiftUI view file for your contacts screen and naming it ContactsView.swift. Change the struct to the following:

import SwiftUI

struct ContactsView: View {

  var body: some View {
    Text("Contacts")
  }

}

So far it doesn't show much — you'll take care of that later. For now, let's add a way to navigate to this view. Open LoginView.swift and change the navigation link's destination to show the newly created contacts view, instead of EmptyView:

NavigationLink(destination: ContactsView(), isActive: $showContacts) {
  EmptyView()
}

If you run the app now and click the login button, you'll navigate to the view. Now we can fill it up with contacts! Well... in a bit.

I am creating this course in collaboration with CometChat, a modern chat platform to help you add chat to you Swift app. During the next few weeks, we’ll be releasing installments of our free SwiftUI course here on dev.to! In the course, you’ll dive deep into SwiftUI by building a real-world production-scale chat app, learning SwiftUI in a practical way, on a scale larger than a simple example app. Follow me to get notified of future parts of this course! You can also follow @CometChat on Twitter see the course of CometChat’s blog.

What's in a List?

First, we'll lay some groundwork on SwiftUI lists. In SwiftUI, Lists are created by using a view called, shockingly, List. Much like Group or VStack, a List is a sort of wrapper around a bunch of child views. It hugs all of its children in a tight embrace and positions them on the screen, one below the other, with separators, paddings, a scroll view and everything else you'd expect from a list.

SwiftUI's List is backed by a UITableView on iOS, which means that the same cell reuse behavior you're used to is there on SwiftUI, too. Apple is an environmentally conscious company, after all, so cells are recycled.

Instead of loading all of your rows at once, SwiftUI will only take up memory for the rows that are currently visible. As you scroll, the rows that disappear are not destroyed, but instead, go into a pool of deactivated rows. When the list needs a new row, instead of allocating one, it will take one from the pool.

When the list takes a row from the pool, it will apply any necessary changes to its views (text values, images, etc.) to match the item at the current index. This gives the appearance of having many rows, while in reality only a couple are ever loaded at once.

All this is to say that Lists are very fast and memory-efficient, regardless of how many rows there are in the list.

In UIKit, you'd probably first create a table view and then think about placing items in that table. The component-based nature of SwiftUI means you'll have to reverse your thinking: Start from smaller views and work your way up.

That's why you'll first create the view for each row in your list and only then begin assembling the contacts screen.

Note: On websites like StackOverflow, you'll often see people suggesting you replace List with a ScrollView and a ForEach view to achieve a desired look. In some cases, this works well. However, ScrollView will load all the items at once. If you have a lot of items, a plain scroll view will be much less efficient than a List!

Making a SiwftUI List row view

Before we create our items, we need a model struct to house information about each contact. Create a new plain Swift file called Contact.swift. Change the contents to the following:

import Foundation

struct Contact: Identifiable, Equatable {
  let name: String
  let avatar: URL?
  let id: String
  var isOnline: Bool
}

You'll notice Contact conforms to Identifiable. To easily show an array of items in a list, those items need to each have a unique identifier. Remember, rows are reused, so the list needs a way of uniquely identifying each item. You conform to Identifiable by giving the struct an id property that is unique.

To create the row view, create a new SwiftUI View file and name it ContactRow.swift.

This is what you'll end up with:

This view has a few things going on. It shows the avatar with a little online badge, the contact's name, as well as their last message.

As you just learned, it's better to start from smaller views and build up to larger views. That's why you'll start by creating a separate view for the avatar and the online badge.

First, you'll need to add a few placeholder avatars to your app. Download the avatar placeholder image and add it to Assets.xcassets. Name the image avatar_placeholder0.

With that in place, add the view struct to the file:

private struct AvatarView: View {
  // 1
  let url: URL?
  let isOnline: Bool

  var body: some View {
    // 2
    ZStack {
      // 3
      Image("avatar_placeholder0")
        .resizable()
        .frame(width: 37, height: 37)
      // 4
      Circle()
        .frame(width: 10, height: 10)
        .foregroundColor(isOnline ? .green : .gray)
        .padding([.leading, .top], 25)
    }
  }
}

With this code, you create a new SwiftUI view for the avatar. You'll use AvatarView inside the view for the list's row. Here's what's going on in the struct:

The view has two properties, one for the avatar URL and one that tells it whether that contact is online. For now, you'll use placeholder avatars. Later in the course, you'll learn how to fetch them from the internet.
Inside of body, you'll position the image and the online indicator in a ZStack. You've already learned about VStack and HStack. ZStack is similar to those, but in 3D! Instead of arranging items below or to the right of each other, it arranges items on top of each other. This is useful for when you want two views to overlap. In this example, you want the online indicator to be on top of the image.
In the ZStack, you first create an image view with the placeholder and give it a fixed size of 37 by 37 points.
Next, you create a circular view of 10 by 10 points and color it green or gray depending on if the user is online or not. You also position the circle to be in the bottom-right corner of the image.

You'll need to modify the preview to see the view you just created. Scroll down to the PreviewProvider struct and change its content to the following:

struct AvatarView_Previews: PreviewProvider {
  static var previews: some View {
    Group {
      AvatarView(url: nil, isOnline: true)
        .previewLayout(.fixed(width: 100, height: 100))
    }
  }
}

This shows the avatar view in all its glory, with a fixed size, inside a group.

You'll use the group later to show your contact row as well. Speaking of which, let's get on creating that view.

Add another View struct to the same file, underneath AvatarView:

struct ContactRow: View {

  struct ContactItem: Identifiable {
    let contact: Contact
    let lastMessage: String
    let unread: Bool

    var id: String { contact.userID }
  }

  let item: ContactItem

}

This is the view that will be shown in the list. Instead of adding a bunch of properties to the struct, you create a nested struct to house all of the data necessary for displaying a contact.

Again, you use Identifiable to help the list reuse items. In this case, passing along the contact's ID will suffice.

For this to be a complete view, you'll also need to add body to the struct:

var body: some View {
  VStack {
    Spacer()
  }
  .background(item.unread ? 
    Color(red: 236 / 255, green: 240 / 255, blue: 254 / 255) : 
    nil)
  .frame(maxWidth: .infinity)
  .frame(height: 67)
}

To center the contents of the view, you'll place the image and the texts inside a vertical stack. For now, the stack contains only a spacer. You also give the stack a light blue background color if the last message is unread, set its width to stretch out as far as it can and make sure its height is a fixed 67 points.

Next, modify the preview so it shows the contact view underneath the avatar view:

Group {
  AvatarView(url: nil, isOnline: true)
    .previewLayout(.fixed(width: 100, height: 100))

  ContactRow(item: ContactRow.ContactItem(
    contact: Contact(name: "Some Name", avatar: nil, id: "0", isOnline: true),
    lastMessage: "Last message is a pretty big message",
    unread: true))
    .previewLayout(.fixed(width: 300, height: 67))

  ContactRow(item: ContactRow.ContactItem(
    contact: Contact(name: "Other Name", avatar: nil, id: "1", isOnline: false),
    lastMessage: "Last message is a pretty big message",
    unread: false))
    .previewLayout(.fixed(width: 300, height: 67))
}

To test all the variations of the contact view, you'll show one preview where the user is online and the message is unread, and one where the user if offline and the message was already read.

All of this code to display a completely empty view! Let's fix that.

Add the avatar view inside a horizontal stack to ContactRow's body:

var body: some View {
  VStack {
    Spacer()

    HStack {
      AvatarView(url: nil, isOnline: item.contact.isOnline)
        .padding(.leading, 20)

      Spacer()
    }

    Spacer()
  }
  ...
}

You place the avatar in a horizontal stack so that you can add the two text views to the right of the avatar. You also add another spacer to the bottom of the VStack so that everything is vertically centered in the row.

Next, add the two texts to the view between the avatar view and the spacer in the HStack:

VStack {
  ...
  HStack {
    AvatarView(url: nil, isOnline: item.contact.isOnline)
      .padding(.leading, 20)

    // New code:
    VStack(alignment: .leading) {
      Text(item.contact.name)
        .foregroundColor(.body)
        .fontWeight(item.unread ? .medium : .regular)
        .lineLimit(1)

      Text(item.lastMessage)
        .foregroundColor(.body)
        .font(.system(size: 12))
        .fontWeight(item.unread ? .medium : .regular)
        .lineLimit(1)
        .padding(.top, 2)
    }
    .padding(.leading, 10)
    .padding(.trailing, 20)
    // ---

    Spacer()
  }
  ...
}

Place the two texts inside a vertical stack since they're arranged one on top of the other. You'll also limit the number of lines of text to 1, to make sure the text doesn't wrap. Finally, you'll add some padding around the vertical stack so that there's a space between the texts and the image.

That's your contact item! It displays the name, the avatar, the last message as well as if the contact is online or not, all at a glance.

Using SwiftUI Lists

Now, it's time to head over to ContactsView.swift to add a bunch of contacts inside a list.

You'll start by creating a state property that will hold your contacts. For now, fill it up with a couple of fake contacts:

@State private var items: [ContactRow.ContactItem] = [
  .init(
    contact: Contact(name: "Some Name", avatar: nil, id: "0", isOnline: true),
    lastMessage: "This is my last message that I sent you",
    unread: true),
  .init(
    contact: Contact(name: "Other Name", avatar: nil, id: "1", isOnline: false),
    lastMessage: "This is my last message that I sent you",
    unread: false),
  .init(
    contact: Contact(name: "Third Name", avatar: nil, id: "2", isOnline: true),
    lastMessage: "This is my last message that I sent you",
    unread: false)
]

You can use this array to populate a list. Replace body with the following:

var body: some View {
  List(items) { item in
    ContactRow(item: item)
  }
}

To use a List with an array, you can pass the array to the list, as well as a function that will create the view for each row, given the array element for that row. Since you already created your row view, you can just create that view with the contact.

Note: Remember that to show a dynamic array of items in a List, those items need to conform to the Identifiable protocol as described above.

In only three lines of code, you have a list of dynamic items from an array. Take that, UIKit!

Removing separators from a SwiftUI List

However, there is a slight problem with this screen. Instead of a nice-looking list, we have a space and a separator between each item. This happens because SwiftUI uses a plain UITableView to show the list, which has built-in separators and insets.

To change this, you first need to tweak the way you created the list. I showed you a shortcut for creating a list from an array, but there's another way to do it using ForEach. Change body to the following:

var body: some View {
  List {
    ForEach(0..<items.count, id: \.self) { i in
      ContactRow(item: self.items[i])
    }
  }
}

Here, List receives a builder that builds an array of views. You'll build this array using ForEach. ForEach is a special type of view that replaces itself with a list of views, one below the other. In the above code,

ForEach(0..<items.count, id: \.self) { i in
  ContactRow(item: self.items[i])
}

...is exactly the same as writing:

ContactRow(item: self.items[0])
ContactRow(item: self.items[1])
ContactRow(item: self.items[2])

Each of these three views will get treated as a separate row by the list. Again, because a List needs to identify items, you'll pass the current index (self) as the ID of that item.

Note: In UIKit it was somewhat difficult to combine different types of cells. It was especially hard to combine static and dynamic cells. In SwiftUI, since List receives an array of rows, it's very easy to combine static and dynamic content. You can first return a hard-coded row, then a ForEach of a couple of different dynamic rows, then another static one, and so on. A List can hold any combination of static and dynamic rows of different types.

Now that you changed the way you build your list, you can apply a little hack to remove the separators.

Since List is backed by a UITableView, any global changes you make to table views will also apply to SwiftUI lists. UIKit provides an API to make global changes to all instances of a view called UIAppearance. Each UIView subclass has an appearance method that returns something called an appearance proxy. Changing properties of the appearance proxy propagates those changes to all instances of the class, like changing a static property.

You can change the table view's appearance proxy to remove the separators, thus removing all separators from you List.

Add the following initializer to the view struct:

init() {
  UITableView.appearance().tableFooterView = UIView()
  UITableView.appearance().separatorStyle = .none
}

Note: Appearance proxies are not limited to table views. Lots of other SwiftUI views are backed by UIKit views. You can also use this pattern to change the look of navigation bars, toggles, texts and other views.

Keep in mind though, this is a bit of a hack. For now, SwiftUI is backed by UIKit, but this is an implementation detail that you don't want to rely on. Nothing is stopping Apple from ditching UITableView and making their own thing in SwiftUI. I'm showing you this trick because, currently, there's no better way to remove separators.

When the struct loads, it will remove all separators from every table view in the app.

The list now looks much cleaner, but I think it looks better with separators.

Adding custom separators to a SwiftUI List

You might be pulling your hair out by now because you just removed them! Well, SwiftUI is flexible enough that, instead of using UITableView's separators, it's better to make our own using plain SwiftUI views.

Go back the view for your item: ContactRow.swift. Inside body, use a rectangle view at the bottom of the VStack to add separators back in:

  var body: some View {
    VStack {
      Spacer()

      HStack {
        ...
      }

      Spacer()

      // New code:
      Rectangle()
        .frame(height: 1)
        .foregroundColor(Color(UIColor.separator))
    }
    ...
  }

The rectangle will stretch the width of the view by default, all you need to change is to set the height to 1 point and set the color to whichever separator color you'd like.

Head back to ContactView.swift to see your list:

It's already looking great, but there's one small issue I can see. There's still extra space around each item.

Removing space around SwiftUI List rows

SwiftUI adds space around each row in a List by default. This space is called the inset of a list row. The inset is an instance of EdgeInsets, a struct that holds values for how much the view is shifted from the leading, trailing, top and bottom edges.

You can remove the inset by calling listRowInsets on the view inside the list, and giving it a value of EdgeInsets(), where all the values are zero.

Add the following to body:

var body: some View {
  List {
    ForEach(0..<items.count, id: \.self) { i in
      ContactRow(item: self.items[i])
        .listRowInsets(EdgeInsets())
    }
  }
}

Okay, now it's looking perfect.

Except... I'd still like to add one final touch. In the original design, there was a shadow underneath the last item, giving the whole screen a sense of depth that is currently missing.

Adding a shadow to a SwiftUI view

To add a shadow to the row you'll call, you guessed it: shadow. This method takes the color of the shadow, its radius, as well as an x and y value that determines how much the shadow is offset from the view.

SwiftUI adds shadows to opaque parts of the view. That is parts that have some sort of color. Right now, the background of your rows is transparent. It appears white because the color underneath them is white. To show the shadow underneath a row, you need to first color the background in white, and then add the shadow.

Add the following to body:

var body: some View {
  List {
    ForEach(0..<items.count) { i in
      ContactRow(item: self.items[i])
        .listRowInsets(EdgeInsets())
        .background(Color.white)
        .shadow(
          color: i == self.items.count - 1 ? 
            Color(UIColor.black.withAlphaComponent(0.08)) : 
            Color.clear,
          radius: 10, x: 0, y: 2)
    }
  }
}

You set the background color to white and apply a shadow to the view. You only want to add a shadow to the last row, though, so you make the shadow completely transparent if the row is not the last.

Okay, now I'm happy with the look of this screen. Let's run this in the simulator so see it in action.

Oh boy, it looks like you're not off the hook yet! There's one more issue to take care of. The original design shows a title in the navigation bar, which isn't there in our version. Thankfully, that's easy to add.

Adding a navigation bar title in SwiftUI

To add a navigation bar title, you need to call navigationBarTitle on the root view of your body. In your case, that's the list view:

var body: some View {
  List {
    ...
  }.navigationBarTitle("Contacts", displayMode: .inline)
}

By default, SwiftUI adds a large, bold navigation bar title with lots of space around it. You already saw this when you were building your login screen. In this case, you want a more subtle title that is part of the navigation bar. That's why you pass .inline as the display mode, integrating the title with the bar.

Now it looks perfect. No, for real this time. You can take a break and pat yourself on the back, I won't be bothering you with design changes anymore.

Conclusion

You're slowly moving more and more towards a fully-fledged SwiftUI chat app! You built out a contacts screen that shows a list of users.

If you want to know more about SwiftUI lists, here are a few links:

In UIKit, table views can hold sections of items. The same is true for SwiftUI Lists. To organize rows into sections, place a Section view inside a list, and rows inside the section.
There's a couple of different list styles that you can use off the shelf. There's a default list, a plain list, a grouped one (used in the Settings app in iOS), a carousel and one that looks like the lists in an iOS sidebar. You can find all of them here. To change the style of your list, call listStyle on the list.

While the contacts in your list might be hard-coded for now, everything is in place to load these users from the internet — in later parts of this SwiftUI course. So keep reading!

Creating a login screen in SwiftUI

marinbenc🐧 — Tue, 11 Feb 2020 07:52:06 +0000

In the last part of this SwiftUI course, you've learned all about how to create and arrange SwiftUI views to craft beautiful interfaces. In this part, you'll put those skills to test by building out a login screen for your app.

You'll build a login screen with an email field, some information and a button at the bottom. Besides just building the screen, we'll also add a way to navigate from the welcome screen you created in the last part to the new login screen.

Ready to get started?

You can find the finished project code on GitHub.

Kicking things off

To create the login screen, create a new SwiftUI View file called LoginView.swift. For now, change the body to display a text saying "Log In":

struct LoginView: View {

  var body: some View {
    Text("Log In")
  }

}

You'll fill up this placeholder screen later, but you'll first need a way to navigate to the screen.

I am creating this course in collaboration with CometChat, a modern chat platform to help you add chat to you Swift app. During the next few weeks, we’ll be releasing installments of our free SwiftUI course here on dev.to! In the course, you’ll dive deep into SwiftUI by building a real-world production-scale chat app, learning SwiftUI in a practical way, on a scale larger than a simple example app. Follow me to get notified of future parts of this course! You can also follow @CometChat on Twitter see the course of CometChat’s blog.

Navigation in SwiftUI

Two SwiftUI views will help you with navigation: NavigationView and NavigationLink. NavigationView is SwiftUI's version of UINavigationController: It manages a stack of views and shows a navigation bar on top of them.

NavigationLink is similar to a Button, but it triggers presenting a new view in the navigation stack when it's pressed. To work correctly, a NavigationLink needs to be nested inside a NavigationView. In UIKit terms, if NavigationView is the navigation controller, NavigationLink is a segue.

Adding a SwiftUI Navigation View and a navigation bar

In iOS apps, you'd often have one navigation controller that will be the initial view controller of your app. You can achieve a similar effect in SwiftUI by making the initial view a NavigationView.

The initial view is determined by the SceneDelegate. If you look inside SceneDelegate.swift you'll find an implementation of scene(_:willConnectTo:, options:) that creates a content view and adds it to the window.

Instead of creating a plain WelcomeView, change contentView so that you wrap the welcome screen in a navigation view:

let contentView = NavigationView { WelcomeView() }

contentView, just like any other SwiftUI view, can be arbitrarily complex. The scene delegate is a good place to add global configuration, like changing colors, adding routing, subscribing to global events and other changes that affect the whole app.

Run the project now and you'll notice a giant space on the top of your welcome screen.

This space is taken up by an empty navigation bar. Let's look at how to change the look and content of this bar.

Styling the navigation bar in SwiftUI

Let's fill up the navigation bar with a title on the welcome screen. Open WelcomeView.swift, and add a navigation bar title to the top-most VStack:

var body: some View {
  VStack(alignment: .leading) {
    ...
  }
  .navigationBarTitle("Create an account")
}

If you run the project, you might notice there's now two texts saying "Create an account".

Remove the one inside the VStack:

var body: some View {
  VStack(alignment: .leading) {

    /* Remove from here...
    Text("Create an account")
      .modifier(BodyText())
      .padding()
    ... to here*/

    Text("Connect with people around the world")
      .modifier(TitleText())
      .padding([.bottom, .leading, .trailing])

    ...
}

The view looks the same as it did before, but the text is now part of the navigation bar.

Note: If you're wondering how to get the default-looking iOS navigation bar, you can use navigationBarTitle(_:displayMode:) and pass in .inline as the display mode.

Since your view is wrapped inside a NavigationView, you can now use NavigationLink to present the login screen. Wrap the primary button in body inside a NavigationLink (instead of a Button):

var body: some View {
  VStack(alignment: .leading) {

    ...

    VStack(spacing: 30) {
      // Change this line:
      NavigationLink(destination: LoginView()) {
        PrimaryButton(title: "Log In")
      }

      Button(action: { }) {
        SecondaryButton(title: "Sign Up")
      }
    }

    ...
  }
}

Just like Button, NavigationLink will wrap around a view and make it interactable. Instead of calling a function, though, the navigation link will present the provided view when it's tapped.

If you run the project now and tap the log in button, you'll be taken to your login view.

The view inside the navigation link can be anything you want, but be aware that views that respond to touches, like buttons, will consume the touch and it won't propagate to the navigation link. In other words, buttons inside navigation links won't trigger the presentation. Watch out for those hungry buttons, lest they eat your touches!

Making a reusable SwiftUI text field

Now that you can navigate to the login view, you'll start building out that view.

Since you're building a login form, you'll first build a reusable text field that you can use throughout your app. Small reusable views are a leitmotif of SwiftUI apps! Once you're done, it will look like this:

Already you can see the views you'll combine to create this text field. In a vertical stack, you'll need Text for the title, a TextField to edit the text, an Image to show the icon and a way to display the line on the bottom of the view.

Before you start working on the view, let's first add the little email icon. You can find the image here. Drag it over to your Assets.xcassets file and name it email.

Next, create a new SwiftUI View file called ErrorTextField.swift. It's called error text field because you'll add the ability to show an error if the text is invalid. Change the struct to the following:

struct ErrorTextField: View {

  let title: String
  let placeholder: String
  let iconName: String
  let text: Binding<String>
  let keyboardType: UIKeyboardType
  let isValid: (String) -> Bool

  init(title: String,
    placeholder: String,
    iconName: String,
    text: Binding<String>,
    keyboardType: UIKeyboardType = UIKeyboardType.default,
    isValid: @escaping (String)-> Bool = { _ in true}) {

    self.title = title
    self.placeholder = placeholder
    self.iconName = iconName
    self.text = text
    self.keyboardType = keyboardType
    self.isValid = isValid
  }

}

It looks like a lot of code but don't worry — it's a boilerplate initializer that sets up all the necessary properties of the view. You'll need a title and a placeholder, the image name of the icon, a function to validate the text and the keyboard type of the text field.

You'll also need a binding to the text. A binding is similar to a state variable, but it's used to bind data between two different views. For instance, you can provide the text field with a binding to your text. The text field will change the text, and your view will be re-drawn.

Think of binding as a state variable that you can pass to other views. It's kind of like giving someone your phone number and telling them to call you when something changes.

In this case, you'll receive a binding to the text that you'll pass along to the TextField view.

Since this view can show an error, add a computed property that will determine whether an error should be shown:

var showsError: Bool {
  if text.wrappedValue.isEmpty {
    return false
  } else {
    return !isValid(text.wrappedValue)
  }
}

There's no point in showing the error if the text is empty. If the text is not empty, you'll use the provided text validation function to determine if an error should get shown.

Next, create the body for this view by adding the title to a stack:

var body: some View {
  VStack(alignment: .leading) {
    Text(title)
      .foregroundColor(Color(.lightGray))
      .fontWeight(.bold)
  }
}

To make your life easier, you'll also modify the preview to show the different possible states of the text field all at once:

struct ErrorTextField_Previews: PreviewProvider {
  static var previews: some View {
    Group {
      ErrorTextField(
        title: "Email",
        placeholder: "test@email.com",
        iconName: "email",
        text: .constant(""))
        .padding()
        .previewLayout(.fixed(width: 400, height: 100))

      ErrorTextField(
        title: "Email",
        placeholder: "test@email.com",
        iconName: "email",
        text: .constant("some@email.com"))
        .padding()
        .previewLayout(.fixed(width: 400, height: 100))

      ErrorTextField(
        title: "Email",
        placeholder: "test@email.com",
        iconName: "email",
        text: .constant("someemail.com"),
        isValid: { _ in false })
        .padding()
        .previewLayout(.fixed(width: 400, height: 100))
    }
  }
}

Note: You'll notice the text is .constant("some value"). The constant is a factory static function that creates a binding that never changes. It's useful for testing and previews, like in the above example.

Just like in the previous part of this SwiftUI course, you create multiple previews by adding views into a Group.

Now that you can see what you're doing, let's add the text field and the email icon.

Laying out SwiftUI views horizontally

With that out of the way, you can continue building the view by adding the text field and the icon. To make sure the text field and the icon are next to each other, you can use an HStack:

var body: some View {
  VStack(alignment: .leading) {

    Text(title)
      .foregroundColor(Color(.lightGray))
      .fontWeight(.bold)

    // New code:
    HStack {
      TextField(placeholder, text: text)
        .keyboardType(keyboardType)
        .autocapitalization(.none)
      Image(iconName)
        .resizable()
        .aspectRatio(contentMode: .fit)
        .frame(width: 18, height: 18)
    }
  }
}

You're already familiar with VStack. Well, HStack works the same, except horizontally. You arrange a text field and an image in a horizontal stack.

The TextField is the SwiftUI equivalent of UIKit's UITextField, except it's plain by default — which is exactly what we need.

Note: If you want to style a text field to look like a regular UIKit text field, you can call textFieldStyle(RoundedBorderTextFieldStyle()) on the text field. The rounded border style is the one used by the good old UITextField.

In the previous part of this SwiftUI course, you learned about making image views expand to match their parent. In this case, you want the image to have a fixed size. That's why you call frame and pass it an exact width and height.

Displaying basic shape views in SwiftUI

Finally, you'll add the border on the bottom of the text field. Since the border is just a plain rectangular view with no content, you can use a Rectangle:

var body: some View {
  VStack(alignment: .leading) {
    Text(title)
      .foregroundColor(Color(.lightGray))
      .fontWeight(.bold)

    HStack { ... }

    // New code:
    Rectangle()
      .frame(height: 2)
      .foregroundColor(showsError ? 
        .red : 
        Color(red: 189 / 255, green: 204 / 255, blue: 215 / 255))
  }
}

As its name suggests, Rectangle is just, well, a rectangle. Perfect for displaying borders or backgrounds. You set its height to 2 and leave other dimensions up to SwiftUI. You'll also set its color to red if showsError is true, otherwise, you'll use a light gray color.

Rectangle is only one of a few basic shape views. There's also RoundedRectangle, Circle, Capsule and Ellipse. Remember these when you need to draw shapes — there's no need to resort to CAShapeLayer anymore.

You now have a nice looking text field that is flexible enough to be used throughout your app. It's time to put it to action in the login screen!

Creating a SwiftUI login screen

Now, finally, you can get to work on the login screen! Head back to LoginView.swift and change body to the following:

var body: some View {
  VStack(alignment: .leading, spacing: 26) {
    Text("Log In")
      .modifier(TitleText())
  }
  .padding()
}

First, you'll make sure stack view items are aligned to the left edge, just like in the last part of this SwiftUI course. Add a spacing of 26 points between each item and make sure the "Log In" text is styled as a title. You'll also add the system padding to the stack.

Remember that the text field you built receives a validation function? Let's create one that will validate an email. Add the following method to the struct:

private func isValid(email: String) -> Bool {
  let regex = "[A-Z0-9a-z._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,64}"
  let predicate = NSPredicate(format:"SELF MATCHES %@", regex)
  return predicate.evaluate(with: email)
}

This method checks the email string against a regular expression. If the email doesn't contain an @ sign, a dot, and text around both of those, this function will return false.

Also, add a state variable for the entered text:

@State private var email = ""

With those two pieces in place, you can now add a text field for the email to your view:

var body: some View {
  VStack(alignment: .leading, spacing: 26) {
    Text("Log In")
      .modifier(TitleText())

    // New code:
    ErrorTextField(
      title: "Email",
      placeholder: "mail@example.com",
      iconName: "email",
      text: $email,
      keyboardType: .emailAddress,
      isValid: isValid)
  }
  .padding()
}

Most of the properties should be self-explanatory, except maybe this weird $text thing. Don't worry, you're not programming PHP! $ is a special character that converts an @State variable to a binding. Remember, bindings are state variables that can be changed from a different view. In this case, LoginView will pass the email as a binding to ErrorTextField.

Next, create an empty function that you'll call when the user presses the login button:

private func login() {
  // Initiate network request
}

Then, add a spacer and a button that calls this function. As you learned in the previous part of this SwiftUI course, the spacer will expand to make sure everything above it is on top, while the button is on the very bottom of the stack. Add the following to body:

var body: some View {
  VStack(alignment: .leading, spacing: 26) {
    ...

    Spacer()

    Button(action: login) {
      PrimaryButton(title: "Log In")
    }
  }
  .padding()
}

Whenever the button is pressed, SwiftUI will call your login function which, currently, does absolutely nothing.

Don't be disappointed, you'll fix this soon.

Presenting a SwiftUI view asynchronously

Later in this course, login will perform a network request to log the user in and then present a contacts screen. For now, though, you'll navigate to an empty screen when the button is pressed.

Earlier, you learned how to use NavigationLink to present a new view in the navigation stack when a button is pressed. Often, though, you don't want to immidiately go to a new screen. You'll usually want to perform a check, a network request or some other bit of logic, and then present a new screen programmatically when you're done. SwiftUI has a way to do that, but it is a bit clumsy.

First, create a new state variable:

@State private var showContacts = false

You'll navigate to the contacts screen when this variable gets set to true. To do this, you can use a NavigationLink, but differently from before. Instead of wrapping a button in the navigation link, you'll show a hidden link that the user won't see.

You'll also use a different NavigationLink initializer: NavigationLink(destination:isActive:label). The key here is isActive: This is a binding to a bool variable. When it gets set from false to true NavigationLink will know to trigger the presentation.

Add the navigation link to the bottom of body:

var body: some View {
  VStack(alignment: .leading, spacing: 26) {
    ...

    Button(action: login) {
      PrimaryButton(title: "Log In")
    }

    NavigationLink(destination: EmptyView(), isActive: $showContacts) {
      EmptyView()
    }
  }
  .padding()
}

By making navigation link's body an EmptyView you make sure that the user can't see the link. You set its isActive binding to the state variable you created earlier.

Finally, set showContacts to true at the bottom of login:

showContacts = true

When the user presses the login button, SwiftUI calls login, which sets showContacts to true, triggering the NavigationLink, which then presents an empty view in the navigation stack. This Rube Goldberg machine of events is what happens when you try to do an imperative thing, like presenting a view programmatically, in a declarative UI framework.

Presenting multiple SwiftUI views asynchronously

To expand this NavigationLink pattern to multiple views, you'd have to have one state variable for each view you want to present, leading to multiple flags in your view that can be false and true at the same time. This doesn't scale well.

To solve this problem, NavigationLink offers a third initializer: NavigationLink(_:destination:tag:selection:). While the one you used previously has a binding to a Boolean, this initializer is generic. selection is a binding to any Hashable type, like integers, strings and even enums. If the current value of selection matches the value of tag, the link will get triggered.

For instance, let's say you wanted to present either a login or a registration screen based on some logic. You'd start by defining an enum with cases for each of the views you'd like to present.

enum PresentedView {
  case login
  case registration
}

You'll also need a state variable to track which view should be shown:

@State private var viewToPresent: PresentedView?

Then, inside body, you can create hidden navigation links to each of your views.

NavigationLink(
  destination: LoginView(), 
  tag: .login, 
  selection: $viewToPresent) {
  EmptyView()
}

NavigationLink(
  destination: RegistrationView(), 
  tag: .registration, 
  selection: $viewToPresent) {
  EmptyView()
}

When you want to present one of these two views, set viewToPresent to the corresponding value:

viewToPresent = .login

The navigation link will check the bound value, and if it matches its tag, present the view. This solution is easier to scale, so if you have more than one view you'd like to present, I suggest you use this approach.

Conclusion

And there you have it! You've built out a login screen and by doing so you've learned a bunch of important SwiftUI concepts:

How to present and style SwiftUI text fields, as well as how to use basic SwiftUI shape views.
How to use a NavigationView to show and style a navigation bar.
How to push a view when you press a button using NavigationLink.
How to push SwiftUI views programmatically using NavigationLink(destination:isActive) or NavigationLink(destination:tag:selection:).

I'd say that's a good day's work! No need to stop now, though.

In the next part, you'll learn all about SwiftUI lists by building out a contacts screen to show your user's friends. You'll also begin your journey into making network requests!

Your first SwiftUI screen

marinbenc🐧 — Tue, 11 Feb 2020 07:51:44 +0000

SwiftUI is a unifying framework in more ways than one. Whether you're building an Apple Watch, Apple TV, iPhone, iPad or even Mac apps, SwiftUI will let you do that. Whether you're a designer, web developer or simply someone interested in building apps, SwiftUI is still for you. It might take a bit longer than for seasoned iOS veterans, but you'll get the hang of things!

Once you're on the other side of this course, you won't just be an iOS developer you'll be a SwiftUI developer. Capable of building for all Apple platforms!

This course will guide you through building a real-world chat application. You'll build each part of the app including logging the user in, displaying their contacts and chatting over the internet. By building a real app, you'll quickly learn practical SwiftUI skills that you can use in the real world.

In this first part, you'll make a welcome screen for the app. You'll learn about existing SwiftUI views, how to make your own views, how to lay them out and space them as well as how to style them to your liking.

On your way to victory, SwiftUI might try to sabotage you at some point with its opaque error messages or hard-to-find APIs. Remember, fortune favors the brave, so let's dive in with courage!

You can find the finished project of this part of the SwiftUI course here.

Making SwiftUI Views

We'll start our SwiftUI adventure by building out a welcome screen for our app. It will be a static screen with some information, an image and buttons to either log in or sign up to our chat service.

Your first SwiftUI screen!

A SwiftUI app is a huge tree of Views. View is a SwiftUI protocol that represents any view that can be shown on the screen, whether it's a huge detail screen or a simple label.

Let's start by creating a new SwiftUI app. Open up Xcode. For this to work, you'll need Xcode 11 or later.

I am creating this course in collaboration with CometChat, a modern chat platform to help you add chat to you Swift app. During the next few weeks, we’ll be releasing installments of our free SwiftUI course here on dev.to! In the course, you’ll dive deep into SwiftUI by building a real-world production-scale chat app, learning SwiftUI in a practical way, on a scale larger than a simple example app. Follow me to get notified of future parts of this course! You can also follow @CometChat on Twitter see the course of CometChat’s blog.

On the Xcode welcome screen, click Create a new Xcode project. Select the Single View App template under iOS and hit Next. Name the app anything you'd like. I named my app "CometChat". Make sure SwiftUI is selected as the User Interface and click Next again. Select a good location to save the project and click Create.

Congrats! You just made your first SwiftUI app. This is the end of this course. Just kidding.

Next, you'll create a new SwiftUI view. Click File > New > File... and, as the template, select SwiftUI View and name it WelcomeView.

You'll get presented with an almost empty struct, except for one computed property called body. This is the most important part of a view. body returns the contents of your view. iOS will periodically call this computed property to re-draw what's on the screen.

You might have noticed body's type is some View. View is a protocol, and the some keyword tells Swift that body can be any concrete type, as long as it conforms to View.

Change the contents of the struct to the following:

struct WelcomeView: View {

  var body: some View {
    Text("Create an account")
  }

}

On the right of your code, you'll see the Canvas. This is where you can preview the views you're making. If the preview updating is paused, click the Resume button in the top-right corner.

As you make changes to your code, the Canvas will update to show your changes. At least in theory. Often the canvas will be too quick to update and try to compile partially-written code or run into some other issue. You'll get used to clicking Try Again and Resume a lot. :)

Arranging SwiftUI views with stacks

Let's add another label to the view, below the one you just added. You might be tempted to simply add another Text below the current one, but if you do that you'd get a compiler error. The error happens because body is a single View: You can't return two values. Instead, you need a view that would wrap around the two texts, like a SwiftUI birthday present.

SwiftUI has a couple of different views that group other views and the one you'll use the most is VStack and HStack. These are the SwiftUI equivalents to UIKit's UIStackView, stacking for vertical and horizontal stack views, respectively. If you're coming from web development, VStack and HStack are the Flexbox of SwiftUI.

These two views are your primary layout tool in SwiftUI. By arranging items into stacks, nesting stacks within stacks and controlling stack alignment and item spacing you can make almost any layout imaginable.

Let's change body so that it returns a vertical stack of two text views:

var body: some View {
  VStack {
    Text("Create an account")
    Text("Connect with people around the world")
  }
}

You'll see the two labels centered in the middle of the preview screen.

If you look at the screen we're trying to make, though, the two texts need to be aligned to the left and sit on top of the view. You can align items in a stack by passing the alignment in the stack's initializer:

var body: some View {
  VStack(alignment: .leading) {
    Text("Create an account")
    Text("Connect with people around the world")
  }
}

Now the texts are aligned to the left, but they're still not on the top of the screen.

Let's look at how we can fix that.

Vertically aligning VStack items with spacers

The stack's alignment controls the alignment of the items along the opposite axis of the stack, so for VStack, it controls the horizontal alignment. To align items along the major axis you can either manually space the items or use a special view called Spacer.

A Spacer, as its name suggests, is an empty view that stretches out to fill out as much space as it can. When you place it inside a VStack, it will stretch horizontally. If you place it in an HStack, it stretches vertically.

Add a spacer to the bottom of your stack to see what happens:

var body: some View {
  VStack(alignment: .leading) {
    Text("Create an account")
    Text("Connect with people around the world")
    Spacer()
  }
}

If VStack is the birthday present, the spacers are the birthday party balloons, filling up the horizontal space as long as they can, pushing the two text views to the top of the screen.

To get the feel for how spacers behave, experiment by placing spacers at different positions inside the stack. Here are a couple of examples:

As you can see, by placing spacers at different positions you can align and space out your items anywhere in the stack. To fine-tune the spacing, you'll use padding — but you'll read more on that later in this part of the SwiftUI course.

For now, we'll take a break from laying out our view and venture into styling the text.

Styling SwiftUI views with `View` methods

Views have all kinds of methods to tweak their properties, whether its changing their size, colors, state, opacity or anything else that can be changed. Some of these methods are common to all views, like methods for changing the frame or padding. Others are specific to that view, such as the font of a Text or the enabled state of a Button.

According to the screenshot of the view we're building, the second text in our stack needs to have a big and bold font. To make this change, call the font method on the text:

var body: some View {
  VStack(alignment: .leading) {
    Text("Create an account")

    Text("Connect with people around the world")
      .font(Font.largeTitle.weight(.bold))

    Spacer()
  }
}

If you're used to UIKit, you're probably familiar with classes like UIFont or UIColor. SwiftUI has its equivalents, but drops the UI prefix and makes them a struct.

There's also one big difference between the UIKit and SwiftUI versions: SwiftUI's fonts and colors are late binding. This means that a Font is just a token or an identifier for some font. This token only gets resolved to a specific font during runtime, depending on the environment it's running in. For instance, Font.largeTitle gets resolved to San Francisco on iOS, but could be Helvetica on the web.

SwiftUI modifier methods are non-mutating. Instead, they return a new View with the changes applied. This has two consequences. First, you can chain modifier calls one after the other.

Image("welcome")
  .resizable() // returns a new Image
  .aspectRatio(contentMode: .fit) // returns a new View
  .padding(.bottom, 35) // returns a new View

Secondly, because each of these methods creates a new view, the order of calling the methods can sometimes be important. A modifier called later can override what you set earlier, like in CSS or when subclassing a Swift class.

If you're the kind of developer who prefers a GUI over plain code, you can Control-Option-Click a SwiftUI view (either in the code or the preview) and open the SwiftUI Inspector.

This opens up a popup window that will let you tweak the settings of a view. As you make changes, SwiftUI will generate code for those changes and add them to your body.

Changing the color of a SwiftUI Text

While we're beautifying our views, why not add some color. As you can guess by now, adding color is a simple matter of calling a method on the label:

var body: some View {
  VStack(alignment: .leading) {
    Text("Create an account")

    Text("Connect with people around the world")
      .font(Font.largeTitle.weight(.bold))
      .foregroundColor(.accentColor)

    Spacer()
  }
}

Just like Font, Color is also a late-binding token, which means that the actual color value of the color above will depend on the current environment, including what platform it's running on as well as whether it's running in light or dark mode.

Even SwiftUI Colors with specific names like .blue will result in a different color in light and dark mode. These are called adaptive colors, and you can make your own!

Adding your own adaptive colors

You'll add a new color for the text content of your app. Open Assets.xcassets in the main folder of your app in Xcode. Right-click on the list of assets and select New Color Set. At first, you'll see a white color with "Universal" below it. But, if you take a look at the Attributes Inspector, you'll see there's a bunch of different environment combinations you can set.

For instance, you can set one color for CarPlay in dark mode, a different color for Apple TVs in dark mode, and a third color for iPhones.

For now, select only Universal in the Devices list, and Any, Dark in the Appearances dropdown. This allows you to set a different color for light and dark mode on all devices.

Select the Any Appearance color and in the Attributes Inspector select 8-bit Hexadecimal for the Input Method and enter the hex value #2D313F.

For Dark Appearance plain white will suffice. Select the Color in the sidebar and rename it to body. This name is important because that's how we'll access it in code.

Create a new plain Swift file called Colors.swift. Replace the contents of the file with the following:

import UIKit
import SwiftUI

extension Color {
  static let body = Color("body")

  static let cometChatBlue = Color(red: 27 / 255, green: 71 / 255, blue: 219 / 255)
  static let shadow = Color(red: 27 / 255, green: 71 / 255, blue: 219 / 255, opacity: 0.3)
  static let background = Color(red: 248 / 255, green: 249 / 255, blue: 251 / 255)
}

extension UIColor {
  static let body = UIColor(red: 45 / 255, green: 49 / 255, blue: 63 / 255, alpha: 1)
}

This adds new static properties to Color and UIColor. We can use these colors throughout our app without having to copy and paste color names or specific values. Having everything in one place also means we can easily change these colors later.

Now that you have the color you can use it to make your text prettier. Head back to WelcomeView.swift and add a color to the first text:

var body: some View {
  VStack(alignment: .leading) {
    Text("Create an account")
      .foregroundColor(.body)

    Text("Connect with people around the world")
      .font(Font.largeTitle.weight(.bold))
      .foregroundColor(.cometChatBlue)

    Spacer()
  }
}

Extending Color with static properties is a great way to add reusability to our app. You can go a step further to make any changes to a view reusable. Let's do that next.

Styling SwiftUI views with view modifiers

So far you have a title and a body text styled as they look in the screenshot above. You'll use the same text treatment (font and color combination) throughout your whole app. Instead of copying and pasting all the method calls in every View with texts, it would be better to have a way to mark titles and body text in a more reusable way.

SwiftUI lets you do that with View Modifiers. Structs and classes in your app can implement the ViewModifier protocol which has one required method that receives and returns a view. The idea is that you receive a view, perform any necessary transformations and return it back to the caller.

You'll add two modifiers, one for the body text and one for titles. Create another plain Swift file and name it TextModifiers.swift. Add a new view modifier to the file:

import SwiftUI

struct TitleText: ViewModifier {
  func body(content: Content) -> some View {
    content
      .font(Font.largeTitle.weight(.bold))
      .foregroundColor(.cometChatBlue)
  }
}

You implement the required method by receiving a view, applying a new font and foreground color and returning the changed view.

Similarly, add another struct below the one you just created for the body text:

struct BodyText: ViewModifier {
  func body(content: Content) -> some View {
    content
      .foregroundColor(.body)
  }
}

For the body text, you'll leave the font as it is and only change the color. Now, you can go back to WelcomeView.swift and replace the styling you applied with the modifiers by calling the modifier method on the text views:

var body: some View {
  VStack(alignment: .leading) {
    Text("Create an account")
      .modifier(BodyText())

    Text("Connect with people around the world")
      .modifier(TitleText())

    Spacer()
  }
}

You can now use these modifiers in any future views. When you want to change the look of your apps content, you can change the modifier the apply the changes everywhere in your app.

Since view modifiers return a View, you have the complete power of SwiftUI inside a modifier. This means you can even do complex changes like embed the view in a stack, scale it, adjust its spacing, add overlays and make whichever changes you can think of.

Spacing SwiftUI views with padding

I think that's enough styling for now. It's time to get back to laying out our screen with padding. SwiftUI doesn't have Auto Layout or constraints, but that doesn't mean you can't do everything you did in UIKit. It might be even easier. At least sometimes.

The method you use for this is called padding, and it has two optional parameters:

func padding(
  _ edges: Edge.Set = .all, 
  _ length: CGFloat? = nil) 
  -> some View

The first parameter is the set of edges to apply the padding to, while the second is the actual value of the padding. By default, the first parameter applies the padding to all edges. If you omit the length, it will be nil which will apply the default system padding to the view.

Usually, you'd want to apply the default padding. The advantage of the default padding is that it's automatically adjusted to the device you're using. Smaller devices will have a smaller padding and vice-versa.

Change the body of your view to add a padding to both of the texts:

var body: some View {
  VStack(alignment: .leading) {
    Text("Create an account")
      .modifier(BodyText())
      .padding()

    Text("Connect with people around the world")
      .modifier(TitleText())
      .padding([.bottom, .leading, .trailing])

    Spacer()
  }
}

To the body text, you add a default padding to every edge by calling padding(). The title text doesn't need a padding on top, so you add the system padding only to the bottom, leading (left) and trailing (right) edges.

Adding padding to a SwiftUI view

You can combine the first and second parameter of padding to achieve your desired effect. Here are some examples of different ways you can call padding:

padding() applies system padding to all edges.
padding(.leading) applies the system padding to the left edge.
padding([.bottom, .leading, .trailing]) applies the system padding to three edges.
padding(.top, 20) adds a padding of 20 points to the top edge.
padding([.bottom, .top], 0) makes the top and bottom padding zero.

By combining stacks and padding you can intuitively make pixel-perfect layouts. At least, once you get used to it. :)

Nesting SwiftUI stacks

In UIKit, one of the most common view types are stack and table views. The same goes for SwiftUI: Your views will often be a big tree of nested stacks. In the screenshot of the screen you're making there's an image with a text below the two texts you just created.

Both the image and the text are centered, so add another VStack inside the existing one, that you'll center horizontally:

var body: some View {
  VStack(alignment: .leading) {
    Text("Create an account")
      .modifier(BodyText())
      .padding()

    Text("Connect with people around the world")
      .modifier(TitleText())
      .padding([.bottom, .leading, .trailing])

    VStack(alignment: .center) {
      Text("""
        This is a sample app.
        Create an account or login to begin chatting.
        """)
        .modifier(BodyText())
        .multilineTextAlignment(.center)
        .padding([.leading, .trailing], 40)
    }

    Spacer()
  }
}

You add another VStack that will hold the image and the text. The text also has the body text modifier. You make sure the text is centered and add a padding of 40 points on the leading and trailing edges, so it doesn't touch the edges of the screen.

Displaying images in SwiftUI

Now that we added the text that's below the image, it's time to add the image. Image views in SwiftUI are called Image, and they can be tricky to parse at first.

Before you add an image view, you first need to add the image itself. You can find the welcome image here.

Open Assets.xcassets and drag the image into the list of assets. Make sure the name is welcome.

Now, you can add a new Image to the inner VStack:

VStack(alignment: .center) {
  Image("welcome")
    .padding(.bottom, 35)
    .padding([.leading, .trailing], 80)

  Text("""
    This is a sample app.
    Create an account or login to begin chatting.
    """)
    .modifier(BodyText())
    .multilineTextAlignment(.center)
    .padding([.leading, .trailing], 40)
}

You give the Image the name of the asset you created. Give it a padding of 35 points at the bottom (between the image and the text), as well as a padding of 80 on the sides.

The image looks good, but there's a small issue: Our whole UI is now broken.

It would be ideal if the image scaled according to the device size and how much space it has to grow. On an iPhone SE, the image should be smaller than on an 11 Pro Max.

We'll deal with this issue in a second, but let's first take a look at how we can spot issues like this in the future.

Previewing SwiftUI views on a different device

You can tweak the SwiftUI preview to see your views at different sizes. The preview screen isn't magic: It's loaded from a struct in the file that implements PreviewProvider. The preview provider is similar to a View. It has one computed property where you return what should be drawn inside the Canvas.

struct WelcomeView_Previews: PreviewProvider {
  static var previews: some View {
    WelcomeView()
  }
}

You can change this view in the same way you can change any other View. There are also preview-specific methods that control the size and look of the previews.

Call previewDevice inside the previews property and display an iPhone SE:

struct WelcomeView_Previews: PreviewProvider {
  static var previews: some View {
    WelcomeView()
      .previewDevice(PreviewDevice(rawValue: "iPhone SE"))
  }
}

You can now see that the image doesn't scale according to screen size. Let's fix that.

Scaling a SwiftUI Image

To make an Image view resizable you need to, you guessed it, call the resizable method! Add the following two new lines to body:

VStack(alignment: .center) {
  Image("welcome")
    .resizable()
    .aspectRatio(contentMode: .fit)
    .padding(.bottom, 35)
    .padding([.leading, .trailing], 80)

  Text("""
    This is a sample app.
    Create an account or login to begin chatting.
    """)
    .modifier(BodyText())
    .multilineTextAlignment(.center)
    .padding([.leading, .trailing], 40)
}

By default the image will just scale to fill its available space, which you probably don't want. Usually, you want to maintain the image's aspect ratio so that it doesn't look stretched out.

To do that in SwiftUI, you can use the aspectRatio method which receives a parameter telling it how to scale the image. .fit scales the image so that it always fits inside its space, leading to letter-boxing. On the other hand, .fill scales it so that it fills the whole space, but you won't see the whole image.

In the above code, you first call resizable on the image to tell SwiftUI that it can stretch out the image if needed. Then, you call aspectRatio with .fit to make sure the image always fits within the screen, 80 points from each edge.

If you change the device back to iPhone 11 in the preview you'll notice the image now scales to fit its available size, no Auto Layout needed.

We're almost done with our welcome screen! The final step is to add the two buttons on the bottom.

Creating buttons in SwiftUI

To build out a screen like this in UIKit, you'd use a view controller, and house all of your view related things in there. Usually, this is not how you'll build SwiftUI views.

SwiftUI does away with the distinction between view and view controller and it's built so that you compose tons of tiny views to build your screen.

That's what you've been doing: Text, VStack and Image are all small views that do one thing well, but by combining them you've created an already good-looking screen.

Now it's time we make your own small SwiftUI views that you can use throughout the app. These views will be the two buttons you see on the bottom of the screen you're building.

Create a new SwiftUI View file called ButtonViews, and change the struct to the following:

import SwiftUI

struct PrimaryButton: View {

  let title: String

  var body: some View {
    Text(title.uppercased())
  }
}

You need to build a big blue button with rounded corners. You'll start with a good old text view.

A button can hold any other view, no matter how complex. With that in mind, our button is looking a little plain.

At this point, you'll get an error because the automatically generated preview references the wrong view name. Change the preview to show your button:

struct ButtonViews_Previews: PreviewProvider {
  static var previews: some View {
    PrimaryButton(title: "Primary")
  }
}

We'll make it look better, but before we go on, let's do some preview setup to make our lives easier.

Changing the size of a SwiftUI preview

Earlier in this section of the course, you learned how to preview your SwiftUI views on different devices. Most of your views will be reusable UI components, so it doesn't make sense to show a whole iPhone with a tiny view in the middle of a blank screen.

Instead, you can preview them in a small window. Change the preview struct to the following:

struct ButtonViews_Previews: PreviewProvider {
  static var previews: some View {
    PrimaryButton(title: "Primary")
      .previewLayout(.fixed(width: 300, height: 100))
  }
}

Now the preview shows a small rectangle that houses our button.

Nice and neat! Let's get back to our buttons.

Styling SwiftUI buttons

Let's deal with that plain-looking button! Start by adding a background and a shadow to the button:

var body: some View {
  Text(title.uppercased())
    .background(Color.accentColor)
    .cornerRadius(5)
    .shadow(color: .shadow, radius: 15, x: 0, y: 5)
}

Okay, you now have a rounded blue blob, which is a start.

Next, change the color and add some padding around the text:

var body: some View {
  Text(title.uppercased())
    .fontWeight(.bold)
    .foregroundColor(.white)
    .padding()
    .frame(maxWidth: .infinity)
    .background(Color.accentColor)
    .cornerRadius(5)
    .shadow(color: .shadow, radius: 15, x: 0, y: 5)
}

There's one new method here: frame. While padding determines how much space there is around the content, the frame determines how big the content is.

You can either specify a constant size or you can make suggestions to SwiftUI about how it should size the view. Here, you set the maximum width to infinite, making the view stretch to fit the size of its parent.

Our button is looking perfect! Let's add another, secondary button.

Creating the secondary button

To create the secondary button, you'll use a complex programming technique used by generations of programmers: copying and pasting. Because SwiftUI views are short pieces of code that are all in a single struct, you can easily copy and paste a view, modify it slightly and get a whole new look.

For the secondary button, copy over the primary button and change the colors a bit to match the screenshot:

struct SecondaryButton: View {

  let title: String

  var body: some View {
    Text(title.uppercased())
      .fontWeight(.bold)
      .foregroundColor(.accentColor)
      .padding()
      .frame(maxWidth: .infinity)
      .background(Color.white)
      .cornerRadius(5)
      .shadow(color: .shadow, radius: 15, x: 0, y: 5)
  }
}

It looks great... I think. To see the button you need to change your preview first.

Showing multiple SwiftUI previews

You might be tempted to replace Primary with Secondary in the preview and call it a day. But, why show just one view, when you can show both of them at once?

If you wrap the views inside a Group, the Canvas will show each grouped view as a separate preview.

static var previews: some View {
  Group {
    PrimaryButton(title: "Primary")
      .previewLayout(.fixed(width: 300, height: 100))

    SecondaryButton(title: "Secondary")
      .previewLayout(.fixed(width: 300, height: 100))
  }
}

Now you can see both of the buttons at once.

This is especially useful when you have views that can show multiple states. For instance, we can show a preview for buttons that have long titles:

static var previews: some View {
  Group {
    PrimaryButton(title: "Primary")
      .previewLayout(.fixed(width: 300, height: 100))

    PrimaryButton(title: "This button has a really long title")
      .previewLayout(.fixed(width: 300, height: 100))

    SecondaryButton(title: "Secondary")
      .previewLayout(.fixed(width: 300, height: 100))
  }
}

This makes it easy to see how your changes affect different states of your views, making sure you spot a lot of bugs without having to build and click around your app.

Using custom SwitUI views

With our buttons created, let's add them to the welcome screen. Back in WelcomeView.swift, add a new VStack with the two buttons, the final addition to the welcome screen:

var body: some View {
  VStack(alignment: .leading) {
    Text("Create an account")
      .modifier(BodyText())
      .padding()

    Text("Connect with people around the world")
      .modifier(TitleText())
      .padding([.bottom, .leading, .trailing])

    VStack(alignment: .center) { ... }

    // New code:
    VStack(spacing: 30) {
      Button(action: { }) {
        PrimaryButton(title: "Log In")
      }

      Button(action: { }) {
        SecondaryButton(title: "Sign Up")
      }
    }
    .padding([.leading, .bottom, .trailing])
    .padding(.top, 40)
    // ---

    Spacer()
  }
}

You can use your Views just like any other SwiftUI view. After all, they're nothing more than a Swift struct conforming to a protocol. In the above code, you placed your views inside a VStack, and each inside a Button.

As opposed to UIKit's UIButton, Button is a completely blank view. All it does is make its contents touchable and manages button state changes. How the button looks is completely up to you. In the code above, you used PrimaryButton and SecondaryButton to display a button label. Instead of that, you could have used Text, Image or any other SwiftUI view.

Currently, the buttons don't do anything. But, if you run the project and tap on the buttons, you'll notice they light up as you tap them. That animation is coming from Button.

Earlier in this part of the course you used padding to space out views within a stack. If you want the space between each of the items to be the same, you can pass the spacing parameter to a stack's initializer. The stack will then take care of the spacing for you. You can even use padding a spacing in tandem for those pixel-perfect designers among you!

And with that, your welcome screen is done! This now looks exactly like the original screenshot, giving the user some information about the app and a way to log in and register. Right now, these buttons don't do anything. In the next part of this SwiftUI course, you'll navigate to a login and registration screen!

Conclusion

In the span of one part of this course, you went from having no app and no SwiftUI knowledge to building out your first full SwiftUI screen! With this knowledge and some googling, you now have the skills to build almost any static SwiftUI screen.

You know about views, how to create them, lay them out and space them around. You also learned about adding and customizing text, creating buttons and displaying images.

SwiftUI shows its power here: By learning a small number of tools you can build out any UI you can imagine. That's elegant, flexible design.

Your layout knowledge doesn't need to end here, though. For the A-grade students among you, check out the WWDC session called "Building Custom Views with SwiftUI" which goes more in-depth into how the layout system works and some other tricks you can use.

There's still much to learn! You now know how to make static UIs, but in the next part, you'll learn how to navigate to a login screen and manage the state for your UIs. Keep reading to build out the login screen of your app!

SwiftUI: An Introduction

marinbenc🐧 — Mon, 23 Dec 2019 13:30:30 +0000

Apple dropped a bombshell for developers on WWDC 19. Among a bunch of other things, they released SwiftUI — a whole new way of making iOS apps and the biggest change to iOS development since Swift came out. Say goodbye to storyboards, auto-layout or coding your UI by hand, SwiftUI is here to replace all of that. If this sounds good to be true, you might be right. This introduction is here to show you what SwiftUI is all about, how it fits in the existing ecosystem and what it means for iOS developers.

Whether or not you're brave enough to switch to SwiftUI now, the fact is that the future of iOS development is SwiftUI. Currently, SwiftUI is in the same place Swift was a couple of years ago, starting small with a handful of early adopters. But Apple's messaging is pretty clear: Just like Swift, SwiftUI will become the dominant framework in a couple of years.

That's why learning SwiftUI, sooner rather than later, is a valuable (and marketable!) skill for any iOS developer and this introduction is here to get you started.

I am creating this course in collaboration with CometChat, a modern chat platform to help you add chat to you Swift app. During the next few weeks, we’ll be releasing installments of our free SwiftUI course here on dev.to! In the course, you’ll dive deep into SwiftUI by building a real-world production-scale chat app, learning SwiftUI in a practical way, on a scale larger than a simple example app. Follow me to get notified of future parts of this course! You can also follow @CometChat on Twitter see the course of CometChat’s blog.

How SwiftUI Works

To see just how different SwiftUI is from UIKit, let's look at a SwiftUI login screen.

That screen is coded with the following code:

import SwiftUI

struct ContentView: View {

  @State var email = ""
  @State var password = ""
  @State var error: String?

  var body: some View {
    NavigationView {
      VStack {
        TextField("Email", text: $email, onCommit: validate)
          .padding()
          .textFieldStyle(RoundedBorderTextFieldStyle())
          .keyboardType(.emailAddress)
        SecureField("Password", text: $password, onCommit: validate)
          .padding()
          .textFieldStyle(RoundedBorderTextFieldStyle())

        Button(action: login) {
          Text("Sign in")
        }.disabled(error != nil)

        error.flatMap {
          Text("Error: \($0)").foregroundColor(.red)
        }
      }.navigationBarTitle("Log In")
    }
  }

  func validate() { ... }
  func login() { ... }
}

Right now you might not understand everything that's going on in the code above — that's okay. Focus on how much code there is. This is the whole UI. There are no additional storyboards, constraint setup code or UIView subclasses. Even without knowing SwiftUI, you can kind of figure out what the screen looks like and what it does just by looking at the code.

You can think of SwiftUI views as being split between two workers. The workers are each working on their own thing, and only indirectly impacting each other. The first worker renders the UI based on the current state. The other worker takes input from the user and changes the state.

In a SwiftUI View, the state is a variable marked with @State, while the view is a computed variable called body.

struct ContentView: View {
  @State var count = 0

  var body: some View {
    VStack {
      Button(action: { self.count += 1 }) {
        Text("Increment")
      }
      Text("Count: \(count)")
    }
  }
}

You can think of body as a function from the state to the view. The @State annotation tells SwiftUI to listen to changes of that variable. Whenever it changes, SwiftUI will call body to re-render the view based on that new state.

The Body

The syntax inside of body might look strange, like a different language embedded into Swift. In reality, it's all just plain old Swift. There's no compiler magic or special exceptions for SwiftUI: You could implement SwiftUI using plain Swift if you had enough time.

The reason the syntax looks so strange is that it uses implicit [return](https://forums.swift.org/t/se-0255-implicit-returns-from-single-expression-functions/22544)s and function builders, two Swift 5.1 features.

Single-expression functions don't need a return keyword, which is why, in the above example, body can return a VStack even if you don’t write return.

Function builders let you define functions that implicitly return an array as a list of expressions. For instance, if you had a builder for an array of integers, you could write a function like the following:

@NumbersBuilder
func build() -> [Int] {
  1
  2 + 2
  3
}

Swift will then create an empty array, take every top-level expression in the function, evaluate then and add their results to the array, returning [1, 4, 3] for the above example.

Similarly, in the SwiftUI example above, VStack is a struct that receives a function builder of Views in its initializer. Because Swift lets us emit the round brackets around closures, the syntax looks like VStack { ... }. Inside the curly braces, every top-level expression gets evaluated to a list of Views (in this case containing Button and Text) and added to a vertical stack view.

If you remove all syntax sugar from the above body, you'll end up with this:

var body: some View {
  let button = Button(
    action: { self.count += 1 },
    label: { return ViewBuilder.buildBlock(Text("Increment")) })

  let countText = Text("Count: \(count)")

  return VStack(content: {
    return ViewBuilder.buildBlock(button, countText)
  })
}

It looks a lot messier, but you might get a better idea of what the code does this way.

The reason I'm telling you this is because SwiftUI will look daunting at first. You'll also receive very opaque error messages that you that will make you scratch your head in confusion. Knowing that underneath it all lies familiar old Swift will illuminate a lot of these errors for you.

The State

The counter screen example works without any additional code. You'll notice there's no "glue" code anywhere telling SwiftUI to update the counter label with the new text. That's because SwiftUI does that automatically.

By annotating count with @State, SwiftUI knows to call body to reload the view whenever count changes.

This still isn't compiler magic, just plain Swift. The @State annotation is made with a new Swift feature called property wrappers. Property wrappers are structs or classes that hold a single property and expose a setter and a getter, but when used they indistinguishable from a plain value.

By incrementing count (count += 1), you're really calling the setter in the State property wrapper. In other words, the following lines:

@State var count = 0
count += 1

Can be de-sugared to:

let countState = State(initialValue: 0)
countState.wrappedValue += 1

State has a defined setter for wrappedValue that will tell SwiftUI to reload the view. Thankfully, you don't have to write all that. By using property wrappers, SwiftUI lets you use the state as a regular variable, reloading the view automatically on every change.

You might notice an issue here. If we re-render the body every time a tiny change happens, we'll end up rewriting the whole UI every couple of seconds! Thankfully, SwiftUI only updates the views that need updating. The view hierarchy has a tree-like structure, and you can compare the current tree of views with the next one. Only the nodes that are different (and their sub-nodes) need to be updated.

The goal of SwiftUI is to let the system take care of more things, so you can focus on making the app you like.

The Three Tenets of SwiftUI

You'll hear a lot of buzzwords around SwiftUI, both from Apple and the community. To realize what SwiftUI means, it's important to unpack those buzzwords:

Composable

First, SwiftUI is composable. It doesn't separate views from view controllers, instead, your whole UI is made up of Views. This gives you the flexibility to separate your code in any way you see fit. You can have one huge View for your app, or have a huge hierarchy of small Views. This also makes it easier to reuse stuff. Every View can be placed inside every other View, with no need for child view controllers or lifecycle management pains.

This makes SwiftUI development incredibly easy for copy-and-paste development. While seasoned developers might scoff at that sentence, the way people build apps these days is by searching for simple things like "how to make a button" and copying the code.

I built a login screen this way in SwiftUI, without any previous knowledge, in 15 minutes. If I wanted to do that in UIKit, I'd have to spend days reading about Interface Builder, auto-layout and outlets before I could even start coding.

Finding a working example and tweaking it to your needs is incredibly productive, and SwiftUI lets you do that.

Declarative

Secondly, SwiftUI is declarative. Instead of creating a storyboard or creating your UI by instantiating and setting up views, SwiftUI lets you use Swift code to describe your UI. You tell SwiftUI, "I want a black view here, and a red view inside of it." SwiftUI then goes and draws those views for you. And it's all just plain Swift code.

What's frustrating about Storyboards is that they're not code. Everything needs to be constant and pre-determined. You can't dynamically calculate a margin or hide a view based on some condition. In other words, there are no **if**s in a storyboard.

However, the code inside SwiftUI's body is plain Swift. That means that all of Swift's tools are available to you: You can use structs, classes, collections, loops and control blocks to write out your UI. If you want to show an empty state in your list, you can check if the list is empty and show that view, and otherwise show the list.

By giving you the flexibility of Swift, your UI code becomes a lot simpler, and the tension between the Storyboard and your code disappears.

Reactive

Finally, SwiftUI is reactive. If you want to change the color of a button in UIKit, you'd grab the button and directly set its color. SwiftUI doesn't offer this direct control. Instead, you'd have a state variable that defines button's color. You'd also have a different function that returns a new button based on this new variable. Whenever you change the state variable, SwiftUI will automatically call the latter function and draw the new button.

This eliminates a whole class of bugs that come up as a result of a difference between your view controller's state and what's shown on the UI. By letting SwiftUI reload your views automatically, you know that your view's state is the single source of truth for the view. This lets you focus on working only on the state, without having to think of what will happen in your view.

This idea of separating working on your state and your view is a long-standing idea in the iOS community. It's the idea behind the most popular architectural patterns like MVP (Model and Presenter separated from the View), MVVM (Model and View Model separated from the View), VIPER and others. With SwiftUI, you get this separation out of the box.

This combination of features in a single framework isn't new by a long shot. React, Vue.js and Angular — three of the most JavaScript UI frameworks already have these features. With frameworks like Electron, React Native, Jetpack Compose and Flutter, this approach to UI is already here on mobile, in huge apps like Instagram, Uber or Pinterest. This is well-trodden territory and has proved itself to be one of the most productive ways to program UIs.

Thinking SwiftUI

By now you noticed that SwiftUI works a lot differently than UIKit. Just like you can't write Swift as you wrote Objective-C, you can't write SwiftUI like you wrote UIKit. SwiftUI requires a change of mindset.

When looking at a login screen, an iOS developer will first think of a view controller containing two text views and a button. In SwiftUI, you'll instead think of three different Views. First, you'll need a View for the text view. Next, you'll need another View for the button. Finally, you'll need a View that will assemble two text views and the button.

When working with SwiftUI, you'll stop thinking in terms of properties and methods, and start thinking in terms of state. A text view has a state variable that holds the text. Instead of changing textView.text, you'll update the state. The state change will then trigger a call of the body variable, where you'll return a new text field containing the new text.

By starting simple and slowly building out a whole app, this type of thinking will become second-nature by the end of our SwiftUI course.

How Hard is SwiftUI?

I won't lie to you, SwiftUI is completely different than UIKit. When I first started building an app in SwiftUI I had a little identity crisis. Here I was, an iOS developer who has worked on tens of apps, wrote and edited books about iOS, spoke at iOS meetups — struggling with centering a text field.

Over time, though, I found my way around the different types of views. When I get stuck, I knew what to try and where to find the solutions. I realized that, even though my UIKit knowledge isn't of much use, I still understand Swift, the iOS ecosystem and programming. Thankfully, SwiftUI is nothing but Swift! Armed with these skills (and our course!), I'm sure you'll quickly get the hang of SwiftUI.

That's where we come in. During the following few months, we'll be releasing a SwiftUI course that will teach you how to make a complete, production-level SwiftUI app. Read to the end of this article to find out more about the course!

What about UIKit?

You can think of UIKit now as Objective-C a couple of years ago. Even though SwiftUI is the new hotness, it still stands on the shoulders of UIKit (and Objective-C, for that matter). That means that UIKit isn't going away soon.

Slowly, over time, Apple will probably put more and more focus on SwiftUI, until eventually, SwiftUI will be the framework receiving new features instead of UIKit. Don't worry, though, you still have plenty of time.

Speaking of which, the pragmatists among you might want to hold out a little bit until you convert your app to SwiftUI. Just like the early days of Swift, SwiftUI is young and not fully molded into shape. Some things that exist in UIKit are still just plain missing. As SwiftUI evolves and matures, expect a lot of changes and View rewriting.

That isn't to say you shouldn't learn SwiftUI. If you're an iOS developer, knowing SwiftUI (and knowing it early) can help you stand out among other, more conservative developers. Eventually, everybody doing iOS development will need people who know SwiftUI. Getting in early can be a competitive advantage for you or your company.

Should I Use SwiftUI?

You should learn SwiftUI as soon as possible. But, should you convert or start making your app in SwiftUI? The answer is, as it is often, an unsatisfying “it depends”.

SwiftUI is very young and the small SwiftUI community is only starting to grow. Some things that are available in UIKit don't yet exist in SwiftUI, and there are some kinks Apple still needs to work out. I expect SwiftUI to change a little bit in a year's time, which might not be the best thing to hear if you want to convert your whole app.

If you're starting to make an app now and only want to support iOS 13, I'd strongly consider using SwiftUI as much as possible.

If you already have an existing app, it might be more practical to build new views in SwiftUI (and convert a few existing smaller ones) and use UIKit and SwiftUI in tandem, slowly increasing the ratio of SwiftUI code over UIKit. John Sundell seems to agree with this thinking and has some good practical advice on his blog post about how to mix and match SwiftUI with UIKit.

If you decide to go full SwiftUI, be ready for some changes down the line. If you decide to not use SwiftUI at all, don't be surprised when Apple pulls the UIKit rug out from under you sooner than you expect. I suggest going right down the middle and gradually adopting SwiftUI as you go.

Let's get started!

To help you master SwiftUI, we're working on a full SwiftUI course that we'll release over the coming few months.

This SwiftUI course is designed for the practical developer. You'll learn SwiftUI by building our a real-world production-level chat app. You'll see the benefits and disadvantages of SwiftUI on a scale larger than a simple example app. You'll also learn how large SwiftUI apps can be structured and architected, as well as how to leverage other new frameworks like Combine to help you build your apps.

While other courses and Apple's website offer great short examples, diving in deep is the only way to fully learn a framework, and that's what we'll do in this course.

Here's how this course is structured:

SwiftUI: An Introduction (You are here!)
Build your first Swift UI screen
- What's a View?
- Using Previews
- Managing the State
Working with Lists in Swift UI
- Lists and Navigation
- Building the Chat Screen
Build a chat app interface in SwiftUI for iOS
State management with Combine
- State and Binding
- Environment Objects
- Introduction to Combine
Complete the SwiftUI chat app for iOS
- Using Combine for Networking
- Creating Combine Publishers
- Hooking everything up

If you want to receive the next part of the course as soon as it comes out, follow me here, or check out the posts on CometChat's blog!

What Is Message Passing and What Does It Have to Do with the Liver

marinbenc🐧 — Thu, 31 Oct 2019 16:09:11 +0000

It all Starts with the liver...

Let's take a break from programming for a while and talk about biology. More specifically, cells. I promise this will tie into message passing, just stick with me.

This is a repost from programmingwords.com. It’s a blog about about different computer science topics explained in a simple, understandable way. Check it out if you’re interested in compsci, compilers or programming languages! :)

We usually think of our bodies as machinery of bones and organs, pushed and pulled by muscles and neatly wrapped in a layer of skin. But when you zoom in, you'll see a giant sea of about 10 trillion cells that are all chaotically floating around.

There are about 200 different types of cells in your body, each with their specific function. For instance, your kidney is made up of kidney cells, all working together doing... well... whatever a kidney does. (I'm not a biologist.)

Each of these cells is about 100,000 times smaller than you, but somehow this soupy mess of cells manages to work together to move my fingers while I type this sentence. The key, like in all teamwork, is communication.

Cells talk to each other through a process called cell signaling. One type of cell signaling is called endocrine signaling, and you can think of it as Slack, but for cells: It lets remote cells work together.

Let's look at a concrete example: You're stressfully working overtime to meet a deadline. Because you're stressed out, right above your kidneys, the cells of your adrenal gland start releasing a molecule you're familiar with: Adrenaline. Adrenaline is a pretty clear message that says "things are about to get ugly".

Adrenaline travels through your bloodstream all the way to your liver. Your liver cells have receptors that can receive adrenaline. Once they receive the message, they change their behavior in response.

See, the liver is like a storage facility for glucose, your body's primary source of energy. If things are about to get ugly, your body best have enough energy. So, liver cells respond to the message by producing more glucose, giving your muscles enough energy to fight or flight.

Adrenaline is just one of the many molecules that can be sent as a message. Cells communicate by sending and receiving these molecules. A receiving cell has specific receptors which can read those molecules. Once a message is received, the cell makes changes according to the message.

If you take the previous sentence and replace "cell" with "object" you'll get message passing.

What does a liver have to do with programming?

Message passing is a way parts of your program can communicate with each other. With message passing, each object acts as an independent cell. The only thing an object can do to communicate with other objects is to send a message.

In a mainstream OOP language like Java or C#, you'd have objects which define their methods that you call to make changes within those objects. For instance, the following code would call a method called setNumberOfUsers on an object called userStore:

userStore.setNumberOfUsers(3)

Message passing adds another layer of abstraction to this process. With message passing, you'd achieve the same effect by sending a message to the object:

sendMessage(userStore, "setNumberOfUsers:3")

Instead of having a predefined set of methods to call on the object, you send the object an arbitrary message. Whether or not the object responds to that message is up to the object.

In the above example, the message is a simple string. There's no concept of "defined" methods and the compiler won't check that the method exists. Instead, you send a string and it's up to the object to read and respond to the string.

The biggest difference between mainstream OOP and this approach is who owns the methods. In mainstream OOP languages, methods live on the class. To add a new method, you have to create a new (sub-)class.

Message passing takes this one step further by letting the objects themselves decide how to interpret and respond to messages, and which messages to respond to. Two instances of the same class can respond differently to the same message.

This adds a layer of flexibility when modeling your program. Did you ever start writing a class and called currently non-existent methods that you will implement in the future? I do this all the time. With message passing, calling a not-yet-implemented method wouldn't result in any errors. The message would get sent, but simply ignored by the receiving object.

This achieved a level of decoupling that isn't possible with languages like Java. Two pieces of code are decoupled when a change in one doesn't result in having to change the other. With message passing, removing, adding or renaming messages doesn't result in compiler errors. Objects are decoupled to the point of not even depending on the method names.

Mainstream OOP languages ask of you to model your software ahead of time, creating classes and methods before you even use them. Message passing adds enough flexibility that the design of your code can emerge organically and change as needed.

The benefits of message passing are similar to the benefits of dynamic typing. In fact, message passing pretty much requires a dynamically typed language, or at least a lack of type safety in a statically typed language.

A concrete example

Alan Kay is widely credited for being one of the people who coined the term "object-oriented programming". What he invented wasn't what's in Java or C# today, instead, the cornerstone of his OOP was message passing.

Alan Kay's idea, like most ideas, came from a soup of discoveries that all intertwined to create Smalltalk — the programming language that popularized OOP, the most popular programming paradigm ever.

But Smalltalk looks different from Java. First of all, it's dynamically typed. That noise you hear right now is all the Java developers shuddering. It's dynamically typed because it uses message passing. Think about it, you can't have static predefined types if each object can respond to an arbitrary set of messages.

I'm going to show you a bit of Smalltalk now and it will probably look different than any language you've seen. Smalltalk was released around 50 years ago, so its syntax is different from the C-based curly-braced languages we're used to.

We'll start by declaring a variable called num. Variable declarations are surrounded by |. (...for whatever reason.)

| num |

You'll notice there are no type specifiers here -- remember, Smalltalk is dynamic.

We'll then assign a value to this variable:

num := 42.

Like a lot of older languages, Smalltalk uses the more mathematical := for assignment instead of the now more common =. To end a statement, we'll use a dot instead of a semicolon, just like this sentence*.*

Now we're going to raise 42 to the power of 2.

num := num raisedTo: 2.

In a C-based language, this might look like num = pow(num, 2).

Instead, Smalltalk uses message passing. Here, raisedTo: 2 is a message that's sent to the object num. Smalltalk calls the named portion of the messages a selector (raisedTo), which can have their arguments, in this case, the number 2.

Language designers like message passing because of its recursive nature. Once you have message passing, you can build the whole language on top of it. For instance, an if/else expression can be nothing more than sending an ifTrue message to a Boolean object.

numberIs42 := (num = 42)
message := numberIs42
  ifTrue:[ 'answer' ] 
  ifFalse:[ 'not the answer' ].

The above line assigns "answer" to message if num is equal to 42. num = 42 evaluates to a boolean object, which we can send messages to. The ifTrue:ifFalse: message has two arguments which are blocks of code, in this case, each returning a string.

Instead of if and else being special keywords that are built into the syntax of the language, here they're nothing more than simple messages being sent to an object.

Even creating classes is nothing more than sending messages to an object!

Object subclass: 'Square'
  instanceVariables: 'a'

This is how you create a class with the property a. This bit of code sends a message subclass:instanceVariables: to a globally defined object called Object.

Java has to scan through all of your classes and their methods and then compile the code by binding a method call to a block of code. Smalltalk doesn't do any of this at compile-time, instead you send a message to Object to create a class while the program is running. That's right, you can create new classes in the middle of running your code.

Smalltalk's equivalent of Java's methods would be the messages objects of this class can receive. Let's add a couple of those.

a: newA
  a := newA

a:
  ^a

area:
  a * a

init:
  a := 1.

You'll notice there's no properties, methods or fields -- it's all just messages. A "getter" is a message called a that, upon receiving, returns the value of a. Similarly, a setter is a message that includes the new value as part of the message. Even the "constructor" is just a plain old message called init.

Smalltalk, as created by Alan Kay back in 1972, is a lot different than the one above, and even the one above is almost 40 years old. Not a lot of people use Smalltalk, but, through an accident of fate, its spirit still lives on among programmers in a language called Objective-C.

Objective-C was created around the same time as C++ and for a long time, these two languages were competitors for the title of the dominant OOP language. Eventually, as you might have guessed, C++ won out.

But Objective-C lives on mostly because of Steve Jobs. When he left Apple, he founded a company called NeXT and created an operating system based on Objective-C. 12 years later, Apple bought this company and installed Steve Jobs as their CEO, who moved all of their software to NeXT's operating system. The result is that, more than 20 years later, macOS, iOS and other Apple's platforms are built on top of a huge Objective-C codebase.

Objective-C is not the only modern language with message passing, though. Message passing is a core feature of Ruby and Python, and can be used in various other languages with libraries.

The Real OOP?

Throughout this article, I've been juxtaposing mainstream OOP with message passing. But, as you've seen, the term was coined for message passing. As Alan Kay puts it:

I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea.

The big idea is "messaging” [...].

If message passing is what started OOP, how come nobody talks about message passing in this context anymore? None of my college OOP classes mentioned message passing. OOP is always presented as a combination of polymorphism, inheritance, encapsulation and abstraction. These all exist in Smalltalk, but mostly as a symptom of message passing, not baked into the language.

The truth is, around the same time Smalltalk was being designed, another language called Simula was being developed in Oslo, Norway. This language was also an OOP language (in fact, probably the first OOP language), even though it wasn't called that at the start. It didn't have message passing but instead relied on something called abstract data types.

If you worked with any mainstream OOP language, you already know what abstract data types are: classes. Simula introduced almost all of the features we consider part of OOP today including classes, objects, inheritance and even garbage collection.

The biggest difference between Smalltalk and Simula is that Simula used types. Even today, when we have a huge number of advanced linters and tools to help with dynamic programming languages, a lot of programmers still prefer statically typed OOP languages, especially for larger projects. Back then, the tooling around dynamic typing was even less developed, so it stands to reason people found types more productive that the wild west of sending messages and hoping someone, somewhere will receive them.

A lot of CS-nerds will keep reminding you that Alan Kay didn't have C++ in mind when he thought of OOP. Standing here more than 30 years later, I don't think it matters. Terms are there to be useful in communicating an idea, and it seems clear that "OOP" means Java more than it means Smalltalk, even if Alan Kay didn't imagine OOP that way.

Which isn't to say Smalltalk is a failure. Languages, sometimes, are like films. Indie filmmakers are making impactful films like Tarantino's Reservoir Dogs, that a few people see, but their influence is felt for decades. Mainstream films like Avengers, though, are watered-down combinations of those influences, a sort of common denominator that almost everyone will like.

Languages can sometimes be the same way. Even though Java doesn't have message passing, it was still heavily influenced by Smalltalk. In fact, almost all OOP languages were influenced by Smalltalk. Without Alan Kay, the language you program in would probably look different.

This is why it's important to encourage idealistic, vision-driven programming languages. They might look weird, but rest assured there are ideas in them that will surely spread into mainstream languages later down the line.

Note: In mathematics, message passing is known as the actor model. This is a very important model for concurrent programming, but it's a story for another post. :)

References:

An email from Alan Kay describing how he got to Smalltalk's design
http://www.purl.org/stefan_ram/pub/doc_kay_oop_en

Another email on OOP as per Alan Kay

http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html

The Early History of Smalltalk, Alan Kay

(A paper on the history of Smalltalk)

http://www.metaobject.com/papers/Smallhistory.pdf

This is a repost from programmingwords.com. It’s a blog about about different computer science topics explained in a simple, understandable way. Check it out if you’re interested in compsci, compilers or programming languages! :)

What's a Turing Machine? (And Why Does It Matter?)

marinbenc🐧 — Mon, 01 Apr 2019 16:53:23 +0000

You don't always think about mathematicians building stuff like engineers do, but the truth is mathematicians build things all the time. It's just that the things they build exist mostly in their minds (and published papers). They're not concrete things you can look and feel. They do this to prove theorems or properties. Turing did just that when he "built" the Turing machine.

To set the scene, imagine it's around 1928 and no programmable computer was invented yet. But mathematicians did study algorithms and computable things. Since computers were so limited, the only way to figure out universal properties of all programs was to think really hard.

One of those properties of algorithms that they couldn't figure out was something I wrote about before: The Halting Problem. The halting problem asks whether or not you can write a program that can tell if another program will freeze or not. (Spoiler alert: You can't!)

The Halting Problem is hard to solve because there's an infinite amount of programs. To answer it, we need a computer that can execute an infinite amount of programs, and that's what Turing did.

Turing's machine is not a real machine. It's a mathematical model, a concept, just like state machines, automata or combinational logic. It exists purely in the abstract. (Although "real" implementations of the Turing machine do exist, like in this foundational computer science paper.)

How a Turing Machine Works

The Turing machine has three main parts:

The star of the show is an infinite roll of tape. This tape can be written on, and written symbols can be erased or rewritten with different ones.
The thing that's doing the writing is the head. The head can move up and down the tape and write, erase or re-write symbols on the tape. Like the head in a hard disk.
There's also a state register, which is the memory of the machine. It holds the current state the machine is in.

All a Turing machine does is read and write from a piece of tape. At any step, it can write a symbol and move left or right. But even with this limited set of actions it can do all kinds of things. In fact, it can do all the things that any programming language does.

There's a table of instructions that tells the machine what to do and when. This table has five columns. The first column checks the current state the machine is in. The second column checks which symbol is currently below the head of the machine. These two columns determine the different combinations of inputs the machine can have.

The next three columns are the next symbol to be written, where the head should move and what's the next state. These three columns determine the actions performed by the machine for the given first two columns.

For instance, if the machine is currently in state "A", and the head is above the symbol "0", the machine should write "1" in that place and move right, transitioning to state B.

If you follow the instruction table at the top, you'll see that for state A all 0s are replaces with 1s and vice-versa. For B, the 0s and 1s stay the same. A always transitions to B, and B transitions to A. This leads to a machine that will invert every other symbol of a string. So for "1111" you'll get "0101".

Let's look at a more complex example to see how this really works.

That doesn't look like your standard C program, does it? An instruction table doesn't really scale well. A much better way to write a Turing machine is with a diagram like above. If you've ever dealt with automata, this will look familiar.

The image above is a Turing machine that does addition, given a string like "00+000" (2 + 3), it will output "000000" (5).

The circles in the image are states, names Q0 trough Q4. States are connected with arrows that represent transitions from one state to another. On the arrow you see three symbols, like "0, X / R". You can look at the first symbol (in our case "0") as an if condition that checks the current symbol on the tape. If the symbol on the tape is "0", the transition will be performed. If the machine reads a symbol and there's no transition from that symbol in its current state, the machine halts.

The first state is marked with an arrow. The goal of the machine is to move to the final state, a state so nice we circle it twice. If the machine stops anywhere other than the final state, it means either our machine is wrong or our input syntax is wrong. This is similar to a way a compiler validates your code. If it gets stuck before it compiles, it means you have a syntax error.

We define the symbols a Turing machine works with. For this example, we'll use four symbols: "0", "1", "+" and "∅", to represent a blank space.

The second two symbols tell the machine what to do. The first symbol after the comma is what will be written down on the tape. "0, X / R" means "if I'm reading a 0, replace it with X". The symbol after the slash tells the head where to go. R stands for right and, naturally, L stands for left. So in total "0, X / R" means "if you read a 0, replace it with X and move right". Once the transition is performed the machine moves to the next state, the one the transition arrow points to. Every time the machine reads a symbol, it will either move to another state or halt.

Now that we have the fundamentals, let's move trough the process of adding 000 and 00 step by step. Here's a high level overview of what the machine does:

Replace the first 0 with a blank space.
Move to the end of the string.
Add a "0" to the end of the string.
Go back to the start of the string and back to step 1.
If the first symbol is a "+", remove the "+" and complete.

Let's go trough an addition step by step. We take a piece of (imaginary) tape and write on it (with an abstract sharpie) we write "00+000". We give the machine the tape, and position the head at the first 0.

"00+000"
 ^(Q0)

The machine is initially in state Q0. State Q0 has two transitions, one for "0" and another one for "+". The machine reads "0", replaces it with a blank space, and moves right.

" 0+000"
  ^(Q1)

The machine is now in Q1. Again, we have two transitions, and one of them is a loop. Just like in programming languages, Turing machines have loops. The loop replaces all 0s with 0s, and moves right. In other words, it just skips over all the 0s. "X, X / R" is Turing-machine-speak for "skip".

" 0+000"
   ^(Q1)

The machine skipped all the 0s and is now at a "+", but still in Q1. The transition to Q2 simply skips over the "+".

" 0+000"
    ^(Q2)

Now we have similar transitions as in Q1: the machine will first skip over all the 0s in a loop.

" 0+000 "
       ^(Q2)

Once it gets to the blank space, it will replace the blank space with a 0, and move left, transitioning to Q3.

" 0+0000"
      ^(Q3)

Q3 will once again skip over all the 0s until it reaches a "+", but this time moving left. Once "+" is reached, the machine will move left one space and transition to Q4.

" 0+0000"
  ^(Q4)

Q4 will skip over all 0s and transition back to Q0 and move right if it reaches a blank space (i.e. one space past the start of the string).

" 0+0000"
  ^(Q0)

The same loop we just described happens again. Can you see what the machine is doing? Essentially, the machine replaces a 0 in front of "+" with a blank space, moves the head to the end of the string and adds a "0". It then goes back to the first 0 from the left and does the same thing. It keeps doing it until it replaces all 0s left of "+" with blank spaces.

Loop 1: 00+000
Loop 2:  0+0000
Loop 3:   +00000
          ^(Q1)

After three loops the machine finds itself back in Q1, but this time it reads a "+". The final step of the machine replaces the "+" with a blank state and moves to Q5, the final state.

   00000
   ^(Q5)

And there we go! We gave the machine "00+000" and we got "00000". Granted, it's not the most useful calculator ever, but it shows that with such a simple set of tools and rules we can construct a machine that can do calculation! And it works with an arbitrarily long number or 0s!

Why is this important?

Turing didn't come up with a machine. Turing came up with an abstract model for all machines. In other words, any algorithm ever can be built on a Turing machine. From "2 + 2" all the way to the latest Assassin's Creed, a Turing machine can run it. (But the latter will require a lot of tape. Like, a lot a lot.)

It's a theoretical description of computers. This is exactly what Turing used Turing machines for, after all. He thought of them so he can prove properties of computable things in general. Before that, we didn't really know anything about the limits of algorithms. We didn't know what exactly can be computed.

What's cool is that this amazing invention is just a byproduct of Turing trying to answer some fundamental mathematical questions, but in the process he created the basis of all computers we use today.

This all sounds well duh to us sitting here reading this on our general purpose computers. But keep in mind Turing is writing this in 1936. This was before any programmable computers. In fact, at the time, "computer" refered to a person, not a machine. And the thinking at the time was that computers can only be purpose-built for one task. But Turing believed otherwise. He believed that you could build a single machine that can be programmed to do any task. Turns out that was true, because you're currently using one.

The existence of machines with this property has the important consequence that, considerations of speed apart, it is unnecessary to design various new machines to do various computing processes. They can all be done with one digital computer, suitably programmed for each case. - Turing, 1950.

Oh, and did I mention he thought of all this while he was still a 23 year old student? Answering a fundamental question of mathematics and computer science and by doing so inventing an abstract way to describe all computers before they're even a thing is a pretty cool idea for a summer project.

Note: This is a repost from programmingwords.com. It's a blog about about different computer science topics explained in a simple, understandable way. Check it out if you're interested in compsci, compilers or programming languages! :)

References

Turing's paper:

https://londmathsoc.onlinelibrary.wiley.com/doi/abs/10.1112/plms/s2-42.1.230

The Annotated Turing (a great book that explains all of Turing's work better than I did and with historical context)
http://theannotatedturing.com

Turing Machines Explained - Computerphile (video)

https://www.youtube.com/watch?v=dNRDvLACg5Q

Curch-Turing Thesis

https://plato.stanford.edu/entries/church-turing/

Computing Machinery and Inteligence, Turing's paper on machine intelligence

https://www.csee.umbc.edu/courses/471/papers/turing.pdf

Why JavaScript is an OOP Language (Even Though It Doesn't Have Classes)

marinbenc🐧 — Tue, 18 Sep 2018 14:30:53 +0000

You probably know how OOP works. The class Dog inherits from class Animal, which means that if you have a Dog you access methods from Animal. This is actually just a subset of OOP. You can be object oriented without classes, and that's what JavaScript does.

A class is a blueprint. It contains information about what every instance of that class has. It tells you which methods and properties are there and how you can use this class of things.

The class itself doesn't actually contain any data. That's the job of an object. A class is the blueprint for a house, but an object is the actual house, with wood, tiles, bricks and all the weight of an actual house. An instance contains the actual data that is individual only to that instance. You might have used the same blueprint for your house as your neighbor, but that doesn't mean you can sleep in their bed.

The difference between instances and classes is fundamental in the way most people understand OOP. But it's not necessary for OOP. There's a way to do OOP without classes. After all, it's object oriented programming: objects are the star of the show, not classes.

The style of OOP where there is no difference between classes and objects is called prototype-based programming (to make our lives easier, we'll call it PBP).

In PBP, every object can be individual. It contains both its methods and data at the same time. Usually, you can add new properties and methods to an object whenever you feel like it, even while the program is running.

If this sounds like something only a few programmers use for their edge case problems, you'd be surprised. One of the most popular languages in the world is a PBP language: JavaScript.

In JavaScript, there are no classes in the class-based OOP sense of the word. JavaScript works with objects. If you want to encapsulate a few functions and properties together, you would create an object containing functions and properties, and not a class.

const animal = {
    numberOfLegs: 4,
    sleep: () => print("Zzz")
}

This is an object that has a property and a function that does some work. This is different from a class because the function itself is a piece of data that the object has. It's as mutable as the state of a property.

animal.sleep = null

Now, suddenly, animal doesn't have a function anymore. JavaScript doesn't have blueprints, it only has houses.

What About Inheritance, Though?

A fundamental property of a class is that it can inherit methods and properties from other classes. Both a House and Apartment can inherit from Residence to make sure we don't have to duplicate the same code in both classes.

But again, classes are not necessary for inheritance. In PBP inheritance is done completely by using objects.

I mentioned earlier that in PBP an object contains all of its methods and properties, as well as their actual state. So the only way to inherit all of those is by copying (or referencing) all those methods and properties. This is exactly what PBP languages do, and it's called prototypal inheritance.

If we wanted to make a dog object which would have access to the same methods as animal, we can simply make dog contain animal, since the methods are inside of animal.

const dog = {
    prototype: animal,
    bark: () => print("Woof!")
}

If we want to make the dog eat food, we can to this:

dog.prototype.eatFood(10)

Thankfully, JavaScript calls functions on the prototype automatically. If a function doesn't exist on that object, it will search the prototype for the function. The prototype can itself contain another prototype, so JS will search all the way up until it finds the function it's looking for.

The reason why they're called prototype based languages is because a prototype is, as opposed to a class, concrete. A prototype is a working thing, and not a blueprint. You might not want to sell the prototype to millions of customers, but it's a real thing that works. You then use that prototype to construct a bunch of copies that you will actually use. Just like you would in a factory.

The animal object is a prototype of an animal. It's an object like any other, but it will be used to create new, concrete animals, like a dog.

Is This Better Than Classes?

PBP is more straightforward than class-based OOP. It has fewer moving parts and is completely transparent. You can see how it works. Class-based OOP is a layer of abstraction on top of this. This means PBP has a lot of advantages, but also disadvantages.

The main advantage of PBP lies in its flexibility. Blueprints are something that has to be made ahead of time, and they have to be correct. If you're building a house, you will have a lot of trouble if you realize half-way trough building your roof that you forgot to add a window in the blueprint. Classes are similar: you create them before creating and using the objects. You have to know which methods and properties you'll need before you start using it. No matter how good you are at programming, you won't be able to predict everything.

If you don't have to make a class ahead of time, you can immediately start creating your objects. You can adapt them as you're using them without having to pay a large cost. This is very beneficial in programming, where requirements change all the time. You want the ability to change quickly and easily.

But quick and easy change comes with a big risk: correctness. Blueprints exist to plan out a house before it's built, so mistakes are caught early and workers don't get lost while building. If you try to build a house by just doing it and seeing where it leads you, you will probably end up with the house collapsing on top of you. The same goes for programming: you need to make sure your codebase is sound and correct. If everyone can just go in and start changing everything, it will quickly collapse on top of itself.

Like everything in programming, PBP and class-based OOP fall in a spectrum of tradeoffs. On one hand, PBP is flexible and easy to work with, leading to quicker development. On the other hand, class-based OOP is more rigid and sturdy, leading to fewer bugs. Different problems require different tools, and with the knowledge of PBP, you are now better equipped to solve problems that require it. Happy coding!

Note: This is a repost from programmingwords.com. It's a blog that showcases two new terms from computer science every month. Check it out if you're interested in compsci, compilers or programming languages! :)

References:

Prototype based programming

https://en.wikipedia.org/wiki/Prototype-based_programming

Inheritance and the prototype chain - JavaScript

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain

Forem: marinbenc🐧

Implementing Facebook Login on iOS without the Facebook SDK

Facebook Login without the SDK

Initiating an Authentication Session

Getting the authentication code

Getting an access token instead of a code

Storing your login information

Logging out

Checking token validity

Can I log the user in without a backend service?

Sources and further reading

Networking in SwiftUI

Installing CometChat

Setting up

Logging in

Combine's Futures and Promises

Creating a Future

Using Futures

Fetching Contacts from CometChat

Updating a contact's online status in real-time

Converting delegates into Combine publishers with passthrough subjects

Messages

Receiving messages

Sending messages

Loading past messages

Conclusion

SwiftUI Architecture: Observable Objects, the Environment and Combine

Sharing data with View children and stateless Views

Using Binding for two-way data sharing between a view and its children

Sharing data between unrelated views

Creating Combine's Observable Objects in SwiftUI

Adding Observable Objects to the Environment in SwiftUI

When to use which approach

Using Combine to track the keyboard height

Conclusion

Creating a chat screen in SwiftUI

Modifying the avatar

Creating the view for chat messages

Displaying the content of the message

Showing a chat bubble

Adding color to the speech bubbles

Chaining messages

Reversing a horizontal stack in SwiftUI

Creating the chat text field

Putting it all together in a chat view

Changing the background of a SwiftUI List

Conclusion

Creating a list in SwiftUI

Navigating to the contacts screen

What's in a List?

Making a SiwftUI List row view

Using SwiftUI Lists

Removing separators from a SwiftUI List

Adding custom separators to a SwiftUI List

Removing space around SwiftUI List rows

Adding a shadow to a SwiftUI view

Adding a navigation bar title in SwiftUI

Conclusion

Creating a login screen in SwiftUI

Kicking things off

Navigation in SwiftUI

Adding a SwiftUI Navigation View and a navigation bar

Styling the navigation bar in SwiftUI

Making a reusable SwiftUI text field

Laying out SwiftUI views horizontally

Displaying basic shape views in SwiftUI

Creating a SwiftUI login screen

Presenting a SwiftUI view asynchronously

Presenting multiple SwiftUI views asynchronously

Conclusion

Your first SwiftUI screen

Making SwiftUI Views

Arranging SwiftUI views with stacks

Vertically aligning VStack items with spacers

Styling SwiftUI views with View methods

Changing the color of a SwiftUI Text

Adding your own adaptive colors

Styling SwiftUI views with view modifiers

Spacing SwiftUI views with padding

Nesting SwiftUI stacks

Using `Binding` for two-way data sharing between a view and its children

Styling SwiftUI views with `View` methods