Many of you know that I am passionate about inter-app communications, specifically the action of sharing. One of the things that I have encouraged anyone who wants to do the next version of Web Intents to do is focus on a very small and specific use case.
Well Good News Everybody. Matt Giuca on the Chrome team has been working on a simple API (Web Share) that has the potential to connect websites with native apps and also and it is in Chrome Dev Channel on Android to test.
Owen Campbell-Moore, one of Chrome’s PM’s for Progressive Web Apps and new APIs asked the following question, and instantly Surma (that is the only name we know for him) said “Sockets”
@owencm Network connections. Like writing an SSH client as a PWA.
— Surma (@DasSurma) August 12, 2016
I also threw in my two pennies, and Marcos Ceres asked for use-cases.
@annevk @Paul_Kinlan @DasSurma @owencm I'd still be interested in a good list of fun things that people want to build but can't.
I wrote about screen recording from Android a little while ago and whilst it is cool, I didn’t document anything of the process that I had to get it into the device frame and make the screen recordings look all “profesh”.
The process in the past was pretty cumbersome, I would grab the screen recording using my script and then use Screenflow to overlay the video on the device frame and then do export that out to the mp4 followed by a quick bit of GIF hakery.
Entering usernames, emails, identifiers and passwords is a massive pain for users. It’s even worse on mobile as the use has to fiddle around with.
Browsers have done a number of things over the years to help with this problem. We started with enhancing autofill across browsers by making it more intelligent, more secure but more importantly synchronised across browsers (so that if you enter data on your desktop it is available instantly on your mobile).
This is a test. It might not look like much but I have integrated WebTorrent streaming in to my blog and bit torrent URLs so that I can distribute content across the web without relying on my site.
It does use the WebSeed BEP so that it always has an unchocked seed (my site). I am going to start experimenting a little more with this to see how to measure analytics etc.
Service Worker gives you control. Service Worker offers me as a developer great power and flexibility when creating sites and managing how I can make them fast and resilient to network issues.
Because of the flexibility that the Service Worker API offers in terms of control over the network there are a lot of choices that you have to make when managing and this could be daunting the first time that you start to play with the API.
TL;DR - Here is a demo Code
Our team has built a lot of Progressive Web Apps recently to demonstrate how we think they can be built: Airhorner, Voice Memos, Guitar Tuner, SVG-OMG are a few that spring to mind. One thing that is common across all of these sites is that they have no server component to store and synchronise data. We built these sites as examples and reference implementations of the types of experiences that we can deliver on the web, they were never intended to be full “Apps” that you would build as a business.
A question came up the other day in the office: “Everyone keeps saying Web Intents died because of the UX, but no one has actually said what the issues were”. I looked back over a bunch of my notes and blog posts and it’s correct, I don’t think we documented the holistic set of UX issues that we faced.
Wide array of actions and data types We never optimized for the user intent and all were treated equally: Sharing == Viewing == Picking == Editing == Any other intent, and this caused a number of issues.
Web Push is great, however if the user already has an app installed that does Push notifications the developer needs to reasonably be able to stop either the app or the web sites notification. However there is no shared ID between site and app (for obvious reasons).
There are a couple of strategies that we are experimenting with right now. One of strategy is to try and launch an app and if it is not installed use the web experience.
The URI is a handy thing, it’s kind of like a Command Line Interface. A URI lets you target a site or an app and pass it data and then see a result in some form.
Nearly everyone will know and understand that to load a web page we enter http:// or more recently (and more importantly) https://, but Apps can also be targeted directly with a custom form of the ‘https’ prefix called a custom scheme.
I was writing about Service Discovery the other day and I have some thoughts about how we can do inter-app communication on the web more effectively than what we can today.
Interactions between web and web, web and apps and apps and web is something that many of you may know that I am passionate about, but it is incredibly hard and using the intent syntax in Android is a great start but has huge problems because it is not portable.
This story starts a long time, was tickled into existing after I visited FlipKart in Bangalore and was finalized after an internal conversation about the fact that it is impossible to trigger the share dialog in Android from the web. Lots of people want it, it turns out everyone thought it wasn't possible. It is.*