When Our Connected Devices Lack Their Connections

QR (Quick Response) codes have undergone something of a renaissance during the pandemic: Where I live in Australia, we use them to check in at a restaurant or cinema or classroom. They anchor the digital record of our comings and goings to better assist contact tracers. It's annoying to have to check into such venues this way—and even more annoying when it doesn't work.

Not long ago, I went to a local café, only to have the check-in process fail. I thought the problem might be my smartphone, so my companion gave it a go, using a different phone, OS, and carrier. No luck. We later learned the entire check-in infrastructure for our state had gone down. Millions of people were similarly vexed—I would argue completely needlessly.

Nearly all the apps on our smartphones—and on our desktop computers—rest on networked foundations. Over the last generation, network access has become ubiquitous, useful, cheap, and stable. While such connectivity has obvious benefits, it seems to have simultaneously encouraged a form of shortsightedness among app developers, who find it hard to imagine that our phones might ever be disconnected.

Before the arrival of the smartphone, we encountered connected devices only rarely. Now they number in the tens of billions—each designed around a persistently available network. Cut off from the network, these devices usually fail completely, as the contact-tracing app did for a time for so many Australians.

People who develop firmware or apps for connected devices tend to write code for two eventualities: One assumes perfect connectivity; the other assumes no connectivity at all. Yet our devices nearly always reside in a gray zone. Sometimes things work perfectly, sometimes they don't work at all, and sometimes they only work intermittently.

It's that third situation we need to keep front of mind. I could have checked into my café, only to have the data documenting my visit uploaded later (after some panicked IT administrator had located and rebooted the failed server). But the developers of this system weren't thinking in those terms. They should have taken better care to design an app that could fail gracefully, retaining as much utility as possible, while patiently waiting for a network connection to be reestablished.

Later that same day, I tried to summon my smartphone-app-based loyalty card when checking out at the supermarket. The app wouldn't launch. “Yeah," the teenage cashier said, “The mobile signal is horrible in here."

“But the app should work, even with a crappy signal," I insisted.

“Everything's connected," he counseled, leaving it there.

Like fish in water, we now swim in a sea of our own connectivity. We can't see it, except in those moments when the water suddenly recedes, leaving us flapping around on the bottom, gasping for breath.

Typically, such episodes are not much more than a temporary annoyance, but there are times when they become much more serious—such as when a smartwatch detects atrial fibrillation or a sudden fall and needs to signal that the wearer is in distress. In a life-or-death situation, an app needs to provide defense in depth to get its message out by every conceivable path: Bluetooth, mesh network—even an audio alarm.

As engineers, we need to remember that wireless networking is seldom perfect and design for the shadowy world of the sometimes connected. Our aim should be to build devices that do as well as they possibly can, connected or not.

This article appears in the March 2021 print issue as “Spotty Connections."