View profile

 iOS Code Review - Issue #28 | Curated code improvement tips

 iOS Code Review
 iOS Code Review
@ios_code_review
Hi there,
I hope you find something useful or interesting in today’s collection ✨

Live-updating cells
Starting with iOS 15, there’s a set of reconfigure methods that let you update a cell that’s already on-screen. This allows us to make nice animations to views inside cells, which are not possible with reloadData - as it recreates cells from scratch.
In earlier iOS versions it was also possible to update existing cells, by getting on-screen cells with UITableView.cellForRow(at:) and updating the state manually. reconfigure can do that with less friction, and it can also update the height of the cell.
Check out Tyler’s thread for a deeper dive into the new methods:
Tyler Fox
iOS 15 introduces a new way for you to conveniently update content displayed in existing cells in UICollectionView and UITableView: reconfigure.

When and why should you use reconfigure? How is it different from reloading an item or row?

Let’s dive in with a quick thread.
Approaches to mocking
Using the factory pattern is a common approach to mocking, but with Swift there are simpler approaches that work just as well: such as injecting values, injecting behaviour as closures (as opposed to injecting instances that perform a behaviour), or having factory methods as closures (as opposed to factory classes). In this thread Nick goes into different ways one can mock behaviour or values:
Nick Lockwood
We joke a lot about AbstractHammerFactories and over-engineering, but I've realized (based on code reviews) that a lot of iOS devs don't really seem to understand the purpose behind mocking and factories and when it is and isn't appropriate to use them.

So here's an explainer 🧵
TL;DR:
Nick Lockwood
So next time you find yourself creating yet another AFactoryProtocol, ask yourself:

* Could this just be a closure, or a static method on AProtocol?
* Do I need a factory at all, or can I just inject an instance?
* Do I even need to inject a mock of A, or can I just decouple it?
On code readability
One comment from Nick’s thread stood out to me - it really highlights the two extremes of code architecture: “hardcode everything” => no flexibility, changing one thing breaks other places; vs “mock everything” = code is not discoverable, no transparency in what to change code to achieve the goal. Balance is somewhere in the middle.
davidoff
@nicklockwood « is this really needed. » is a good question.

If “labelHeight = 12” is certainly Technical Debt

“labelHeight = FactoryManager.instance.get(A.Type).Make().getLabelHeight(LoginLabel)” is Code Quality Tax that will need additional time to make, to train, to read and to fix.
Technical debt is debt
Sometimes we say “there should be no technical debt”. It’s a really good aspiration, we’ve all been there. But as in life, going into debt can be beneficial:
Gergely Orosz
Is leveraging a credit line a smart way a good thing? Of course. It's how many get their first house (mortgage), start a new business (business loan) or borrow money (e.g. company bonds).

So why do we wonder if leveraging tech debt a smart way is a good thing?

Of course it is.
but also:
Testing Codable initializers
A well-structured and understandable article on unit-testing custom Codable initializers. Lots of little gems in there - for one, the Difference library looks like a huge quality-of-life improvements for unit tests.
How to test custom Codable initializer | Danijela's blog
Sometimes, when parsing a JSON, you need to implement a custom Codable initializer. Because of that custom logic, you’re no longer using the default implementation. It’s a good idea to test your code.
danijelavrzan.com
🤘☮️
Alright, that’s it for today. 
Did you enjoy this issue? Let me know by pressing the buttons below. If you enjoyed it, you can help grow the newsletter by spreading the word ☺️
Got feedback? Want to see more, or less of certain kinds of tips? I’d love to hear from you. Reply to this email or reach out on Twitter via @ios_code_review 🙌
Did you enjoy this issue? Yes No
 iOS Code Review
 iOS Code Review @ios_code_review

Bi-weekly newsletter amplifying code improvement tips from the Apple developer community in a bite-sized format. Swift, Objective-C, iOS, macOS, SwiftUI, UIKit and more. Curated by Marina Gornostaeva and published every other Thursday.

For feedback or sponsorship ->> [email protected]

In order to unsubscribe, click here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Created with Revue by Twitter.