This is interesting! If anyone from WebKit is in the comments, can you provide link(s) to the bugs discussing the bytecode caching API? I'd love to take a look but my Bugzilla search skills are evidently weak.
It's a pretty fascinating feature set. You can attach images, update the content of an existing notification, attach buttons to perform custom actions, choose to make it silent or not... I think there is more utility than most implementations in the wild would suggest. One fascinating aspect of it for me is that you can do very time limited things (e.g. send election results) - users might be reluctant to download an entire app just for one evening of updates, but being able to send notification through the browser sidesteps that entirely (and more broadly, it puts a useful tool in the hands of people who can't afford native development).
That said, I agree that it's total madness that the default UI allows you to ask for permission on page load. We always had the prompt behind a button on the page and it worked great, so I think Mozilla have the right idea here.
This is a really interesting development. I've been poking around with making a cross-platform library lately, and had settled on Go because it does such a great job of building for iOS and Android simply (though the go bind tool), but the implementation feels a little messy because the nature of Go (e.g., no classes, property accessors, etc) doesn't translate easily to Objective-C or Java. So Kotlin might be a really interesting alternative here.
How about Flutter with Dart? It uses AOT so plays well with IOs. But granted, their approaches are very different as Flutter renders most things by itself.
The project I'm working on doesn't use any UI (that's still native), so I'd disregarded Flutter - but perhaps that's not fair. Looking at it, it seems to have straightforward ways to use native functionality, but I'm not 100% sure how I might go about exposing Dart classes/methods/etc to existing native code. Worth looking into, though - thanks!
I'd disagree with your assertion that it's not that much work :) Service Workers are their own self-contained JavaScript environments with complicated lifecycles after all.
That said, I've been surprised by now much is possible just using public APIs, but I'm not sure you could pull request a full OS implementation. For example, adding an app to home screen. That's going to need to wire into non-WebKit iOS and macOS code, which AFAIK is not open source. Workers also sometimes run when the browser is not active, and that wouldn't be a trivial thing to add.
Also, Apple started working on the Service Worker APIs recently. It's not clear exactly how much they'll implement, but it's a very positive step.
The main reason is that the phone will download the image each time you post a notification, and with 650 alerts throughout the night (for 650 constituencies) the user would end up downloading a lot of data with very little to show for it (since newer notifications replace the older ones).
But to add to that, it needed to be customised for different screen sizes. So we'd have to have generated a lot of versions server side.
You can't use an SVG as an image in a notification. A real shame as it would have solved all the device pixel ratio problems, but the SVG spec is absolutely huge (and includes stuff like animation) so I'm not overly surprised that Android doesn't support it.
Hmm, I'm wondering if there's a way now to render an SVG (not the full spec) within a service worker e.g. using PngPong with https://github.com/canvg/canvg
Huh! That's a really fascinating library. My gut instinct is still that it would be a heavy lift, though. Without the Canvas API in the middle you'd need to reimplement pixel by pixel drawing of different shape/curves (PngPong literally only draws squares and copies sections of other images) anti-aliasing, etc. etc.
It would be a fascinating thing to work on, but the OffscreenCanvas API is coming to Chrome[1], so I suspect it would end up being a lot of work that would be obselete after not all that much time.
> especially since the block sizes are undocumentedly little-endian, while everything else is big-endian.
Yes! That stumped me for a long time. Along the way to solving it I found this great Stack Overflow answer where the creator of ADLER32 popped in to give some advice:
Author here. The post is a combination of two separate things: creating a PNG file via JavaScript typed arrays, then using that PNG in an (Android-specific) web notification.
I added a subtitle to the Medium post, but should have considered the fact that it won't show up anywhere else. Not sure it would fit if it was appended to the end of the title here.
Glad you noticed that! It's proof of the difference a great designer (in this case, Rumsey Taylor of our News Design team) can make.
As a developer it can be quite humbling to realise how many seemingly tiny yet actually really important touches exist in a project you think you know inside out.
That's kind of the genius of puzzles like these (we can't take credit for inventing it - Spot the Ball has existed for a long time in the analog world) is that it's a mix of skill and luck, so you can fool yourself into thinking you're amazing at it, when in reality the next photo might trip you up completely.
I can relate. I mostly ended up around 55% overall per round (only slightly above average) but I did get a 100% score on one photo which made up for some spectacular fails.
