Rob Bearman
June 13, 2016

Can Service Workers service background applications?

I had a thought experiment on how I might port an application I once developed for native Android to a web app, even if it were to run solely on Android devices. The application behaves like a mantle clock: every fifteen or thirty minutes, it wakes up and plays a custom chime. My son used to call it "Big Ben in Your Pocket."

The app seems perfect for a web app approach since it's primarily visual UI and it plays an audio resource on a timer. The problem is that you want the app to wake up and chime on a regular schedule, even if the user doesn't have the application running in the foreground. In native Android, you employ an Android Service which runs in the background on a thread separate from the application's UI thread, and can run and wake up when the application isn't running in the foreground. In many ways, Android Services feel like Service Workers but with a critical exception: Service Workers have indeterminate lifetimes and I think the only way to wake them up is for them to receive a push notification. Android Services can be woken up through events like a local alarm notification.

My question for the Service Worker folks is: how would I implement this as a web application? Conceptually, I'd have a timer running in a Service Worker, but since the Service Worker can be killed by the "OS" at any time, the timer dies with it. Waking up the Service Worker with a push notification is not a good local solution, as some server-based service would have to send 15-minute wakeup calls to all subscribed users. I think Greenwich already cornered the worldwide timer market.

There are other application examples where you want local wake up of a background application. The question I have is whether Service Workers will make these web applications possible.

While I was pondering this question, I noticed that Alex Russell over at Google has a really good recent post on installation strategies for PWAs, and he references Ada Rose Edwards' followup discussion on the state of web applications. Ada's post led me to read more on Financial Times's strategy for building web applications with support for offline (disconnected) and unreliable network conditions. Financial Times uses the older Application Cache (AppCache) mechanism since the more modern Service Worker currently has limited browser support outside of Chrome. AppCache is implemented on a wider range of browsers, and in particular, Safari.

The difficulty from a developer or product planner perspective in attempting to move away from native app development and toward PWA is bridging the differences between browser capabilities. For certain application types, being able to run offline is everything, and without universal (or at least modern) browser support for this, you're going to have a difficult time convincing people that limiting your customer base only to specific optimal browsers is a good thing. On the other hand, developing your web app to support both Service Worker with an AppCache fallback seems akin to balancing the development costs between native Android and iOS. So what's the best strategy to move forward today?

I asked, and Ada gave a response: target Service Worker browsers. The lack of universal support remains an open issue.


« Blog home