6 Posts


Routing in SwiftUI

June 3, 2020

I probably should have waited for the next iteration, but I was starting a new side-project and, well, there was that checkbox to use SwiftUI staring at me, taunting me, luring me in with the sweet promise of unending UI layout bliss. So I scrunched up my face, clicked the box, waited a minute for the trumpets to die down, and then created the project.

This is not a thoughts post on SwiftUI. It’s too early for that. Besides, there’s plenty of posts out there on the interwebby thing if you want an opinion. Plus, I want to wait until version “2” comes out for, you know, when Apple has had a chance to take their beta and turn it into a real boy.

Instead of creating a “thoughts on SwiftUI” post, I’m going to wrap my current thoughts on SwiftUI into what I hope is a somewhat comprehensive — or maybe just an acceptable — discussion on one piece of architecture: Routing. That’s safe, right? It’s not like SwiftUI isn’t going to suddenly change their whole paradigm this year.

Okay, enough with the disclaimers; let’s talk about Routing.

Read More

Interface Design

January 20, 2018

One of the key pillars of good architecture revolves around Interface Design. The reason for this is deceptively simple: software is complex and we want to do everything we can to make it as simple and easy as possible. Part of the entire point of OOP (Object Oriented Programming) is to abstract complicated code into objects and then hide that complexity behind a simplified interface. That way programmers don’t need to know what’s going on behind the scenes, and instead can deal with the abstraction. The interface should be the only thing someone needs to know about that object to use it. The only time someone should even consider the implementation is when they’re modifying it. This is an essential tool in battling the complexity of a codebase.

Read More

A Deeper Look at Handlers

October 10, 2015

Now that I’ve spent quite a bit more time implementing a “handler” based development approach, I’m finding that there’s quite a bit I like about it. I still have some frustrations with it, and some unresolved questions, but overall I think this approach has some serious merits that warrant consideration as an Architecture approach to handling complex dependencies.

To give some perspective, I’ve been using this approach to construct a transport layer client for a messaging service. The service is not simple, with concepts of multiple messaging types, rooms, user, orgs, members, a “mentioning” system, markdown-like parsing, etc. It’s responsible for communicating with a TL layer (via a socket), persisting data, managing sync, updates, etc. As you can imagine, there is a lot of interdependencies doing on here, many of which can only resolve asynchronously via network calls. For example, A Member is a User and and an Org. So before you can have one, you must ensure you have the others. This results in a lot of what I call “asynchronous interdependent behavior” among the various machinations in the code. The reason I turned to a handler-based approach was that I found that these interdependencies were so numerous and varied that attempting a protocol based approach would end in a proliferation of single-use protocols. Moreover, Swift has limitation on protocols that I’m not quite pleased with. This is not to say I don’t use protocols. The TL client exposes itself to the rest of the app (it’s a module) via several protocols. But internally, that was not the right approach.

What I’ve realized is that this approach is extremely useful to a specific set of requirements, but the approach is not useful in all situations. To me, this is a new “tool” I’ve learned… a conceptual model and practical approach useful to a circumstances and requirements I’ve commonly come into contact with. It’s an architectural model useful to solve certain problems but definitely not all problems.

Read More

Handler-based Development

August 15, 2015

Lately I’ve been writing a Swift module for a project at work. I decided to branch out a little bit by utilizing a different design philosophy than I’ve used in the past. While Apple sits around and pretends that protocol based development is actually something new and exciting, I’ve been much more interested in the functional abilities that Swift seems to endow us with. To that end, I decided to escew protocols and instead define the dependencies in my objects using handlers1 instead. This means instead of defining a protocol and requiring an object that conforms to this protocol, I simply require the specific behavior itself. An example of a simple handler might be:

	typealias GetUserForID = (userID: String) -> User

A protocol, instead, might look something like this:

	protocol UserRetrieval {
		func getUserFor(id: String) -> User

At first glance these really look similar, except perhaps the the protocol is a little more verbose, which might not actually be a bad thing. I’ve noticed a trend with Swift devs (myself included) to be overly concise with their code which disturbs me because in the end it simply creates short code that’s impossible to read.

  1. Or callbacks, functors, whatever… I’m going to stick with the term “Handler” because it seems to implicate the dependency, like I’m depending on someone else to “handle” the dependent behavior I need. If you want, feel free to copy this and do a search & replace for callback or functor or another term you feel more comfortable with. 

Read More

Functionally Taming Optionals

February 15, 2015

There are a lot of blog posts and probably even more opinions about Swift. I will continue this short, but certainly worthy trend.

One common opinion I keep hearing is about how the Optional system kind of sucks, and is perhaps better in theory than in practice. I would like to take a brief, slightly inebriated moment to defend Swift’s optional system and provide some tricks I have found that greatly help to tame the optional system and provide a path out of “if-let nested hell”. 1

But first, let’s talk about why Swift’s Optional is truly great. Many other peopld have spoken of this and Apple itself has loudly proclaimed the benefits. The shell of the nut, though, is this: Optionals force you to deal with the possibility that a value doesn’t exist. If there is a variable (or parameter) and it’s not an optional, you can be sure that variable exists. If it is an optional, the only way to access that variable is to account for the possibility that the value doesn’t exist. After working with my own frameworks and creating apps for client in Swift I will say this: it works. Yes, it may be annoying to deal with at times, but after creating an app in Swift I found there were several types of bugs and crashes that simply did not exist. All of my bugs were functional in nature2. I never had a bug where I thought I was dealing with one Type but instead it was another. Not once did my app crash because an object was nil. Whatever difficulty the Optional system might entail, it is well worth the price of admission, IMHO.

  1. It should always be presented in qoutes, necessary to impart the proper gravity of the situation. 

  2. I’ve also had bugs with the Swift compiler (not to mention the extremely irritating SourceKit Editor crash). But this is improving a lot. I’ve been playing around with Swift 1.2 and it’s convinced me that Apple really is serious about Swift. 

Read More

In Need of Some Conventions

January 24, 2015

There are three things I told myself I would not do when I started developing in Swift:

  1. I would never bang an optional. I think the optional system, though sometimes annoying, is a great idea. Banging optionals is dangerous… as I’m sure my wife would agree.
  2. I would never use an emoji for a variable. Seriously, just because you can do it doesn’t mean you should. Not even the poop emoji. It’s only funny once and then you have to copy and paste the shit all over the place and no one likes that.
  3. I would avoid custom operators for the sake of anyone else that might look at my code.

Unfortunately, I’ve only managed the first two, even though Xcode persistently insists on banging all of my @IBOutlets. And seriously, why? Why do they do that? For the life of me I can’t think of a single reason aside from sheer laziness. I’ve often used the same View Controller for several different Wireframes, many of which don’t have the same views or configuration… thus, ! is stupid and dangerous. It always is and always will be in Swift… don’t use it.

Arg… I got sidetracked. Damns bangs.

Read More