Programmers can be a pedantic bunch. We like everything to be consistent. Uniform. Organised. Just so.
Everyone seems to be striving for ‘clean’ code at the moment. You can’t read a blog post without the author telling you how clean their approach is. Engineering teams get together and discuss which of the possible solutions is the cleanest. Other developers assure you that they practice ‘clean code’.
It feels like Swift is pretty ubiquitous across the Apple ecosystem now, but there’s a lot of Objective-C out there. The larger and older the app, the more likely that there’s still a bunch of Objective-C powering various bits behind the scenes.
If you want to test your Swift code, at some point you’re probably going to need to make some mocks in order to isolate a type that you’re testing from system apis. For instance, if your type calls UNNotificationCenter, then in your tests you don’t want it to call the real UNNotificiationCenter, but rather a mock substitute that you control.
It’s not uncommon that we need to model a dataset composed of a finite number of discrete data types, where each data type has it’s own unique data model. This is often the case for table view data sources - they’re often comprised of a few different cell types, with each cell type having a different set of properties that it needs to be configured with.
I’ve been thinking about tableviews recently. Table views and collection views have become the default way to build UI for many types of applications, especially content driven ones. As our table views become increasingly complex though, testing that they’re showing the correct content becomes difficult to do.
When I first started writing Swift, I felt like Optionals were a constant pain point. Everything seemed to end up being Optional, resulting in me littering if lets and guards around my code, and generally just making a horrible mess of things.
Remember how awesome the delegate pattern was in Objective-C? Enabling classes to be super reusable by delegating out the bits that you might want control over. There’s a reason that it’s so ubiquitous across Cocoa Touch, it’s just so damn good!
I’m sure we’ve all come across the comment wrapping problem. You write a long comment that looks like this:
iOS and macOS apps have a version number and a build number. Typically you see these in Xcode or iTunes Connect represented something like this:
How can you call a delegate or closure callback, passing in arguments that are lazily calculated? This was an issue that I had recently, so I thought I’d share how I solved it.
All applications need to do some sort of data transformation. It’s unlikely that the information that you get from your api or database will come in exactly the format or order that you want to display it in, and you will likely have to perform some sort of sorting, filtering, or other manipulation to extract the information that your app requires.