Even though they are sometimes overused , enums are still a great tool. Thanks to Codable they can easily be decoded from JSON sent by your backend. This is great until you need to add a new case to the enum. Then you have to either deal with versioning your API or you need to tell your users to update the app. In some cases you have no choice, but in other cases it would be fine to just ignore…
I often see a pattern where there is an enum with a bunch of computed properties that return a different value for each case. In the rest of the code base then only those properties are used. Something like this: enum Style { case headline case bodyText case emphasis var isBold : Boolean { switch self { case . headLine , . emphasis : return true case . bodyText : return false } } var fontSize :…
While investigating the new AttributedString API I realized you could use the same techniques to build a generic fluid builder interface for any type. This is what I came up with: And here is an example how you can use it:
Finally we are going to get attributed strings as a native Swift value type. So lets see how we can update the example of my last article about attributed strings:
I had to take a string like “Name (whatever)” and display it in a label. The Name part should be bold, and anything in parentheses should use the regular font.
Especially on iOS it’s often necessary to create new objects like new view controllers or such things. This often cannot be avoided. This usually is solved by having the object that creates new objects also require all the dependencies of the objects it wants to create. This of course is not a great thing as changes in one class can ripple through the whole project. The protocol composition…
I recently read the article “Using protocol composition for dependency injection” by Krzysztof Zabłocki. I found this to be a rather interesting technique for doing DI, but when trying to implement it I found it somewhat limited:
Another attempt to write a blog. Lets see how it goes this time.