How to write clean code when it comes to data sources and delegates.
In this article, we will improve the code that goes within our data source methods to make it more meaningful, understandable, and maintainable, either for table views, collection views, or any other kind that we need.
Disclaimer: This content is not about any different way of working with data sources, but rather about enhancing the internal implementations of the existent good-old and well-known data source methods.
All it takes to have cleaner data source implementations is to stick to these statements:
In this article, we will face a question that we should always ask ourselves when writing a function:
How should I name this function?
Although this question looks simple, getting it answered properly determines a crucial aspect in our professional lives as software developers. It makes our codebases cleaner and easier to use, as we will see.
If you were to use a function from a third party library, let's say for creating fancy labels, and you find these two options:
static func makeLabel(withTitle title: String) -> FancyLabel// B
static func configure(_ text: String) -> FancyLabel
I wrote this article almost two years ago. Unfortunately, the website where I published it shut down. By luck, though, I've been recently told I was allowed to republish this content, which is what I'm gladly doing right now.
Special thanks to Brujo Benavides who pushed so hard on getting these contents back to the Internet. Soon, I will revive some other articles I wrote, which are worth the respawn too. Stay tuned.
This blogpost in particular contains lots of time references, so, when it says "2 months ago" it now means "21 months ago", "recently" now means "a while…
The Strategy Pattern is one of the first design patterns I’ve learned in the theory. Sadly, however, it was very difficult for me to find real use cases where it could be applied in actual iOS codebases. Most books and tutorials showcase examples that are good for understanding what the pattern goes about (by using everyday objects such as animals, vehicles, or pizzas), but are usually far away from the actual code that you encounter in your projects.
In this article, I will expose concrete scenarios that I've recently stumbled upon while developing some iOS apps, and in which I…
Quite often in iOS projects, it happens that QA people find issues like this one:
Usually, they report the bug, and, when it’s your turn to fix it, the first thing you think is “Okay, I’ll put a breakpoint where the alert is created and see what’s going on”. Next step, you’re doing something like this:
Engaging gears in a project involves powering up our everyday processes. In the iOS world, a very important one is how we deal with environments and other settings that need to be customized depending on the audience. Xcode does have a set of tools to help us along the way. Unfortunately, though, I've seen that most of the times teams are not even close to take the best of these tools. It's not their fault: I think Apple doesn't do very well at encouraging good practices, as they just provide not-so-useful configurations by default.
In this article, we'll explore how…
It’s been a while since I shared Getting the right colors in your iOS app, a blogpost I wrote for helping iOS devs prevent the color nightmare that happens every now and then. That blogpost was cool and got more visits than I expected, but, the information I exposed at that moment was neither complete nor certainly accurate, and it got outdated very quickly too. My appologies for taking too long to write about it again.
Today, I bring this update in order to help the iOS community once more, because, I found that there aren’t much articles out there…
#iOS developer. Incessant learner. Clean-code lover. #SwiftLang developer