Pedro Carrasco

How To Have Multiple Icons?

2019-06-30T00:00:00+00:00

There are multiple ways to make your application feel more personal to your users or even reward the most loyal ones. However, there aren’t many as simple as having multiple application icons available and, in this post, you’ll learn how you can do it.

“How to … ?” is a collection of short posts where I’ll share problems I’ve faced and how I ended up solving them.

tl;dr - Question 👉 Answer

Problem

While adding your main application icon is as simple as adding some image to an asset catalogue (.xcassets), adding an alternative application icon won’t be anything like that.

⚠️ Spoiler: You won’t even add it to an asset catalog 😱

Solution

Assuming you have already designed a beautiful default icon and some alternatives, export them using the @2x and @3x naming convention and place them somewhere in your project inside a group (outside of any asset catalogue).

In the end, you should have something as follows:

Now, open your Info.plist as source code. At the end of your file, you should see </dict> and </plist>. Paste the following before them:

In case you didn’t notice, you must omit the file extension and the scaling suffix (@2x and @3x) from each entry.

Once you’re done, you can freely change your application’s icon by calling setAlternateIconName(_:completionHandler:) like follows:

Before ending, if your application also supports iPad, you’ll need to add another dictionary to your Info.plist. This dictionary should be a copy of the previously added one but with the ~ipad suffix. Considering the previous dictionary, it would result in:

Conclusion

Alternate application icons were introduced in iOS 10.3 and can help you make your application feel more personal to your users. While providing this feature isn’t difficult, it isn’t as easy as it could and should be and tools like AlternativeIcons can improve your experience with it.

Last but not least, if you have any subject you would like to see covered and/or discussed, let me know here or on Twitter! 👀

Thanks for reading. ✨

How To Display Your Dependencies?

2019-06-19T00:00:00+00:00

Ever wanted to show your users which dependencies your application has? I needed this for an application I’ll launch soon and, in this post, you’ll learn how you can achieve it.

“How to … ?” is a collection of short posts where I’ll share problems I’ve faced and how I ended up solving them.

tl;dr - Question 👉 Answer

Problem

Since I was using CocoaPods to manage my dependencies, there was only one requirement: the data must be synchronized with the podfile.

Solution

While I’ve never heard of it before, there was a clear and “official” solution. It was the plugin cocoapods-acknowledgements.

This plugin generates a property list (.plist) with the metadata of your dependencies. In order to use it, follow the next steps:

Install it via ruby with gem install cocoapods-acknowledgements
Add plugin 'cocoapods-acknowledgements' to your podfile.
You’ll now find Pods-YOUR_TARGET-metadata.plist inside Pods/

With this property list you can either decode it with the following code and map/transform to your own user interface:

Or, if you rather have it in your application’s settings, you can also embed it in your Settings.bundle. To do so, you just need to add plugin 'cocoapods-acknowledgements', :settings_bundle => true to your podfile.

Conclusion

You’re now able to display your dependendencies to your users and keep in mind that CocoaPods Acknowledgements is well documented and offers other features, such as excluding dependencies or even adding non-CocoaPods dependencies to your property list. You can find it all here.

Last but not least, if you have any subject you would like to see covered and/or discussed, let me know here or on Twitter! 👀

Thanks for reading. ✨

How To Be Lazy In Extensions?

2019-03-29T00:00:00+00:00

How to extend an object with a lazy property? Recently, I needed this for Constrictor and, in this post, you’ll learn how you can achieve it.

“How to … ?” is a collection of short posts where I’ll share problems I’ve faced and how I ended up solving them.

tl;dr - Question 👉 Answer

Problem

Let’s start with the obvious solution, which in this case, would be extending UIView with:

Clean and simple, but it doesn’t work… If you give it a try, Xcode will fail to compile with “Extensions must not contain stored properties”.

Solution

While potentially dangerous, Associated Objects can still be very useful as they allow us to add new properties inside an extension of an existing object.

As an example, we are able to create a lazy property in an UIView extension as follows:

In short, we have a lazy property by associating a Constrictor’s instance to a UIView’s instance in runtime. If there is one associated, it will retrieve it. If there isn’t, it will create one and save its “address” in AssociatedKey.constrictor so it can be retrieved in future calls.

Conclusion

As mentioned, Associated Objects can be dangerous if used improperly. To be fully aware of its capabilities and common pitfalls, I recommend reading Mattt’s article from NSHipster.

Last but not least, if you have any subject you would like to see covered and/or discussed, let me know here or on Twitter! 👀

Thanks for reading. ✨

Let’s Talk About Double Standards

2019-01-08T00:00:00+00:00

Have you ever found yourself surrounded in a codebase where code guidelines seem to be ignored in its tests? It’s time to talk about this with José Figueiredo, Paul Hudson, Rodrigo López-Romero and Tiago Martinho.

“Let’s talk about” is a series where I discuss and showcase my point of view about specific topics. However, as most topics can be highly opinionated, I will also bring other people’s opinion.

tl;dr - Friendly Rant

Introduction

Let’s start with the definition of guideline according to the Cambridge Dictionary:

guideline (noun)

information intended to advise people on how something should be done or what something should be

We have lots of guidelines in our lives and people soon recognised we also needed them in programming. Otherwise, our codebases would be a combination of personal tastes embedded into an incoherent pile of computer instructions.

Subsequently, we developed multiple guidelines from styling to best practices. On top of that, we even automated the review process with tools such as SwiftLint but what about tests?

We follow a whole bunch of principles, patterns and guidelines but we often see tests ignoring them. Copy-pasting across multiple tests, response’s stubs polluting test files, magic numbers everywhere and force-unwrapping because “it is just a unit test”? What about having double standards when it comes to code guidelines?

Paul Hudson, author of Hacking with Swift and Testing Swift, agrees that tests are as important as application’s code and we shouldn’t have different standards between both:

“The Swift language provides us with a dazzling array of language features and design patterns to help us create smart, safe, reusable code, but for some reason these get completely ignored when writing tests – we just write them the brute force way, with a thousand functions named testXYZ().

At WWDC17, Xcode engineer Greg Tracy said “Treat your test code with the same amount of care as your app code.” Simple, but straight to the point: all the coding principles we apply in our application’s code should also be applied in our tests

Many companies will talk proudly about their approach to code review – they might do pair programming, they might do GitHub reviews, they might have in-person code review sessions. But if you ask whether they do that same code review for their tests, you’ll find a problem: they usually don’t.

The code you write is designed to solve a problem, and the tests you write are there to prove the code does what it says – the two are equally important, and should be treated as such.” - Paul

At this point, it should be clear how critical it is to acknowledge tests as part of the codebase and treat them as such. In this regard, Tiago Martinho, the organiser of the Swift Peer Lab in Barcelona, goes one step further and explains how culture and adaptability work together to eliminate double standards:

“Guidelines are important as a safety and communication mechanism, but the secret to maintaining a healthy codebase is having a healthy team culture. If we have guidelines for the production code but we are not following them for our tests, then there is a misalignment in the value these guidelines provide, and this should be tackled before adding more or changing existing guidelines.

My personal opinion is that tests are part of the codebase, without them the cost of doing iterative development on the software greatly increases over time. On the other hand, if a test is not providing a safety net (that actually works) or is fragile with a high maintenance cost, then the best approach is to gradually migrate it to follow the team principles.” - Tiago

The following sections contain some examples in how you can improve your tests by giving them as much attention as you give to your application’s code.

Call It Magic

A magic number (or any other type) is a hard-coded value which meaning is hard to infer without context. Also, it might need to be updated at a later stage, therefore requiring you to change it in multiple places if it is all over your codebase.

Everyone tends to avoid it in their projects, but it isn’t uncommon to see it in tests.

Take a look at the following example:

While you might quickly notice the number 7, in order to understand it, you have to take a few seconds analyzing both functions. You might end realizing there is a business rule limiting the number of products an unauthenticated user will see. However, if instead of a magic number, you defined a constant with a proper name, both readability and understandability would have been improved.

Still not convinced if it is worth the effort? What if months later, your company decides to update from 6 items for non-logged users to 9? In the previous example, you would only have to update two tests but what if you had more? That’s right, using a magic number isn’t scalable at all.

So instead, you could do as follows:

Now, if there is an update, you just change one value in your tests. Besides, you can immediately see the reasons behind what you are asserting.

José Figueiredo, a senior engineer at Synchronoss Technologies, also disagrees with the use of magic numbers and double standards in general. According to him:

“In my honest opinion, magic values have no place in the middle of the code either if its production-grade or on a test target. Instead, they should be contextualised with variables, struct or enums with proper naming.

After all, if you avoid the use of magic numbers in production code, you should be compelled to do it on the test target as well.” - José

Hide yo’ Data

It is uncommon to have data stubs in the application’s code. However, it is very likely to have them in its tests. While data stubs aren’t an issue by themselves, spreading them across your test case isn’t a proper solution. Not only do they pollute it with extra lines but do also reduce its readability.

Take the following as an example:

In two tests, a considerable amount of lines are for instantiating two Product and for what? In the end, you care about what these objects represent, not how they are instantiated. So instead, place them strategically into isolated containers, expose their meaning and reuse them if appropriate. Not only will this reduce the lines of code in your test file but also increase its readability - not to mention you now have two Product you can reuse across your tests.

As an example, create the following in a separate file:

Then, update your test as follows:

Much shorter, easier to read, easier to understand and easier to maintain.

Rodrigo López-Romero, an engineer at Adidas, added you should also have a well-defined folder structure, just like you would have in your application’s code. According to him:

“I find very useful to have a separate project folder consisting of all test data. It helps to make the testing code clean and neat. When it comes to stubbing network requests, I think it is useful to have the JSON responses in separate files, although you need to update those JSON files whenever the server side changes.” - Rodrigo

Keep in mind you shouldn’t overuse your test data! Distribute it by logic, context or any other criteria and avoid crossing it. Logic receives updates over time and with so you may need to update your test data. If it is too spread all over your tests, it may undesirably set some of them on fire! 🔥

Copy-Pastability

On what do we spend most of our time as programmers? Scalability, replaceability, understandability, reusability and other fancy terms. All because we strive for quality.

If we have the same five lines of code in different places what do we do? Encapsulate it in a function. But what about tests?

Imagine a scenario in which your screens’ structure is dynamically controlled by a back-end service and you want to validate that when receiving a new structure it updates accordingly. Take the following as an example:

Notice the pattern? The code responsible for loading a JSON file doesn’t add any value to these tests. After all, it isn’t relevant how it loads it. It adds unnecessary complexity and extra lines for you to read. Instead, try doing as follows:

These tests exist to validate how the screenStructureManager determines and updates the screen structure. Therefore, you can encapsulate any supplementary logic in functions with a well-defined interface. Subsequently, you’ll reduce the lines of code in your test file and its readability. The DRY principle plays a big role both in your application’s code and its tests in order to avoid repeating yourself.

Want to improve it even further? Decouple loading a JSON from this test case, make it as pure as possible and then you can freely reuse it across your tests’ codebase.

In short, you can summarize this section with the following words from Paul Hudson:

“Take the time to clean up your tests so you isolate common setup, then add custom assertion functions to avoid repeating yourself. The end result will be shorter tests that are easier to read, easier to write, and easier to check when they fail.” - Paul

Some or None?

Optionality as great as it is can sometimes be bothersome to tackle. However, why would you take care of it in your application’s code but ignore it in its tests?

I could be writing about this, but instead, I will ask you to read John Sundell’s article about this subject. My opinion is quite the same as his so I think we should apply DRY here! 😂

Conclusion

Tests’ code quality must be as high as in your application as you’ll be spending hours creating, maintaining and debugging them, so make sure you create a healthy environment around it. Also, be as coherent as possible and use all the tools in your belt, from design patterns to principles. Don’t disregard your tests, they are an essential part of your codebase!

For further reading, Paul recommends “XUnit Test Patterns: Refactoring Test Code” by Gerard Meszaros.

Huge shoutout to José Figueiredo, Paul Hudson, Rodrigo López-Romero and Tiago Martinho for joining me. I would also like to praise Ana Filipa Ferreira, Heitor Ferreira and Tiago Silva for their outstanding support and João Pereira for giving the “Let’s Talk About” original idea. ❤️

Last but not least, if you have any subject you would like to see covered and/or discussed, let me know here or on Twitter! 👀

Thanks for reading. ✨

Saving Your Screen

2018-12-04T00:00:00+00:00

Building your own screen saver in Swift can be a tricky task since the template provided by Xcode wasn’t designed for it. Still, it’s far from being impossible.

Introduction

According to Quinn “The Eskimo!”, an Apple Staff Member on the Apple Developer Forums, it isn’t safe to create a screen saver in Swift since the current architecture uses an “NSBundle-style plugin”.

“The current screen saver architecture uses an NSBundle-style plug-in. It’s not safe to create such plug-ins in Swift unless you control all the plug-ins and the app loading those plug-ins.”

“Note that this does not apply to modern plug-ins, which are all app extensions. An app extension can be safely written in Swift because it runs in its own process.”

Because of this, screen savers written in Swift need to be bundled with the required Swift standard libraries into the application package. While this may lead to maintainability issues that need to be addressed in every Swift release, it didn’t stop the community from building screen savers written in Swift. As an example, you have both Aerial & Brooklyn.

There’s also hope that the promised ABI stability that is coming with Swift 5 tackles some of these problems.

What’s the goal?

You’ll be aiming to develop a screen saver written exclusively in Swift. Design-wise, it’ll be simple since this article isn’t about creating a fancy animation but instead, give you the tools needed to develop and create your own screen saver.

By the end of this article, you’ll achieve the following screen saver:

Setup

Like any other application, to develop a screen saver, you’ll have to start by creating a project in Xcode.

Xcode already has a screen saver template and you are going to use it to speed up this task. To do so, follow the next steps:

Select Create a new Xcode project;
Select the macOS tab;
Search for Screen saver and select it;
Name it SavingYourScreen and choose its location.

Following this, you’ll notice Xcode generated SavingYourScreen.m and SavingYourScreen.h. But since you are going to develop it in Swift you can safely delete these two files. Once deleted, create a Swift file named SaverView and Xcode will present the following prompt:

As you won’t work with Swift & Objective-C interoperability, just select Don't Create.

Coding that View

To start things off, import the ScreenSaver framework and subclass ScreenSaverView as follows:

With the skeleton ready, it is time to start working on the real implementation, starting by implementing the component required to display an emoji.

While in iOS you could use an UILabel by importing UIKit, in macOS you don’t have access to it. Instead, AppKit provides a component called NSTextField. Unfortunately, this component behaviour is very similar to its iOS counterpart, UITextField. This means, it supports interaction & typing, which you don’t want and in order to remove these functionalities, you’re going to subclass NSTextField as follows:

Now, create an instance of it in your view by adding the following code above your initialization methods:

Finally, implement addSubviews, defineConstraints and setupSubviews as follows:

Everything should look very familiar to you and in fact, it is! Most of the code until now could be used in iOS except for some minor differences between UIKit and AppKit.

However, you won’t be getting the result you are aiming for with it. While you’ve defined the layout for your view, you are still missing the random emojis changing every second.

Start by creating a String extension with the following method:

With it, you can easily retrieve an emoji but what about changing it every second? You could easily implement a timer but the ScreenSaverView has some tools under its belt. According to Apple’s documentation, it has the following methods:

startAnimation() - “Activates the periodic timer that animates the screen saver.”
stopAnimation() - “Deactivates the timer that advances the animation.”
animateOneFrame() - “Advances the screen saver’s animation by a single frame.”

These three methods together provide you a timer embed into ScreenSaverView’s life cycle. Both startAnimation() and stopAnimation are called automatically. To control the pace in which animateOneFrame() is triggered, you need to set the animationTimeInterval property. Since your goal is to show one emoji per second, you can safely define it with 1 inside your configure method. In short, this means that animateOneFrame() will be called every second.

In order to use it, start by adding the following method to your view. It will be responsible for updating the emoji presented on your screen:

Now, you just have to override animateOneFrame() and call updateContent() after super.animateOneFrame(). In the end, your view should look as follows:

Time to get your hands dirty

If you attempt to install it by building and opening the generated .saver (right-click & Open with External Editor as shown in the image below), you’ll notice that instead of seeing your screen saver you’ll face “You cannot use the SavingYourScreen screen saver with this version of macOS. Please contact the vendor to get a newer version of the screen saver.”

As mentioned earlier in this article, screen savers were meant to be written in Objective-C and its template is prepared according to it.

To solve this, start by going to your Info.plist and replace the value for Principal Class with SavingYourScreen.SaverView which corresponds to your target and view joined by a dot.

Now, go to the build settings of your project and change the value for Always Embed Swift Standard Libraries to YES. This will ensure that any of the required Swift standard libraries are also copied into your app bundle.

Conclusion

Although it isn’t recommended to create a screen saver in Swift, it isn’t difficult to go around it, you just need to keep maintaining it every time a Swift version gets released. ABI stability is promised to come with Swift 5 but in the meantime, you have all the tools needed to create your own screen saver.

Take into consideration that you have only scratched the surface when it comes to creativity & possibilities. This article introduces you to screen savers in Swift but you can go further and beyond by downloading resources from any service, draw custom shapes and the list goes on.

In the end, what’s your opinion of it? Have you ever tried to build a screen saver or was it something new to you? Let me know, alongside with your questions, by sending feedback on Twitter or here.

Last but not least, I would like to praise Ana Filipa Ferreira, Heitor Ferreira, João Pereira and José Figueiredo for their outstanding support. ❤️

Thanks for reading. ✨

Power-Up Your Anchors

2018-10-25T00:00:00+00:00

Programmatically done Auto Layout is still the preferred way of implementing views by a lot of developers. While there are amazing open-source frameworks, most of them differ from Apple’s anchor syntax. Therefore, by adding them to your project, you’ll raise the entry level complexity of your project and increase its learning curve. In this article, you’ll learn how to avoid adding an external dependency and create your own layer above NSLayoutAnchor to solve some of its issues.

Introduction

NSLayoutAnchor was first introduced by Apple in iOS 9.0 and it is described as a “factory class for creating layout constraint objects using a fluent API”. Apple’s documentation also refers that NSLayoutAnchor usage is preferred when compared to NSLayoutConstraint: “use these constraints to programmatically define your layout using Auto Layout. Instead of creating NSLayoutConstraint …”. This is due to type checking and having a cleaner interface when compared to NSLayoutConstraint.

Improvements related to type checking are based in Apple’s decision to split NSLayoutAnchor into three different concepts, being:

NSLayoutXAxisAnchor for horizontal constraints
NSLayoutYAxisAnchor for vertical constraints
NSLayoutDimension for width and height constraints

Apple’s documentation also mentions that “you never use the NSLayoutAnchor class directly. Instead, use one of its subclasses, based on the type of constraint you wish to create”. In short, you can never constrain anchors between the different subclasses shown above. But, you can still mess it up, as Apple states:

“While the NSLayoutAnchor class provides additional type checking, it is still possible to create invalid constraints, For example, the compiler allows you to constrain one view’s leadingAnchor with another view’s leftAnchor, since they are both NSLayoutXAxisAnchor instances. However, Auto Layout does not allow constraints that mix leading and trailing attributes with left or right attributes”

First of all, take a look at the following code and try to identify some of NSLayoutAnchor’s boilerplate code.

According to this implementation, you should have found the following requirements:

You must set translatesAutoresizingMaskIntoConstraints to false for every view;
You must activate constraints by setting its property isActive to true or by using NSLayoutConstraint.activate();
You cannot set UILayoutPriority via a parameter and must instead create a variable.

Within this article, you will learn how to address these issues. However, keep in mind that this only applies to Swift.

TranslatesAutor… Yes, that long property you always set to false

Here lies the first identified issue, and Apple is clear on why you always have to set it as false:

“If this property’s value is true, the system creates a set of constraints that duplicate the behavior specified by the view’s autoresizing mask. This also lets you modify the view’s size and location using the view’s frame, bounds, or center properties.

If you want to use Auto Layout to dynamically calculate the size and position of your view, you must set this property to false”

This describes exactly what you want: use Auto Layout to dynamically calculate the size and position of your views. However you don’t want to write this huge property for every single view, not even inside a forEach.

There are multiple approaches to solve this, but for now you will be improving addSubview and adding a side-effect to it. To do so, create an UIView extension with the following code:

With this code, you will be able to send multiple views, set them all as subviews and set each one’s translatesAutoresizingMaskIntoConstraints to false all at once.

Now, instead of doing the following:

You will now have:

What about the remaining issues?

Start by extending NSLayoutAnchor as follows:

This will generate an error:

Prior to Swift 4, you were forced to extend each of NSLayoutAnchor’s subclasses, or constrain it, because it is a generic class. But now you can simply expose your extension to Objective-C.

If you try to compile this, you will notice that the error disappears. Your extension is now ready to use your own code, and that is exactly what you’re going to do.

Activate your constraints!

Setting isActive in every single anchor is excruciating. Even though NSLayoutConstraint.activate() might be considered a better option, according to Apple’s documentation, it still adds a lot of indentation.

One way of solving this would be to set isActive to true by default. You can achieve this with the following:

This function uses a Swift capability called default argument. It allows isActive to be called as an optional argument. By default, it will always be set to true. But in case you don’t want it active, you can set it to false.

By using @discardableResult, you will be returning an NSLayoutConstraint that you can safely ignore if you don’t need it. In case you never heard about this keyword, I’ve written an article titled “I Want to be Discardable” that addresses this.

Too many functions!

Currently, you only support a relation of equalTo when you should also support greaterThanOrEqualTo and lessThanOrEqualTo.

According to Apple’s documentation, NSLayoutAnchor exposes 6 different functions. These are as follows:

func constraint(equalTo: NSLayoutAnchor) -> NSLayoutConstraint
func constraint(equalTo: NSLayoutAnchor, constant: CGFloat) -> NSLayoutConstraint
func constraint(greaterThanOrEqualTo: NSLayoutAnchor) -> NSLayoutConstraint
func constraint(greaterThanOrEqualTo: NSLayoutAnchor, constant: CGFloat) -> NSLayoutConstraint
func constraint(lessThanOrEqualTo: NSLayoutAnchor) -> NSLayoutConstraint
func constraint(lessThanOrEqualTo: NSLayoutAnchor, constant: CGFloat) -> NSLayoutConstraint

While Apple’s approach works, you can reduce the amount of functions in your interface with an enumeration approach for NSLayoutConstraint.Relation as in the following code:

If you try to use it:

Everything seems to be working well. But what if you try to apply a width constraint based on a constant? Add b.widthAnchor.constrain(to: 50.0) to the previous example and rebuild. Oh no, you trigger another error:

But this time it is pretty easy to understand what’s happening. Currently, your function is expecting you to send a NSLayoutAnchor.

To solve this, the following are the two most obvious solutions:

Set the expecting anchor as an optional, NSLayoutAnchor?.
Provide a default parameter.

But none of these are optimal, because:

It would lead to some edge cases that aren’t supposed to be possible and wouldn’t even work. Therefore your interface would allow inconsistencies that didn’t exist before.
It isn’t possible to provide a valid default parameter to NSLayoutAnchor.

According to Apple’s documentation, you are only allowed to set a constraint without any relation to another anchor for NSLayoutDimension’s anchors.

To avoid missing cases that already exist, you should also have the option to apply a constraint between two NSLayouDimension anchors with a constant & multiplier.

In order to address this, you must enable this feature only for NSLayoutDimension’s anchors. Therefore, you are going to extend NSLayoutDimension with the following code:

You’ll now able to apply width and height constraints without any kind of relation to another anchor.

Priorities

Now, you’re going to simplify setting priorities. To set a constraint’s priority in the current model, with anchors, you would need to do the following:

A good way to avoid being forced to assign the constraint to a property is adding this option to your functions. Also, with a default value of .required, you don’t need to type it in most scenarios.

Replace your functions with the following:

However, what if you wanted a priority between .defaultHigh and .required? The current way doesn’t look very clean. In order to improve it, you are going to extend NSLayoutPriority with the following:

And now you’ll be able to do bWidth.priority = .defaultHigh + 1 .

DRY

DRY stands for “Don’t Repeat Yourself”, and it is often seen as a golden rule in software development.

You are currently repeating yourself when setting isActive and priority. In order to follow this pattern, you will move this to a NSLayoutConstraint extension.

Start by adding the following function to your extension:

And now update your constrain functions with the following:

What have you done?

At the beginning of this article, you spotted some problems related to anchors. Now you can proudly check that you’ve developed solutions to each of them.

Having to set translatesAutoresizingMaskIntoConstraints to false for every view that isn’t loaded from a NIB
- You’ve created a new addSubviewsUsingAutoLayout function that supports sending multiple UIView
Activating constraints by setting its property isActive to true, or using NSLayoutConstraint.activate()
Setting UILayoutPriority via parameter is not supported and requires you to create a variable.
- NSLayoutAnchor extensions work together to solve these two problems
Interoperability has its costs to NSLayoutAnchor because it doesn’t allow it to take advantage of some Swift capabilities.
- You’ve reduced the number of functions needed with an enum based approach and adopted default parameters in your interface.

Everything is looking good on paper. However, how does it look in practice?

How does it look?

Before showcasing your new and fresh powered-up anchors, take another look at the initial example shown in this article:

Now you can achieve the same result in a much cleaner way with your extensions:

As you can see, it is a lot easier to read and understand what each anchor is doing. You were also able to decrease the amount of code you needed to write.

Future Improvements

While this will simplify the usage of Auto Layout programmatically, there are some details missing. The following functions aren’t covered:

constraintEqualToSystemSpacingBelow(NSLayoutYAxisAnchor, multiplier: CGFloat)
constraintGreaterThanOrEqualToSystemSpacingBelow(NSLayoutYAxisAnchor, multiplier: CGFloat)
constraintLessThanOrEqualToSystemSpacingBelow(NSLayoutYAxisAnchor, multiplier: CGFloat)
constraintEqualToSystemSpacingAfter(NSLayoutXAxisAnchor, multiplier: CGFloat)
constraintGreaterThanOrEqualToSystemSpacingAfter(NSLayoutXAxisAnchor, multiplier: CGFloat)
constraintLessThanOrEqualToSystemSpacingAfter(NSLayoutXAxisAnchor, multiplier: CGFloat)

If requested, we can review this in a follow-up article.

The End

If you’ve managed to fully read this and reach the end, congratulations on powering your anchors! In the end, what’s your opinion of it? Did you know it already, or was it something new to you? Let me know, alongside with your questions, by sending feedback on Twitter or here.

Last but not least, I would like to praise Ana Filipa Ferreira, João Pereira, José Figueiredo, Pedro Eusébio, Tiago Silva and Farfetch for their outstanding support. ❤️

Thanks for reading. ✨

Guide Your Layout

2018-08-24T00:00:00+00:00

How would you achieve the following screen?

You can easily spot an UIImageView and an UILabel centered together.

There are multiple approaches to this problem and the most obvious would be to insert these two elements in a UIStackView. But what if, in a more complex layout, you weren´t able to use it? The most common approach, although not the best, would be encapsulating the UIImageView and the UILabel inside a UIView.

In this article, you’ll learn how to approach this problem in this scenario.

I’m Here to Guide You!

In iOS 9.0, Apple introduced major changes to its frameworks and added new ones. One of them was UILayoutGuide.

UILayoutGuide is a “rectangular area that can interact with Auto Layout”. It should be used to replace any UIView used for “inter-view spaces or encapsulation” since it improved efficiency and safety by avoiding the following issues regarding these kind of UIView (dummy views):

Creating and maintaining a UIView impacts performance
Each member of the view hierarchy adds overhead to every task the hierarchy performs
A dummyView will be able to intercept messages that are intended for other views

It’s also important to notice that, similar to UIStackView, UILayoutGuide cannot have a background color, among other properties.

World’s Most Famous Guide

Alongside with iOS 11, Apple introduced the Safe Area Layout Guide while deprecating the top and bottom layout guides.

According to its documentation, safeAreaLayoutGuide is “the layout guide representing the portion of your view that is unobscured by bars and other content”. It can also be confirmed in its declaration below, that safeAreaLayoutGuide truly is an UILayoutGuide:

Time to Solve Problems

With all the knowledge acquired, you are now able to solve the initial problem using UILayoutGuide instead of a dummy view.

To start off, if you were using an UIView for encapsulation, you would start by creating it and adding it to the hierarchy:

This time, since you’re using UILayoutGuide, you’ll need to create an instance of it. Then, instead of adding it by calling addSubview(UIView), you’ll be using addLayoutGuide(UILayoutGuide).

Notice that, since UILayoutGuide isn’t a member of the view hierarchy you’ll be adding your views to view instead of layoutGuide.

You’re now done with the UILayoutGuide’s initial setup and with so, it’s time to move to constraints. In the end, it is similar to what you would do with an UIView.

Keep in mind that photoImageView and introLabel setup isn’t in the scope of this article. Still, if you’re interested in it, take a look here.

Conclusion

Most of the times, you’ll end up using a UIStackView to solve problems alike but there are cases where UILayoutGuide shines. The presented problem isn’t the case and it was just used for a matter of presentation.

Unfortunately, in case you prefer working with Interface Builder, UILayoutGuide isn’t available there.

In the end, what’s your opinion of it? Did you know it or is it something new to you? Let me know it, alongside with your questions and feedback on Twitter or here.

Last but not least, I would like to praise Ana Filipa Ferreira, Tiago Silva, José Figueiredo and João Pereira for their outstanding support. ❤️

Thanks for reading. ✨

I Want To Be Discardable

2018-07-19T00:00:00+00:00

Ever wanted to ignore a value returned from a function but if you do so you’ll end up with the following warning?

First of all, take the following function as an example for this article.

In most scenarios, you would use ‘_ = example()’ to silence the warning. While this is correct, adding ‘_ =’ every single time would create a lot of boilerplate code and your public interface wouldn’t seem well designed. Keep in mind that changing the function to Void isn’t an option for this specific example because we might want to use example()’s return in some scenario.

The Hero

Prior to Swift 2, this warning wouldn’t appear unless you’ve marked your function with @warn_unused_result. In Swift 3, Apple turned on this warning by default and introduced @discardableResult.

“Apply this attribute to a function or method declaration to suppress the compiler warning when the function or method that returns a value is called without using its result.” - Swift.org

This mark is available since iOS 8.0.

Ignore this, Ignore that, I want those

Previously you’ve used ‘_ =’ to ignore a function result, but this time, you are going to do that by using @discardableResult. To do so, you’ll add @discardableResult to the previous function. Resulting in:

Now, invoke your function, compile and you’ll verify that Xcode didn’t show any kind of warning this time. But what if you want to use the value returned?

If you run the code above you’ll see that “This is an example” is printed followed by “This is an example with discardable”, meaning that you’ve successfully stored the result of example() in value, appended “ with discardable to it” and finally printed it.

Real-World Examples

You don’t have to look too far to find some real-world examples. Take a look at Apple’s NSLayoutAnchor for example. If you notice when you apply a constraint with anchors, in case you need to save it locally to define a priority, you could easily do:

If you don’t want use the NSLayoutConstraint returned, you’re also allowed to ignore it without Xcode displaying any warning.

There are many other cases where @discardableResult can be useful, for example, it can also be handy for chaining functions and logging.

Conclusion

So, should you use it every single time you have a return value? The answer is no, absolutely not. Your interfaces should be as clear as possible and @discardableResult usually means your function has side-effects and adds a small implementation detail that doesn’t have much visibility, therefore, it could lead to some readability problems and inconsistencies. Plus, it shouldn’t be used when you are expecting to use the result of a function most of the times.

And with this, you’ve now acknowledged @discardableResult. What’s your opinion about it? Did you know it or is it something new to you? Let me hear it, alongside with your questions and feedback on Twitter or here.

Last but not least, I would like to praise Ana Filipa Ferreira, Tiago Silva, Pedro Eusébio, José Figueiredo, Warren Burton and João Pereira for their outstanding support. ❤️

Thanks for reading. ✨