![](\"/assets/posts-images/SwiftToolkit.png\")
\n \n\nI’m thrilled to announce that during the the past few months, I’ve been working on a new website: SwiftToolkit.dev. The goal is to share tutorials, guides, cheatsheets and other resources that can be helpful in the tooling, developer experience, and server side Swift domains.
\n\nAlthough there were some unexpected bumps along the way - a devastating ongoing war since October 7th and the loss of a close family member - I finally published the first posts, and here are some of them:
\n\nI’m looking forward to create more content, contribute to the Swift community, and help empowering other developers learn new areas.
\n\n\n \n\nDuring the last month, as part of my work as an iOS Infra engineer at Houzz, I was responsible for moving our CI from a in-house, bare metal setup running TeamCity, to Bitrise. The constant maintenance, hardware limitations, and lack of determinism were the main reasons for this change.
\n\nConnected to the single repository containing the code for both Consumer and Pro apps, we have 6 types of builds: On commit, Nightly, and Release, for both apps. One of the advantages of the TeamCity approach when compared to Bitrise, is that it provides a way to see the status of these 6 builds, while Bitrise displays the builds sorted by time. When I realized we lost this quick and useful overview, I wanted to build something to replace it.
\n\nInitially, I thought of building a web dashboard based on the Bitrise API. Or, possibly, storing the statuses at some server and updating it at the end of every build. But I quickly disregarded it. Requiring our devs to go to another page (specially now that everyone is remote, and displaying it in a TV in the office is not an option) and managing static pages or servers were factors that made me walk way from this idea. Then I thought about displaying a table with the existing and popular build badges, provided by many CI/CD solutions. Throw them in the repository’s Readme in GitHub, and that’s it!
\n\n![](\"/assets/posts-images/20211401-BitriseBadge.png\")
\n \n\nBitrise provides status images, so I thought there would be almost no work: just embed the images in the readme, and that’s it. Shortly after, I realized their Badge API is missing something basic: although it supports querying per branch statuses, it doesn’t for workflow IDs. As the different builds run per workflow, I couldn’t go with this solution.
\n\nEmbedding images in markdown do not support any logic, as they’re simple GET requests. I realized I would need some sort of logic running in a remote server: use the broader Bitrise API, analyze the response, and return an image, or maybe a redirect to Shields.io with the correct parameters.
\n\nBeing able to run code in the cloud on demand seemed the perfect fit for my goal. Instead of managing servers, scaling and loading, many cloud providers do that for you by allocating the hardware resources which will execute your code only when it’s necessary. They take care of the servers running your code, so the industry calls this model serverless. AWS sells it as Lambda, Google Cloud and Azure simply call it Serverless, and even Cloudflare allows having serverless function with their Workers product.
\n\nAlthough I’ve used Lambda in the past for executing Javascript, I wanted to try the Swift implementation of the AWS Lambda Runtime, released a few months ago by the Swift Server Work Group. Besides the runtimes provided by default by AWS (as Node.js, Python, Ruby, Java and Go), one can implement custom runtimes which run on Amazon Linux. Some people have been working on supporting Swift on Lambda for a long time, but finally we have now an official package by the Swift Server group.
\n\nTo get started, you can watch this WWDC20 session by Tom Doron, and also read this post and this post by Fabian Fett, which describes some of the prerequisites, such as installing Docker, setting up an AWS account, and exposing your lambda to HTTP endpoint using API Gateway. Both Tom and Fabian work at Apple and maintain the Swift Lambda Runtime package.
\n\nIf you’re an iOS developer, writing some Lambda functions might be the fastest way to get something up and running to provide remote APIs for your apps. Or, maybe, if you work for a company that has both Android and iOS products, moving some of the code to the cloud might save you from writing parsing logic twice in your app clients.
\n\n\n\n\nNote: this post will focus more on the implementation of the function itself to achieve my goal, rather than on how to deploy lambda functions. You can refer to Fabian’s post linked above if you want to learn how to deploy your Lambda function and connecting it to API Gateway. Lambda and API Gateway are two different services, which can be used together.
\n
My first idea was to read the Bitrise API, querying for a specific workflow ID, and returning a redirect in the lambda response to Shields.io. This is a service that provides badges which can be included in Readmes and other pages. Alongside with ready badges for different services (which do the logic for you), it also allows you creating static badges, without any logic, based on parameters you provide. For example, copy https://img.shields.io/badge/TestBadge-works-green and paste it into the address bar in your browser.
To perform a redirect using the Swift runtime, you can write something like this:
\n\nimport Foundation\nimport AWSLambdaRuntime\nimport AWSLambdaEvents\n\nLambda.run { (context, request: APIGateway.V2.Request, callback: @escaping (Result<APIGateway.V2.Response, Error>) -> Void) in\n let headers = [\"Location\": \"https://img.shields.io/badge/Redirect-Succeeded-orange\"]\n\treturn callback(.success(.init(statusCode: .found, headers: headers)))\n}\nIf you use curl -i to call the /invoke path on localhost, you’ll get the following response:
HTTP/1.1 200 OK\ncontent-length: 102\n\n{\"headers\":{\"Location\":\"https:\\/\\/img.shields.io\\/badge\\/Redirect-Succeeded-orange\"},\"statusCode\":302}\nNotice how the /invoke function returns 200 OK, while the body contains what API Gateway needs. API Gateway will convert the status code and the body into another response. After you deploy the same function, you should integrate the it via API Gateway, and calling it with curl -i will result in the following response:
HTTP/2 302\ndate: Fri, 15 Jan 2021 13:06:29 GMT\ncontent-length: 0\nlocation: https://img.shields.io/badge/Redirect-Succeeded-orange\nNotice how now the status code is 302, found, which is used for redirecting. If you call the same API from the browser, it will handle the redirect for you. So far so good.
\n\nOnce you get this working, adding a method for querying the Bitrise API is straightforward. A single URLRequest call using URLSession is enough:
import Foundation\nimport AWSLambdaRuntime\nimport AWSLambdaEvents\n\n//1\n#if canImport(FoundationNetworking)\nimport FoundationNetworking\n#endif\n\n//2\nstruct ErrorResponse: Codable {\n\tlet error: String\n}\n\n//3\nguard\n\tlet appSlug = Lambda.env(\"APP_SLUG\"),\n\tlet bitriseToken = Lambda.env(\"BITRISE_TOKEN\") else {\n\tfatalError(\"Environment variables not configured\")\n}\n\nLambda.run { (context, request: APIGateway.V2.Request, callback: @escaping (Result<APIGateway.V2.Response, Error>) -> Void) in\n\t//4\n\tguard let workflowId = request.queryStringParameters?[\"workflow_id\"] else {\n\t\tlet error = try? JSONEncoder().encodeAsString(ErrorResponse(error: \"Missing required workflow_id parameter\"))\n\t\treturn callback(.success(.init(statusCode: .badRequest, body: error)))\n\t}\n\n\t//5\n\tlet urlString = \"https://api.bitrise.io/v0.1/apps/\\(appSlug)/builds?sort_by=created_at&workflow=\\(workflowId)&limit=10\"\n\tlet url = URL(string: urlString)!\n\tvar urlRequest = URLRequest(url: url)\n\turlRequest.setValue(bitriseToken, forHTTPHeaderField: \"Authorization\")\n\n\tURLSession.shared.dataTask(with: urlRequest) { data, response, error in\n\t\tguard\n\t\t\tlet data = data,\n\t\t\terror == nil,\n\t\t\tlet buildResponse = try? jsonDecoder.decode(BuildsResponse.self, from: data) else {\n\t\t\treturn callback(.success(.init(statusCode: .badRequest)))\n\t\t}\n\n\t\tguard let build = buildResponse.builds.first(where: { [1, 2, 3, 4].contains($0.status) }) else {\n\t\t\tlet error = try? JSONEncoder().encodeAsString(ErrorResponse(error: \"Build \\(workflowId) not found\"))\n\t\t\treturn callback(.success(.init(statusCode: .badRequest, body: error)))\n\t\t}\n\n\t\t//6\n\t\tlet location: String\n\t\tif build.status.contains(\"success\") {\n\t\t\tlocation = \"https://img.shields.io/badge/\\(workflowId)-Passing-green\"\n\t\t} else {\n\t\t\tlocation = \"https://img.shields.io/badge/\\(workflowId)-Failing-red\"\n\t\t}\n\t\t\n\t\tlet headers = [\"Location\": location]\n\t\treturn callback(.success(.init(statusCode: .found, headers: headers)))\n\t}.resume()\n}\nNotice a few things were added in this sample code:
\n\nURLSession is part of FoundationNetworking, and not Foundation as on iOS and macOS.ErrorResponse is a Codable struct that wraps an error string. Because the API Gateway expects the body parameter as a String, a encodeAsString extension method is used on JSONEncoder, as described by Fabian in the Step 4: JSON section.env(_ name: String) -> String?, which is ideal for accessing environment variables as API tokens and other sensitive parameters. Without these required values, a fatalError is thrown and the Lambda cannot be initialized.queryStringParameters property of APIGateway.V2.Request. If no workflow_id is provided, the function returns with a bad request 400 response.Authorization using the Bitrise API token, also defined in step 3.Once I deployed this function, I got exactly what I wanted. A URL for a badge with the correct status.
\n\nAfter embedding the image URLs with each workflow as a parameter (for example, https://<API-GATEWAY-ID>.execute-api.us-east-1.amazonaws.com/badge?workflow_id=Consumer-OnCommit), I started seeing the badges I wanted. I saw which builds were failing, and after fixing them, I was expecting to see them changing. Except they didn’t: by inspecting the HTML of the GitHub Readme, I noticed that all images had a different URL. Something in the form of http://camo.githubusercontent.com/<Some-Long-ID>.... After a short research, it turned out that GitHub proxies and caches every media in the Readme, which is bad for build badges that constantly might change.
As stated in the GitHub docs, setting the Cache-Control header to no-cache in the response should be enough to avoid caching. However, as my function’s URL only performed a redirect, and static Shields.io badges have max-age=86400 in their Cache-Control header, doing so didn’t help in the end.
I realized I would need to return my own images instead of relying on a redirect to a server I don’t control.
\n\nThe process to return the build badge as an image data would consist creating the images and figuring out what type of response I needed to provide API Gateway with. The first part was relatively easy: figuring out the best colors and shapes in Sketch.
\n\n![](\"/assets/posts-images/20211401-BadgesInSketch.png\")
\n \n\nAfter exporting them, I searched the correct way of returning binary data from a Lambda function with API Gateway. It turns out the data needs to be converted into a Base64 encoded string, and this string passed as the body parameter. Additionally, the key isBase64Encoded needs to be set to true, and API Gateway takes care of converting it from Base64 to binary. To make GitHub load the image correctly, the header Content-Type should be set to image/png or another valid content type.
Because the images are small, and are only 4 in total, I decided to embed them as plain string variables into the code. I used an Xcode playground importing UIKit to convert a UIImage from resources into Base64. I copied the results from the playground console into something like this:
let consumerPassing = \"iVBORw0KGgoAAAANSUhEUgA...\" //a long string\nlet proPassing = //similar\nlet consumerFailing = //similar\nlet proPassing = //similar\nOnce the strings were ready, it was it was left to find the correct image and wrap it in the response:
\n\n//decide the image based on the build response and workflow id\nlet base64Image = build.statusText == \"success\" ? consumerPassing : consumerFailing\n\nlet headers = [\"Cache-Control\": \"no-cache\", \"Content-Type\": \"image/png\"]\nlet response = APIGateway.V2.Response(statusCode: .ok, headers: headers, body: base64Image, isBase64Encoded: true)\nreturn callback(.success(response))\nWith the code above deployed, calling my Lambda function returned an image which could be embedded in the Readme:
\n\n![](\"/assets/posts-images/20211401-BadgesReadMe.png\")
\n \n\nAfter the mini dashboard was live, I had another idea, which could be the cherry on top. What if clicking the badges would take the developer straight to the page of the build. This could save them from searching the build in the list of builds. And after all, by using the Bitrise API, I had all the information I needed.
\n\nOne of the advantages of using API Gateway, is that you can integrate your lambda with many routes. For example, you can have <Url-Host>/badge and <Url-Host>/link using the same lambda, and deal with the routing on the lambda itself. This is exactly what I did.
On the API Gateway dashboard, I added two GET routes: one for /badge, and another one for /link. Under Integrations, I connected both routes to my lambda function, and inside my function, instead of returning the image right away, I did the following:
Lambda.run { // ...\n\t//decode workflow_id...\n\t\n\tURLSession.shared.dataTask(with: urlRequest) { data, response, error in\n\t\t//decode build data...\n\t\t\n\t\tswitch request.context.http.path {\n\t\tcase \"/badge\":\n\t\t\tretrieveImage(for: build, workflowId: workflowId, callback: callback)\n\t\tcase \"/link\":\n\t\t\tredirect(to: build.slug, callback: callback)\n\t\tdefault:\n\t\t\tlet error = try? JSONEncoder().encodeAsString(ErrorResponse(error: \"Invalid path: \\(request.context.http.path)\"))\n\t\t\treturn callback(.success(.init(statusCode: .notFound, body: error)))\n\t\t}\n\t}\n}\n\nBelow that, I inserted the two functions called from the switch statement:
\n\nfunc redirect(to buildSlug: String, callback: @escaping (Result<APIGateway.V2.Response, Error>) -> Void) {\n\tlet headers = [\"Cache-Control\": \"no-cache\", \"Location\": \"https://app.bitrise.io/build/\\(buildSlug)\"]\n\treturn callback(.success(.init(statusCode: .found, headers: headers)))\n}\n\nfunc retrieveImage(for build: Build, workflowId: String, callback: @escaping (Result<APIGateway.V2.Response, Error>) -> Void) {\n\t//move here the response initialization based on the correct image for `build`\n}\nAfter deploying the code above, and inserting the link URL for each image with the correct workflow ID, taking the user to the failing or passing build worked perfectly:
\n\n![](\"/assets/posts-images/20211401-LinkToBitriseBuild.gif\")
\n \n\nAWS Lambda is a great (and probably cheap) resource for running specific computational tasks. With the official runtime package, Swift is a fantastic language to write your lambdas with. Be it due to its low memory foot, type safety, and also for being a language you might be familiar with already. With API Gateway you can expose your functions to the web and call them from anywhere (app client, readme), and don’t worry about server scaling and uptime.
", "summary": "During the last month, as part of my work as an iOS Infra engineer at Houzz, I was responsible for moving our CI from a in-house, bare metal setup running TeamCity, to Bitrise. The constant maintenance, hardware limitations, and lack of determinism were the main reasons for this change.", "date_published": "2021-01-19T09:00:00+00:00", "date_modified": "2021-01-19T09:00:00+00:00", "author": { "name": "Natan Rolnik", "url": "https://natanrolnik.me"}, "tags": ["Lambda","Swift","Server Side Swift"]},{ "id": "https://blog.natanrolnik.me/RW-SSS-Debut", "url": "https://blog.natanrolnik.me/RW-SSS-Debut", "title": "My first tutorial at RayWenderlich.com: “SMS user authentication with Vapor and AWS”", "content_html": "A few months ago, RayWenderlich.com launched a Server Side Swift section and they were looking for authors to join the team. As I believe that Swift on the server has a promising future - and not only amongst iOS developers - I decided to apply.
\n\nAfter many weeks of effort and with the support of their great team (tech editors, editors, designers), the tutorial went live earlier this month and I couldn’t be more proud. I’ve been consuming content from RayWenderlich.com since 2013, be them tutorials, books and video courses. Joining their team is a dream coming true.
\n\nIn this tutorial, the reader will learn how to build an SMS user authentication API using Vapor and Amazon’s AWS Simple Notification Service, SNS. Amongst the covered topics, are:
\n\nService in Vapor;The article is here, check it out!
\n\n![](\"/assets/posts-images/RW-SSS-Debut.png\")
\n \n\nA few years ago, when I opened a Pull Request, one of my colleagues requested a change which seemed irrelevant. The code was something similar to this:
\n\nfunc someFunction() -> String {\n if someCondition {\n return \"Value when condition is true\"\n } else {\n return \"Some other value\"\n }\n}\nWhat he pointed was the following: the else key is redundant. Because there is a return inside the if block, what’s inside the else block would not be called anyway when someCondition is true. Therefore, the same code could be written this way:
func someFunction() -> String {\n if someCondition {\n return \"Value when condition is true\"\n }\n\n return \"Some other value\"\n}\nAt a first glance, one can think: it doesn’t really matter. But there are two arguments that can be used against the usage of redundant elses:
else block.Since that Pull Request, I’ve been a strong supporter of removing usages of it. As an iOS Developer, having a SwiftLint rule throwing warnings would be perfect. Until I or someone else manages to write it, I decided first to find how many ocurrences exist in the codebase I’m working at.
\n\nTo achieve that, I decided I should use a Regular Expression - even though a wise man once said The person who solves a problem with RegEx has now two problems - because they are extremely powerful. I opened up Regex101, and pasted this gist on the “Test String” area. After a few minutes iterating on the RegEx, I found that the following expression is what I wanted:
\n\n(return|continue|break)\\s.*(\\s|\\n|\\t)*?\\}(|\\s)else
You can also open Regex101 and paste the expression to understand what each token and group mean.
\n\nTo see how frequent it appears in your codebase, open Xcode, and by pressing cmd+shift+F open the Find Navigator. Above the search field, click on Text to replace it to Regular Expression. Paste the expression above and hit search. To my surprise, the numbers I got were higher than what I expected:
![](\"/assets/posts-images/20191218-RedundantElse.gif\")
\n \n\nThe Atom editor also supports RegEx search - activate Find in Project with the same cmd+shift+F shortcut, and in the right side enable RegEx by choosing the option Use Regex (the button with .* as the icon).
One of Swift’s greatest features, and one of my favorites, are enums with associated values. The language itself uses them for its fundamentals, like Optional<T>, which either has a .some(T) or is .none. Another example is the new since Swift 5 Result<T, E>, which either contains a .success(T) or a.failure(E) case. In this post, we will go over cases (no pun intended) where an enum is more suitable than a struct or class, and also learn how one can make enums with associated values conform to Codable, achieving a better and safer usage of these data representations when they need to be encoded and decoded. You can scroll to the end of the post to get the final playground.
Enums with associated values make sense when a type may hold only one value, instead of two or more optional values. A classic example for Result is a network operation, which might return either an error or an object. They never should be nil or not be nil simultaneously: when one is nil, the other should exist.
//in this case, the caller must check for nil for both values\nfunc issueRequest<T>(_ request: URLRequest, completion: @escaping (T?, Error?) -> Void)\n\n//here, however, it will be either .success or .failure\nfunc issueRequest<T>(_ request: URLRequest, completion: @escaping (Result<T, Error>) -> Void)\nNow, let’s think of a more concrete example. Let’s imagine we have an app which allows users to confirm presence in some event, and the response from the server might have one out of three possibilites:
\n\nThe server returns a JSON encoded response, so these are the possibilities:
\n\n//1 - user is confirmed:\n{\n \"status\": \"confirmed\",\n \"confirmedUsers\": [\n {\"id\": \"abc\", \"name\": \"Rachel\"},\n {\"id\": \"def\", \"name\": \"John\"}\n ]\n}\n\n//2 - user is in waitlist:\n{\n \"status\": \"waitlist\",\n \"position\": 12,\n \"confirmedUsers\": [\n {\"id\": \"abc\", \"name\": \"Rachel\"},\n {\"id\": \"def\", \"name\": \"John\"}\n ]\n}\n\n//3 - user cannot go for a different reason\n{\n \"status\": \"not allowed\",\n \"reason\": \"It is too late to confirm to this event.\"\n}\nNow, in our client, we need to be able to represent this data and its possible values. If we would use a struct, it would probably look to something like this:
\n\nstruct EventConfirmationResponse {\n let status: String\n let confirmedUsers: [User]?\n let position: Int?\n let reason: String?\n}\nCan you imagine yourself checking for all the the possible states this struct might have?
\n\n![\"Are](\"/assets/posts-images/OptionalsMeme.png\")
\n \n\n In addition to that, in this case a property being present is not enough to determine what is the status: confirmed is returned in both confirmed and waitlist states. Therefore, the status property must be checked in association with the optional values. And if the API get more possibilities, it gets even worse.
We can do better. It would be much safer and predictable to use the following enum:
\n\nenum EventConfirmationResponse {\n case confirmed([User]) //Contains an array of users going to the event\n case waitlist(Int, [User]) //Contains the position in the waitlist and\n case notAllowed(String) //Contains the reason why the user is not allowed\n}\nGreat! Now, whenever this response needs to be used for being displayed to the user, one can use a switch statement to check each case and extract the associated values:
switch confirmationResponse {\n case .confirmed(let users):\n let confirmedEventVC = ConfirmedEventViewController(event: event, confirmed: users)\n present(confirmedEventVC, animated: true)\n case .waitlist(let position, let users):\n let eventWaitlistVC = EventWaitlistViewController(event: event, position: position, confirmed: users)\n present(eventWaitlistVC, animated: true)\n case .notAllowed(let reason):\n presentNotAllowedAlert(with: reason)\n}\nThis looks much better. Now, we want to provide the EventConfirmationResponse enum to our HTTP client, so it can convert the JSON response directly into the enum: we want it to be Decodable, which has a great advantage: we hand over the different possibilites to the JSONDecoder, and if there is any field missing or incompatible with what we described above, the decoding fails. Failing early, in the decoding stage, is better than failing at a UI display stage. Also, it’s worth noting, if the server is also being written in Swift (e.g., with Vapor), we can make it conform to Encodable, and JSONEncoder will take care of converting it exactly into the expected response.
Encodable & Decodable is the exact definition of Codable. If we add it to our enum and try to compile, we will get the following error:
extension EventConfirmationResponse: Codable {}\n\n//type 'EventConfirmationResponse' does not conform to protocol 'Decodable'\n//protocol requires initializer 'init(from:)' with type '(from: Decoder)'\n//type 'EventConfirmationResponse' does not conform to protocol 'Codable'\n//protocol requires function 'encode(to:)' with type '(Encoder) throws -> ()'\nThe message is pretty clear. Because Swift doesn’t know how one wants the associated values to be encoded, and there is no defined standard, it doesn’t know what to do, and, consequently, asks the developer to implement them.
\n\nAs the errors stated, there are two methods that need to be implemented. Let’s first do the encoding part, thinking about the JSON declared above, and move to the decoding later on.
\n\nThe required method by Encodable is encode(to encoder: Encoder). The parameter is a Encoder, which might be Foundation’s JSONEncoder, or a custom XMLEncoder, for example. In order to encode the data, the Encoder provides three types of encoding containers:
KeyedEncodingContainer<Key>: to be used when the encoding will have a key-value format, using a CodingKey enum to access the possible keys, as used when encoding a dictionary. Types that automatically conform to Encodable will have the CodingKey generated automatically as well.UnkeyedEncodingContainer: to be used when encoding multiple, unkeyed values, as used when encoding an array, for example.SingleValueEncodingContainer: to be used when a single primitive value, like a string.The documentation says: You must use only one kind of top-level encoding container. This means that when encoding a value, only one container must be used, and not more than one simultaneously. In our case, we will choose the keyed container, because we will encode our enum into a key-value JSON object.
\n\nAs mentioned in the explanation of the keyed container, we need to create a CodingKey-conforming type. We will create a case for each possible key in the JSON. Also, because there are only three acceptable statuses (confirmed, waitlist, and not allowed), we can use a simple enum to ensure the status value is one of them.
//declare which keys in the JSON we are interested in\nenum CodingKeys: String, CodingKey {\n case status\n case confirmedUsers\n case position\n case reason\n}\n\n//declare the possible values os the status key\nprivate enum EventConfirmationStatus: String, Codable {\n case confirmed\n case waitlist\n case notAllowed = \"not allowed\"\n}\nNotice that in both enums, where the raw value is a string, there is no need to actually declare it - the cases are compiled into the raw values (except the notAllowed case). Now it’s left to implement the encoding itself. We will need to do two things: (1) get the keyed container from the encoder, and (2) iterate over the event confirmation enum in order to encode each case, separately:
extension EventConfirmationResponse: Encodable {\n func encode(to encoder: Encoder) throws {\n //access the keyed container\n var container = encoder.container(keyedBy: CodingKeys.self)\n\n //iterate over self and encode (1) the status and (2) the associated value(s)\n switch self {\n case .confirmed(let users):\n try container.encode(EventConfirmationStatus.confirmed, forKey: .status)\n try container.encode(users, forKey: .confirmedUsers)\n case .waitlist(let position, let users):\n try container.encode(EventConfirmationStatus.waitlist, forKey: .status)\n try container.encode(users, forKey: .confirmedUsers)\n try container.encode(position, forKey: .position)\n case .notAllowed(let reason):\n try container.encode(EventConfirmationStatus.notAllowed, forKey: .status)\n try container.encode(reason, forKey: .reason)\n }\n }\n}\nWe can now use JSONEncoder().encode(confirmation) and get a JSON representation of our enum.
To finally conform do Codable, there’s left the Decodable protocol. To achieve it, we need to initialize our enum given a Decoder with init(from decoder: Decoder).
Similar Encoder, Decoder also has the three analogue containers. As all 3 states have a status key and we need it to define which state will be initialized, we will look for it first by trying to decode a String for the .status coding key. Then, we iterate on the status value, and look for the other values for the relevant keys:
extension EventConfirmationResponse: Decodable {\n init(from decoder: Decoder) throws {\n //access the keyed container\n let container = try decoder.container(keyedBy: CodingKeys.self)\n\n //decode the value for the status key into the EventConfirmationStatus enum\n let status = try container.decode(EventConfirmationStatus.self, forKey: .status)\n\n //iterate over the received status, and try to decode the other relevant values\n switch status {\n case .confirmed:\n let users = try container.decode([User].self, forKey: .confirmedUsers)\n self = .confirmed(users)\n case .waitlist:\n let users = try container.decode([User].self, forKey: .confirmedUsers)\n let position = try container.decode(Int.self, forKey: .position)\n self = .waitlist(position, users)\n case .notAllowed:\n let reason = try container.decode(String.self, forKey: .reason)\n self = .notAllowed(reason)\n }\n }\n}\nDone! Our enum is now ready to be encoded and decoded. If you want to test and see all the code in a single place, I’ve prepared a playground which you can download here.
\n\nEnums with associated values provide expected scenarios to the developer dealing with it, leaving out uncertainties and ambiguities. Leveraging the Codable protocol by implementing only 2 methods, server or client side Swift apps can send and receive the enums data representations in a standardized way, making things more predictable and safe. You can download the playground to play with it.
Thanks to Bruno Rocha and Antoine v.d. Lee for reviewing this post
", "summary": "One of Swift’s greatest features, and one of my favorites, are enums with associated values. The language itself uses them for its fundamentals, like Optional<T>, which either has a .some(T) or is .none. Another example is the new since Swift 5 Result<T, E>, which either contains a .success(T) or a.failure(E) case. In this post, we will go over cases (no pun intended) where an enum is more suitable than a struct or class, and also learn how one can make enums with associated values conform to Codable, achieving a better and safer usage of these data representations when they need to be encoded and decoded. You can scroll to the end of the post to get the final playground.", "date_published": "2019-05-15T09:00:00+00:00", "date_modified": "2019-05-15T09:00:00+00:00", "author": { "name": "Natan Rolnik", "url": "https://natanrolnik.me"}, "tags": ["Codable","Enum"]},{ "id": "https://blog.natanrolnik.me/ProtocolsWithObjcFunctions", "url": "https://blog.natanrolnik.me/protocols-default-impl-control-handling", "title": "Protocols Default Implementations with UIControl.Event handling", "content_html": "Since Swift’s introduction, a lot was covered about Protocol Oriented Programming (aka POP). In contrast to Object Oriented design, which is based in inheritance, POP allows your objects and types to “wear many hats”. Instead of making an object inherit functions from its superclass(es), using protocols can make it more flexible and modular by implementing a protocol’s methods.
\n\nSwift 2 introduced a huge factor in favor of using protocols: default implementation. Let’s start with an example. ScrollRefreshable will make it easier to add a UIRefreshControl to our UIScrollViews and handle the refresh action.
(If you already know about default implementations, you can skip to the ‘Refining The Protocol’ or the ‘The Roadblocks’ section)
\n\nprotocol ScrollRefreshable {\n var scrollView: UIScrollView { get }\n func addRefreshControl()\n}\nBefore default implementation became available, we would implement it this way:
\n\n// Make MyViewController implement the scrollView property and the addRefreshControl method\nextension MyViewController: ScrollRefreshable {\n var scrollView: UIScrollView {\n return collectionView\n }\n\n func addRefreshControl() {\n let refreshControl = UIRefreshControl()\n refreshControl.addTarget(self,\n action: #selector(refreshTriggered),\n for: .valueChanged)\n scrollView.refreshControl = refreshControl\n }\n}\n\nextension MyViewController {\n @objc func refreshTriggered() {\n //call server and fetch data\n }\n}\nNow, with protocol default implementations, we could change things a bit:
\n\nprotocol ScrollRefreshable {\n var scrollView: UIScrollView { get }\n func addRefreshControl(target: Any, action: Selector)\n}\n\n//add a default implementation for adding the control\nextension ScrollRefreshable {\n func addRefreshControl(target: Any, action: Selector) {\n let refreshControl = UIRefreshControl()\n refreshControl.addTarget(target, action: action, for: .valueChanged)\n scrollView.refreshControl = refreshControl\n }\n}\n\n// Make MyViewController conform to ScrollRefreshable\nextension MyViewController: ScrollRefreshable {\n var scrollView: UIScrollView {\n return collectionView\n }\n}\n\n//Add a method that we will pass to addRefreshControl in the action parameter\nextension MyViewController {\n @objc func refreshTriggered() {\n //call server and fetch data\n }\n}\nNow, anyone who wants to conform to ScrollRefreshable won’t need to implement the addRefreshControl function. This is nice, but it’s been around for a few years, and also, we can do more to improve it.
The above protocol might be a better solution in some cases (by passing target and action), but for the exercise, we will try to add refreshTriggered() to the protocol, and passing it as the action. The following code will not compile:
protocol ScrollRefreshable {\n var scrollView: UIScrollView { get }\n func addRefreshControl()\n func refreshTriggered()\n}\n\nextension ScrollRefreshable {\n func addRefreshControl() {\n let refreshControl = UIRefreshControl()\n refreshControl.addTarget(self, action: #selector(refreshTriggered), for: .valueChanged) //DOESN'T COMPILE\n scrollView.refreshControl = refreshControl\n }\n}\nCan you try guessing why? It’s because refreshTriggeredis not exposed to the Objective C runtime. This is what the compiler says: Argument of '#selector' refers to instance method 'refreshTriggered()' that is not exposed to Objective-C.
To fix it, we could try adding @objc to the function in the protocol definition, which gives us another error: @objc can only be used with members of classes, @objc protocols, and concrete extensions of classes. The solution for this is adding @objc to the protocol itself, as suggested by the compiler’s message.
The approach of making our protocol @objc has a few different problems: if the protocol has any features not available in Objective C, it won’t work. These might be:
Associated type 'Item' cannot be declared inside '@objc' protocol 'ScrollRefreshable';Method cannot be a member of an @objc protocol because the type of the parameter cannot be represented in Objective-C or Method cannot be a member of an @objc protocol because its result type cannot be represented in Objective-C;Non-class type 'MyStruct' cannot conform to class protocol 'AnotherScrollRefreshable'Ideally, we should automatically call refreshTriggered() while keeping our protocol not constrained to be @objc.
Fortunately, we can still use the default implementation of addRefreshControl() while keeping our protocol away from being @objc only. And we will use the Objective-C runtime for that. If we add support for passing a block to execute when a UIControl.Event happens, we don’t need to rely on the target-action pattern from within the protocol extension directly.
To do so, let’s create a wrapper, that receives a simple () -> Void block:
class ClosureWrapper {\n let closure: () -> Void\n\n init(closure: @escaping () -> Void) {\n self.closure = closure\n }\n\n @objc func invoke() {\n closure()\n }\n}\nThe code above simply receives a block and runs it when invoke() is called. Now, we will add it as the target of our UIRefreshControl with this handy UIControl extension:
extension UIControl {\n func addAction(for controlEvents: UIControl.Event, action: @escaping () -> Void) {\n let wrapper = ClosureWrapper(closure: action)\n addTarget(wrapper, action: #selector(ClosureWrapper.invoke), for: controlEvents)\n objc_setAssociatedObject(self,\n \"[\\(arc4random())]\",\n wrapper,\n .OBJC_ASSOCIATION_RETAIN)\n }\n}\nLet’s see what this UIControl extension method does:
action block in a ClosureWrapper;UIControl (in this case, self);wrapper was created in the function scope, it would go away at the end of the function. To avoid that, we attach it to the UIControl itself using objc_setAssociatedObject - so whenever the UIControl is alive, the wrapper we just created will be kept in the memory as well.With this, we can solve our problem in an elegant way, instead of using target-action:
\n\nextension ScrollRefreshable {\n func addRefreshControl() {\n let refreshControl = UIRefreshControl()\n refreshControl.addAction(for: .valueChanged) { [weak self] in\n self?.refreshControlTriggered()\n }\n scrollView.refreshControl = refreshControl\n }\n}\nProtocols allow us to make our objects more flexible, and default implementations helps implementing them in a concise way. With a bit of creativity and using the Objective C runtime, we can get rid of the @objc protocol constraint whenever the target-action pattern is required in a protocol extension (as in UIButton or any other UIControl).
Feel free to add any comments below, or ping me on twitter if you have any suggestions or ideas: @natanrolnik
", "summary": "Since Swift’s introduction, a lot was covered about Protocol Oriented Programming (aka POP). In contrast to Object Oriented design, which is based in inheritance, POP allows your objects and types to “wear many hats”. Instead of making an object inherit functions from its superclass(es), using protocols can make it more flexible and modular by implementing a protocol’s methods.", "date_published": "2019-04-01T09:00:00+00:00", "date_modified": "2019-04-01T09:00:00+00:00", "author": { "name": "Natan Rolnik", "url": "https://natanrolnik.me"}, "tags": []},{ "id": "https://blog.natanrolnik.me/DispatchWorkItem", "url": "https://blog.natanrolnik.me/dispatch-work-item", "title": "Using DispatchWorkItem to delay (and cancel) tasks", "content_html": "Performing delayed tasks and working with multithreading in Cocoa became much simpler since the introduction of GCD - Grand Central Dispatch. Before it existed, delaying a task would require using NSThread and/or NSOperationQueue, or the simple but limited performSelector:withObject:afterDelay: method available in NSObject.
While NSOperations are better, in general, when you need to manage multiple tasks that can be added to a queue (like sequential image downloads, for example), GCD allows a simpler API to run blocks of code with the dispatch_after (Objective-C) and DispatchQueue.main.asyncAfter methods.
DispatchWorkItemWith a practical example in mind, assuming we want to show a hint indicating that our messenger app supports voice messages now. To do so, we’ll make the microphone button jump:
\n\n\n\n\nIf you’ve been developing with Swift for a while, chances are high you already used this API. Now, imagine that, if the user found the button before it jumped - we definitely don’t want to trigger the hint. We could do it in a way - not the cleanest one:
\n\n\n\n\nThis is how we would to it before knowing about DispatchWorkItem. Let’s compare with how this can be achieved, but using DispatchWorkItem:
Isn’t it much better? I believe so, for a few reasons. First, every task can be assigned to a different work item. Secondly, in case we want to cancel it, there is no need to keep one state variable for each task.
\n\nIt is worth noting that, although GCD is available in both Objective-C and Swift, DispatchWorkItem Swift only.
A few months ago, Guilherme Rambo tweeted a great example of how easily this API can be used to create things that, often, we consider using a framework for.
\n\n\n\n\nDispatchWorkItem ❤️ pic.twitter.com/6gxCLA4Wmo
— Guilherme Rambo (@_inside) April 13, 2018
With less than 30 lines, Guilherme showed us how to create a simple throttler for a specific UI event. Within his tweet’s replies, some people suggested he should try RxSwift, as it offers the built in .throttle() and .debounce() operators. Well, if we have a project that is already using it, fine. But if we don’t want to add to our app a new dependency, I believe it makes more sense to keep things simple. My rule of thumb is: Always prefer system APIs and simplicity over 3rd party frameworks when possible.
Of course, Gui’s example is a specific use case. But with little effort we could make it something more generic. For example, that listens to NotificationCenter and throttles a Notification when it’s posted:
If we end up having multiple work items managed by the same view controller, we should think if the current design is correct. One way to fix it is splitting the responsibilities of a view controller in multiple child view controllers. If we tried doing so and still have 3 or 4 work items that need to be managed by the same view controller, having them as multiple references is far from ideal.
\n\nA solution that I came up with, was creating a Dispatcher object, that would manage the work items according to an identifier. It should allow:
After a few iterations and inputs from friends, I was able to get to this (you can see the playground version here):
\n\n\n\n\nGCD and DispatchWorkItems are provide us a simple way to perform powerful and complex tasks, that would require us using different or older APIs. Sticking to it might save us from unnecessary frameworks or wrong abstractions and architectures.
Feel free to add any comments below, or ping me on twitter if you have any suggestions or ideas: @natanrolnik
", "summary": "Performing delayed tasks and working with multithreading in Cocoa became much simpler since the introduction of GCD - Grand Central Dispatch. Before it existed, delaying a task would require using NSThread and/or NSOperationQueue, or the simple but limited performSelector:withObject:afterDelay: method available in NSObject.", "date_published": "2019-02-14T13:10:00+00:00", "date_modified": "2019-02-14T13:10:00+00:00", "author": { "name": "Natan Rolnik", "url": "https://natanrolnik.me"}, "tags": []},{ "id": "https://blog.natanrolnik.me/wwdc-16-past-and-future", "url": "https://blog.natanrolnik.me/wwdc16-past-and-future", "title": "WWDC 16 - Past and Future", "content_html": "I can’t believe it’s already been three years since I visited San Francisco for the first and only time. In the same way that the tickets that year were sold out in 70 seconds, that unforgettable week, where Apple announced iOS 7 and Mavericks, passed like lightning. It’s hard to to express how much I’m excited for the next week, both as a member of the iOS worldwide community and as a programmer. Yes, Dub Dub is already in the next week!\nIn three years, generally speaking, a lot can happen in someone’s life. But in tech, things move faster, and in three years things change a LOT more. Just to understand to what degree iOS is maturing and the community is evolving together, I’ll list a few jaw dropping facts that were reality right before WWDC 13.
\n\nIn the iOS/OS X world:
\nUIAlertViews and UIActionSheets and their delegates weren’t deprecated yet 😩And in the iOS community:
\nIs it only me, or when you look back to all these changes, knowing how things were different and hard before, you are also proud to experience all these changes while they happen? How cool is to watch this video again and again, and to remember the excitement for the new iOS that was coming?
\n\nAs a pre-WWDC post, I also can’t skip my (humble, I admit) wishlist:
\nOf course, the Keynote and the State of the Union presentations will come and (I hope) surprise everyone. This is part of the magic. In the last days I’ve been literally dreaming about this magic.
\n\nI can’t wait to meet personally the people who I only know from the internet; to see other friends who I’ve met before and I’m in touch with; and specially to meet new people. Thousands of different people, from different backgrounds and locations, with a shared passion.
\n\nI can’t wait to hear in first hand what’s coming to iOS 10, OS X, watchOS, tvOS, Xcode and Swift 3. I can’t wait to get emotional for making a dream come true, once again, after being present on a Keynote with more than 5 thousand people. I can’t wait for WWDC to start!
\n\nPS: If you want to start getting into the mood, I recommend this playlist on Apple Music!
", "summary": "I can’t believe it’s already been three years since I visited San Francisco for the first and only time. In the same way that the tickets that year were sold out in 70 seconds, that unforgettable week, where Apple announced iOS 7 and Mavericks, passed like lightning. It’s hard to to express how much I’m excited for the next week, both as a member of the iOS worldwide community and as a programmer. Yes, Dub Dub is already in the next week! In three years, generally speaking, a lot can happen in someone’s life. But in tech, things move faster, and in three years things change a LOT more. Just to understand to what degree iOS is maturing and the community is evolving together, I’ll list a few jaw dropping facts that were reality right before WWDC 13.", "date_published": "2016-06-05T12:35:38+00:00", "date_modified": "2016-06-05T12:35:38+00:00", "author": { "name": "Natan Rolnik", "url": "https://natanrolnik.me"}, "tags": []},{ "id": "https://blog.natanrolnik.me/migrating-my-data-from-parse", "url": "https://blog.natanrolnik.me/migrating-my-parse-data", "title": "Migrating My Data From Parse", "content_html": "As you probably already know, Parse announced it’s ending their hosting services on January 28, 2017. The migration plan was divided in two steps: first, we need to host the databases of our apps, and later on we should deploy our own, open source, Parse Server. During the first stage, the clients (iOS, Android, etc.) will keep hitting Parse’s servers, and they will access the newly migrated data; after the second stage is done and your server is up and running, the clients should be updated to point to the new server. The recommended schedule by the Parse team is to migrate the database by April 28, and finish setting up your self-hosted Parse Server by July 28. Yes, you read it right - if you haven’t migrated your database, you have less than a month to do so.
\n\n“But where should I start from?”. As any decision, the pros and cons must to be taken into account, also considering the different conditions: do you have only one or multiple apps on Parse? They store huge amounts of data, or not so much? Do you have experience managing databases, specially MongoDB? How sensitive is your data? What is your budget?
\n\nAs most of my apps have a small, niche audience, the amounts of data are really small. None of the databases is higher than 10 MB, even with a few thousand users, installation, and other objects. Also, most of them are free, with some humble contributions or donations occasionally. Therefore, I have a small budget to keep them functioning. As I have zero experience managing databases, I can’t build all the MongoDB server by myself (for example, I didn’t even know of some concepts like sharding, replica sets, and more). I started researching all the different options available in the market, to find what would fit my needs.
\n\nSuggested by the Parse Team, there are mLab and ObjectRocket, who provide - from what I’ve read - excellent DB-as-a-service. mLab would be a good fit for me, their prices start from U$15 per GB/database/month (the free tier is not intended for production usage). I have around 6 apps in production, and they require different databases, so the monthly cost would be almost U$100 per month, and we aren’t even talking about hosting the Parse Server yet. (Actually, if you are using only Parse Server, and not migrating from hosted Parse, you can use only one database for different apps, by defining a collectionPrefix).
\n\nUnfortunately, the prices and sizes that ObjectRocket offer aren’t for indie/side projects, so I needed to cross them as well from my list, together with mLab and Compose.io. While reading the community links and googling more, I’ve found Clever Cloud. I almost chose them to host my DBs: you can host as many mongo dbs you want, and it’s free up to 500 MB; but if you need more than that, it jumps from a free 500 MB, to a 75 €/month for 30 GB, and I needed something in the middle.
\n\nAlso, as an option for a replacement of all Parse services, there are also NodeChef, ParseGround, Backand and Back4app. But as now I have the possibility to have control over the whole parse stack, I preferred not to depend too much again on another service. It’s a personal decision; check them out because they may be a good fit for you, if you don’t want to worry at all with the backend.
\n\nAfter a few weeks, when I was about to give up, I found Scalegrid.io, that provided exactly what I needed: a place where I can create many Mongo DBs under the same infrastructure (a cluster). Someone to manage the hard part, but with the control that I want. Similarly, there is also MongoDB Cloud Manager, which is an excellent product from MongoDB Inc. itself. I preferred to go with Scalegrid, but the process I describe in the next section is very similar for both solutions.
\n\nAfter signing up for a 30 day free trial, I checked which one of the services would fit me better: (1) hosting, where I provide my AWS keys or own hardware, and they manage it, or (2) management, where I don’t need to worry about the hardware that will host the dbs. In my case, I preferred to have control also over the underlying instances, so I chose the first option. Price-wise, they are very similar at the end of the day - in the first, you need to pay AWS and Scalegrid.io, while in the second you pay a little more but only for Scalegrid.io. According to my calculations, it would be something very close. So this is what I did, and what you should do to set it up:
\n\nFinally, an important detail: as one of my apps stores medical data, I wanted SSL to be required. Scalegrid offers two options: self-signed certificates, or use your own, trusted certificates. If you are running only your own Parse Server, the self-signed certificate is enough; if you are migrating from Parse, you will need to get a certificate from a trusted Certificate Authority, or disable SSL at all in your mongo server. I chose the first option:
\n\n![](\"/assets/posts-images/parse-db-migrated.jpeg\")
\n \n\nIf you have any troubles, you can ping me @natanrolnik, or e-mail me at me+b@natanrolnik.me.
\nThanks to @newFosco, @MarcioK and @ofermorag24 for reviewing this post
Friday morning, Israel time. After I wake up and look to my iPhone, I see 3 notifications from friends (fellow developers that know how much I love Parse), sending me the link to Kevin Lacker’s post. When I saw the title, “Moving On”, I froze. Only a few days after releasing my side project, an app I’ve worked on for over than a year and a half, using Parse as backend, would I read the worst thing to happen to that and to a few other smaller projects?
\n\nIn the last two years, I’ve been using it in almost every single project, in many different ways for each app:
\n\nFor me, nothing describes Parse better than the following quote from their last marketing video, part of a complete and recent redesign and rebranding: “You can definitely handle the frontend, but what about the backend? Configuring servers, managing databases, writing APIs, storing videos, authenticating users, building deployment processes, and so on, and so on. Sure, you can figure out how to do that stuff yourself, maybe hire someone to deal with it for you, but here is a better way: Parse”. For sure, if I had all the time and resources in the world, of course I would like to take care of every single part of my app, doesn’t matter if it’s frontend or backend. I am, more than an iOS developer, a programmer. We deal with solving problems, no matter the language or the ecosystem. But our resources and time are limited.
\n\nThere are two main reasons developers liked it so much and got pissed off with the news. First, it allowed us to make more complex apps in a easy, fast, and reliable way, even without the need to master another programming language. Additionally, if you are working in a side project where you may even know how to build the server side - you may be constrained by time and need to get out with something faster, focusing on the app experience. We loved Parse because it made the heavy lifting. If my side project took an year and a half with client code only (and minimal Cloud Code), I don’t think I would have ever finished it if I needed to take care of writing the API, managing databases and deploy processes.
\n\nIn total, 6 friends have sent me the link to the shutdown post, and they all did it because I’m sure I’ve talked enough about it (recommending) and telling how much it helped me accomplishing this app. Even a few of my friends who don’t code know what is Parse.
\n\nOf course, the first thing that popped in my mind as I read the shut down post was: “Ok, what should I do now?!”. I couldn’t believe what my eyes were reading. In the following hours, I got really sad (ask my wife!), and felt as if I was loosing something cherished - after all, I’ve been a user for almost 3 years since I first heard about in the WWDC 2013 party, and after following how much it changed and improved since then.
\n\nFinally, I reached the stage of acceptance and tried to follow the excellent migration guide they prepared. After around one hour, I had the development database migrated to mongolab, and after around another hour I had the Parse Server deployed in Heroku.
\n\nWell, it’s definitely not yet there, and the server has still a few limitations and issues, but I started feeling that the “backup plan” may end up being a better solution in the end of the day (specially if you client app is mostly done):
\n\n(This, considering you won’t do significant API changes and still want to use Parse’s SDK in the client code. If your client app’s architecture is not tied to _PFObject_s everywhere, even better.)
\n\nIt’s more work, for sure. Deploying, monitoring, scaling. But that’s an amazing opportunity to learn more stuff, and keep using the same client code (only changing the server URL).
\n\nA huge thanks to everyone who was involved in creating the idea, implementing the initial products, and the ones who took it to another level. With the tool you created, I did apps that could do much more, and also I could focus and finish a big project I’ve been dreaming of for around 3 years. Another special thanks to the folks (Fosco Marotto et al) who are working around the clock to make Parse Server and the migration stable and reliable, and as smooth as possible for us!
\n\n![Skeumorphism was](\"http://core0.staticworld.net/images/article/2013/06/photo-jun-17-3-34-21-pm-100042569-large.png\"){kind=link}
![awesome](\"http://core0.staticworld.net/images/article/2013/06/photo-jun-17-6-03-18-pm-100042568-orig.png\"){kind=link}