Model-Defined Interfaces
A Pattern for Better, Safer, and More Explicit API
Most iOS architectural patterns rely on protocols to define what data and behaviors (i.e. interfaces) will be available to client code. This is a perfectly workable approach, but it adds quite a bit of overhead in terms of creating the protocol and multiple conforming types.
For example:
protocol AuthenticationProvider . . .Creating a Sustainable Software Cycle
Breaking the perpetual deadlock of legacy code, lack of testing, and missing documentation
Having been an iOS developer at quite a few tech companies, from small to large, I’ve found that they all mostly share the same painful reality of software development:
- Lots of fragile legacy code that is risky to refactor or update because it is untested
- Tests can’t be written for legacy code because what it even . . .
A Fresh Look at Testing
There are as many opinions about testing as there are developers, and then some. The opinions run the range from considering all testing a waste of time, to the belief that only unit testing is worthwhile, to an insistence that end to end tests are the most important, to a dismissal of end-to-end tests as not maintainable.
Because . . .
WWDC 2017 Wishlist
It's the night before WWDC and so while this post is pretty late, its technically not too late to be appropriate. But not having much time to type this up means that I'm not able to go into as much detail as I normally do for these wishes and they are all going into a single post.
Some interesting context going into WWDC . . .
A Single Writer Pattern in Swift
A Fun Experiment With Shared Mutable State and Lock-Free "Locking"
I was talking to a co-worker today about different ways to minimize the risks around having a single shared instance in any app that holds global values which can be read and written to from anywhere in the code.
The potential risks around global mutable state are discussed in lots of places, but some of the key problems are:
. . .Towards Better Unit Testing
Last year, I wrote a post about the problems with code coverage as a metric, and left the topic as “to be continued”, saying that I had some ideas for a better approach. Well, it's taken long enough, but here are the first pieces in that objective to evolve a better way to create and measure well-tested software.
What Makes Good . . .
A Swift-y Approach to Dependency Injection
While I would guess that fewer iOS developers are concerned with Dependency Injection than say, Java developers, the concept has gained more steam on the platform as the practice of unit and integration testing has increased.
In short, Dependency Injection (or DI) consists of:
Making your structs or classes depend on . . .