alastaircoote.github.io

Structuring the project, and communicating with a WKWebView

2017-07-19T00:00:00+00:00

I’ve made some relatively boring progress lately - primarily in splitting the code up properly into discrete projects, so that people will be able to pick and choose their level of integration. Right now I’m expecting it to look like this:

ServiceWorker: the actual JS environment code executes in. Basically a wrapper around JavascriptCore that provides some of the stuff it doesn’t, like setTimeout, fetch and importScripts. It also provides stubs for things like ServiceWorkerRegistration, but leaves the implementation up to the user.
ServiceWorkerContainer: …which is an implementation of ServiceWorkerRegistration and the like. Basically it’s the glue that joins service workers together, and provides the bridge to…
SWWebView: the actual component people will use in their apps. As the name implies, I’m hoping I can get this as near as possible to a drop-in replacement for WKWebView, allowing people to augment their existing apps relatively easily. But if they don’t already have an app…
I dunno what I’ll call it: A wrapper around SWWebView that will basically create a full navigation stack for an app. This part will be particularly complex as it moves completely outside of the Service Worker API itself.

Anyway. To more immediate concerns

Communicating with a WKWebView

My initial hack version used WKScriptMessageHandler to allow webviews to send messages back to the app, then used evaluateJavaScript to send responses back. This had quite a few problems:

The send and receive are totally disconnected. So I had to manually store unresolved promises in an array and pass the array index through to the native code… then send that index back with the response. The whole thing was kind of a mess, not least because I needed to keep very close track of any errors so that I didn’t have an ever-ballooning array.
It didn’t work with <iframe>s. evaluateJavascript doesn’t let you target which frame you want to execute the script in, so it always goes to the top-most frame. From there we’d have to (somehow) find a reference to the correct frame and pass the message down.

However, iOS 11 brings us a new API to play with: WKURLSchemeHandler. It let us register a custom URL scheme, then receive any incoming requests for that scheme and send whatever we want back. It’s actually how we’ll power the fetch event, too - but it can also serve as a method of communication. Being an HTTP call, we can pair request and response very easily in the browser. And the response will go to whatever frame send the request automatically. I’m sure there is a performance overhead in adding this HTTP/JSON overhead, but we don’t use these calls that much, so I’m optimistic the switch will be worth it.

URLSession and GZip

2017-07-19T00:00:00+00:00

Another short entry, just to make a search engine indexable note about something I’ve discovered. It appears that when using URLSession in iOS, there is no way to stop the OS from decompression gzipped content. Normally you’d want it to do this, but in my case I would actually prefer to preserve the gzipped body on disk. Worse, having the gunzipped body means that the Content-Length header is no longer accurate, and when you’re using SQLite 3’s blob streaming functions (which I am, more on that later) you need to know the length upfront.

Long story short, I have no answer on accessing the gzipped body. It doesn’t seem to be possible, at least not right now. But there is some good news: URLSessionTask has a property named countOfBytesExpectedToReceive, which is accurate for gunzipped content. So, in my Fetch implementation I’m now rewriting headers as they are passed to JS - removing the Content-Encoding header and rewriting the Content-Length one. Not great. But better than nothing.

URLSession, willPerformHTTPRedirection and timeouts

2017-07-14T00:00:00+00:00

Erk. It’s been a month since I started this thing and I haven’t updated it in a while. I’ve been busy on other stuff at the lab, but have been plugging away at bits and pieces when I can find the time. Lately, I’ve been trying to replicate the Fetch API in iOS. The first hacky version kind of sidestepped the details of the API and just downloaded whole files into memory, but we want to be a little smarter than that, since we might be downloading multi-megabyte files into our cache, or something like that.

But anyway, more on that when it’s actually done. In the meantime, a very quick note about an infurating bug I (think I) stumbled upon. The Fetch API has a redirect attribute that lets you control whether your request follows redirects or not. iOS’s URLSessionTaskDelegate has a method called willPerformHTTPRedirection that lets you control this, via an asynchronous completion handler - you either pass the new, redirected request to it, or pass nothing - if you pass nothing it’ll just return the unredirected response.

Expect it won’t always. The first time you run it, it will. The second time it just hangs until the request times out. You might be able to imagine how confusing this was when running my test suite. It appears someone has already filed a bug report but in the meantime I have the Fetch implementation manually setting the URLRequest.CachePolicy to reloadIgnoringLocalCacheData when redirect is set to manual, which seems to restore the behaviour we expect, even if it isn’t using the cache.

Anyway, hopefully someone will stumble across this post when they put some of these terms into Google and save themselves some of the time I wasted working out what was going on here!

UNNotificationServiceExtension and memory

2017-06-16T00:00:00+00:00

As previously noted, my hacky attempt at making a service worker implementation really came undone when it tried to handle push messages. UNNotificationServiceExtension has a hard memory limit, and if your code hits that limit it’ll immediately terminate the process without letting you change the content of a notification. Not great.

So I’ve been trying to find a way around this. Testing the limit is very difficult, because you can’t use the service extension with a local notification - it has to be a remote one. So I’ve upgraded my phone to the iOS 11 beta (more fool me) and created a tiny test app that sends HTTP calls to a service that’ll send me a remote notification. Then, it checks to see if the UNNotificationServiceExtension successfully manipulated the content of the notification or not. Then, in the extension itself, I’m spinning up a JSContext, and executing code inside it that creates a Uint8Array of ever increasing size, until it reaches a point where the extension crashes.

My initial tests showed that it reached this around the 900KB mark. Not awful (at least it runs), but really not great either, as this is an entirely empty JSContext, and I still need to populate it with the various worker APIs we depend on, which will take up more and more memory. Worse, it turns out that iOS doesn’t close the extension when it has processed a notification - it keeps it alive for some amount of time (I have no idea how long) to process a second notification, should it arrive. There was some kind of garbage collection issue that meant the JSContexts were not being collected, so when a second notification arrived the extension tried to make a second JSContext and crashed immediately.

Not good at all. But, with garbage collection on my mind (which we can’t control in Swift), I tried something - recreated the extension in Objective C. And, somehow, the amount of memory it could use kept ticking up and up, reaching 10MB. Great news, but I immediately had nightmares of having to make the entire library in Objective C, which I don’t know well at all. But to my surprise, pulling in my ServiceWorker Swift module into the Objective C extension worked, and without decreasing the memory limit.

I don’t really understand why this works, and I’m waiting to trip up on something major, but for now I’m making the bulk of the code in Swift, and then going to Objective C to write my (pretty small) notification extension code. I already ran into one issue - if I don’t unassign the exceptionHandler of the JSContext it has the same issue as the Swift version - so I’ll have to be vigilant and run this test app on a regular basis to make sure I’m not making any references that lead to the JSContext sticking around. But overall, good news - it looks like we’ll be able to process push messages.

importScripts()

2017-06-15T00:00:00+00:00

Issue number one. I totally ignored importScripts() functionality when first hacking around with this because it didn’t seem necessary, but if I want to end up with something spec-compliant, it’s pretty crucial (the Google SW toolbox uses it, for one). importScripts is weird. But after reading the spec and a number of GitHub comments I think I’ve nailed the functionality down. This is how I’m going to implement it, anyway…

I had assumed importScripts was similar to the ES6 import command, but it really isn’t. For one, it adds whatever you’ve imported directly into the global scope of the worker - no fancy modules or static dependency trees here. It can also be run at any point in the code - not just at the root level of the file, but inside a function, in response to an event… it’s tricky.

It also has an odd relationship with caching - when you importScripts() a file it is added to a special cache collection for each worker and any future loads will go directly to the cache before trying the network (AFAIK it also ignores any headers etc too). In fact, current browser implementations will never check those files again, unless the main service worker file is changed. There are lots of hacks out there involving adding file hashes to your worker file and all sorts of nonsense like that, but fortunately browsers are changing their behaviour to check both the worker JS and imported JS when updating. So we’ll reflect that, with a process that goes something like:

Download and store worker JS, along with HTTP headers
Whenever importScripts() is run, store JS and headers for each import
When updating the worker, first try the worker URL, using If-None-Match and If-Modified-Since
- If it’s changed:
  - Treat this as a new worker, ignore the old import cache entirely
- If not changed:
  - Check each import URL with the same HTTP header checks. If any have changed, treat as new worker. If not, end the update.

I’ve been storing the JS contents inside the SQLite database I’ve been using for all app data (I tried Core Data, but… no), but I’m wondering if it makes more sense to just store them on disk. Again, I’m motivated by minimising memory usage in the Notification Service Extension - if I could remove the SQLite dependency in that environment (which won’t be trying to update or anything like that, just start, fire push event, and shut down) that would be great. Right now I’m thinking I might get that extension working before anything else, as it’ll inform quite a few of the decisions I’ll make further down the line.

A development blog.

2017-06-14T00:00:00+00:00

Hello. I’m trying a new thing here, a semi-regular blog detailing the work I’m doing on a specific project. Namely, Hybrid, my attempt at implementing Service Workers inside an iOS app. Normally we write up all our Lab projects on Medium, but waiting until I’m finished before detailing everything isn’t going to work here - there’s just too much going on.

It’s for me more than it is for you - I’ve been reading through my old code and struggling to remember why I made some of the decisions I did. The usual answer to that is “write more comments in your code”, and that’s fair, but it doesn’t capture the overall thinking that you’re doing about a project while you write it. But hopefully this will also be a way for people to discover more about this project as I chug along with it. Updates will be sporadic, as this isn’t the main project I’m working on at the lab right now, but whenever I have some free time I’ll be piecing it together.

What’s the current status of the project?

Messy. It started off as a hacky experiment and sort of ballooned out from there, so the code is awful. But it is live in the App Store as the Guardian Mobile Innovation Lab app, and it does indeed download, register and load Service Workers (using JavascriptCore) and allow you to do things like post messages from the (WK)Webview your content is in, and even receive notifications. But like I said, it’s an utter mess. So I’m rebooting it. That doesn’t mean I’m rewriting all the code from scratch, just that I’m starting a new project, then copy and pasting in various bits and pieces as I need. I’ve got a few aims with this reboot:

Organised code. Hybrid was also my first decently-sized Swift/iOS project, so I wasn’t too clued in on the best ways to structure a project. Right now, all the code sits inside one project, and I intend to change that. Partially for my own sanity, but also so that specific portions of the code, like the Service Worker implementation (separate from any UI-facing webview stuff) could possibly be separated out and embedded into an existing app at some point.
Tests. I started with the best of intentions, and created a test suite. But then deadlines appeared and I rushed, and now half of them don’t even pass, to say nothing of the vast amounts of code that have no tests at all. That came back to bite me when we did use the app to experiment with live video notifications, as it turned out the published version of the app didn’t let me update a cached worker. I don’t want to do that again.
Use new functionality in iOS11. One of the hackiest parts of the current project is how it actually serves content. In order to implement the Cache API and the fetch event, it actually creates a new local web server for every domain, and points the web view to it. That’s wasteful, and also has enough security implications to worry me deeply. iOS11 introduces the ability to register a protocol with WKWebView and manually provide data in response to requests, which will be much, much cleaner.
Make a ServiceWorker implementation that’s as tiny as possible. One difference between iOS and the web APIs that I’m going to struggle to solve is that the contents of an iOS notification are decided by the server and presented immediately, wheras on the web you use the Push API to send data, then construct the notification inside the worker. iOS 10 introduced Notification Service Extensions, which allow you to intercept the notification before it’s shown and alter the content. But, they have very, very tight memory requirements. Right now, just trying to spin up a worker is enough to cause it to hit the memory limit and terminate the process. But the Service Worker implementation uses third party frameworks like PromiseKit and FMDB, and I’m hoping that if I can strip all that out, it might be lean enough to execute in. It probably won’t be, but a small worker implementation also lends itself to having something that other apps can embed, so it’ll still be worth it.

Anyway, stay tuned.