A Case Against // MARK: Comments
MARK comments are often recommended as a way to divide a construct (class, enumeration, struct, etc.) into sections of related methods and properties. Here's how such annotated class may look like:
Read more →MARK comments are often recommended as a way to divide a construct (class, enumeration, struct, etc.) into sections of related methods and properties. Here's how such annotated class may look like:
Read more →There are two common ways of adding new features to UIViews: composition and subclassing. Today I'd like to focus on a third, less known, but often a more fitting approach: extensions (or categories in Objective-C).
I wrote about setting up Continuous Integration and Delivery with fastlane and Travis CI on Macoscope's blog.
UITableView is a bread and butter of (almost) all iOS developers.
In most cases we simply present a single data type using the same UITableViewCell class and reuse identifier for all items.
Guys from objc.io got us covered here.
Situation gets more complicated when we want to have two, or more, different types of cells in one table view.
Heterogeneity of items makes things hard to implement in context of the type system.
For the past few days I've been trying to bring one of my older codebases up to date with iOS 9 and Xcode 71. Today I stumbled on some code using map method from Mike Ash's MACollectionUtilities library. I started thinking whether it's possible to make this method generic. Let's see what we can come up with.
Read more →