Seven lesser-known web features that you can implement into a progressive web app (PWA) 🤳. https://fireship.io/lessons/pwa-top-features/

🙏 Special thanks to François Beaufort, check out his awesome work here https://web.dev/authors/beaufortfrancois/

PWA Features https://web.dev
Source Code https://github.com/fireship-io/7-pwa-features-demo

#webdev #pwa #javascript

00:00 Intro
00:34 App Shortcuts 
01:16 Contact Picker 
02:32 Geolocation & Device Motion 
03:39 External Devices 
05:06 Idle Detection 
06:14 File System 
07:46 Web Share 
09:10 PWA Limitations 

Install the quiz app 🤓

iOS https://itunes.apple.com/us/app/fireship/id1462592372?mt=8
Android https://play.google.com/store/apps/details?id=io.fireship.quizapp

Upgrade to Fireship PRO at https://fireship.io/pro
Use code lORhwXd2 for 25% off your first payment. 

My VS Code Theme

- Atom One Dark 
- vscode-icons
- Fira Code Font
2024-02-04T06:00:08.068Z
nova-2
2-general-nova
2024-01-09.29447
30089e05-99d1-4376-b32e-c263170674af
bba4cecb-f33d-4698-a0ec-948f0e4fa339
71eb48e5f38245d4c74ceeffbd9e37dc66da68cc52537ef37529bee08a4f11ad
67875a7f-c9c4-48a0-aa55-5bdb8a91c34a
deprecated
By simply adding a service worker, manifest, and some logos to your code base, you can turn your website into an installable progressive web app.
But the fun doesn't stop there.
In today's video, you'll learn about 7 awesome features on the web that you didn't know existed, like app shortcuts, physical device connections, file system access, and many others.
And make sure to stay tuned until the end of the video where we talk about the things the web can't do yet.
If you're new here, like and subscribe.
And if you've never heard of a progressive web app before, check out PWAs in 100 seconds.
And to follow along with this video step by step, pull up the full article on FireShip IO.
Just like native apps, PWAs can be installed on a mobile device.
That puts an app icon on the screen, but what you may not know is you can also add shortcuts to this icon.
Every progressive web app has a manifest dot JSON file, which contains metadata about the app itself, like the name and its icons.
Native devices use this information to install the app.
However, your end user may not wanna go directly to the home screen every time they tap the app icon.
Shortcuts provide a convenient way to get to a popular screen within your app, and they are very easy to implement, in the manifest file, add a shortcuts array, then add some data about each shortcut you want to add, like a name, what it links to, and an icon.
And that's literally all it takes to implement app shortcuts.
Now when a user installs your app, one of the first things you might wanna do is access their contacts, which could easily allow one user to invite a bunch of their friends to install your app as well, we can easily make this happen with a little bit of HTML and JavaScript.
In the HTML, we have a button that when clicked will bring up the user's contact list.
From there, we can write a little bit of JavaScript.
We need to specify exactly which attributes we want access to from the contacts and whether or not a user can select multiple contacts at one time.
And we'll also wanna check that this feature is supported by the browser.
The contacts picker API should be available in the navigator and the contacts manager object in the window.
From there, we'll write an async function called get contacts, and if the feature is supported, then we'll get the contacts by awaiting a call to navigator contacts select, along with the properties that we want to view.
This will prompt the user to grant access to their contacts, then allow them to select people from their contact list.
When finished, the promise will resolve with an array of contacts, which you can then handle accordingly in your application code.
Pretty simple stuff, but one thing to keep in mind here is that to run this code, it needs to happen over h t t p s.
That means in order to develop locally, you likely need an SSH tunnel, which is actually very easy to set up, and you can learn more about that in the full article.
When it comes to mobile apps, many features rely on the device's location and movement.
You probably already know that web apps can easily gain access to the GPS on a device using the geolocation API, because many websites already implement this feature.
As an end user, you'll be prompted to allow access to your location.
For example, calling get current position returns us with the latitude and longitude of the user's device.
But what you may not know is that you also have access 2 device sensors that give you information about acceleration and rotation.
Accessing device motion data is as easy as setting up an event listener on the device motion event.
When the user is in motion in the physical world or rotating the device, this event will fire multiple times per second.
Then we can use a callback function to make calculations with acceleration and rotation and update the UI.
Here's a quick pro tip.
If you're working with geolocation or device sensors in your progressive web app, enable the sensors panel in Chrome Dev Tools.
It allows you to simulate a position or orientation on the device without ever having to leave your desktop browser, and you can also simulate the GPS position as well.
Knowing where your user is going is great, but what if you have an app that relies on an external device like Bluetooth, USB, NFC or some other exotic protocol.
In the past, you likely had to build an iOS app and an Android app, each with its own dedicated code base.
Today, you can build a PWA that reaches everybody from a single code base while supporting external hardware connections.
To demonstrate this, let's imagine we're building a heart rate monitor to compete with the Fitbit.
If you don't have a device of your own to experiment with, download the BLE simulator app, which can broadcast a mock Bluetooth device from your phone.
Now that we have a device, we'll connect to it from our code using an async function.
The first step is to request the device we want to interact with.
This will bring up a dialogue with a list of devices that the user can connect to.
After the device is selected, we can connect to it by calling device dot gat connect.
That creates a connection between the heart rate monitor and the progressive web app, which we can then use to get the primary service that we want, which is the heart rate.
A service might emit multiple different values, but the one we're interested in here is the heart rate measurement.
From there, we can tell it to notify us anytime the data changes by calling start notifications.
And lastly, we add an event listener to characteristic value change to handle these notifications and run some application code most likely to update the UI with the current heart rate.
The data is emitted in binary in the form of a data view, which means it does take some additional processing.
That's beyond the scope of this video, but check out the full source code for additional details.
When you build a highly interactive real time app, you may need to know whether or not a user is currently interacting with the app.
The idle detection API allows you to do just that.
It tells you whether or not a user has been idle for a certain amount of time, or whether or not the device screen is locked.
This could be a useful feature if you have something like a chat app that shows whether or not a user is currently online.
When the status goes to idle, you update a cloud database like Firestore so everybody else in the chat knows that that user is offline.
In order to implement idle detection, we'll want to make sure that the idle detector is available in the browser.
If it is, the next step is to get permission from the user to track their idle status.
This will bring up a dialogue in the browser window that the user will have to agree to.
From there, we instantiate an idle detector and start it with a given threshold.
The minimum threshold is 60,000 milliseconds or 1 minute.
Now, whenever the status changes, the idle detector will emit a change event.
We can listen to the change event and then grab the user state and screen state from the idle detector.
If the user state is idle, then we might need to update our database, pause a video, or something along those lines.
That's a nice feature, but traditionally, one of the biggest limitations for web developers has been access to the file system.
If you've ever dealt with files on the web, you're probably familiar with the file input element.
Unfortunately, it's very limited and not really designed to build complex features.
Like, imagine building an IDE or video editing software that requires you to read entire directories in addition to constantly editing, saving, and reading files.
Apps like this are often packaged as desktop apps by either writing native code or wrapping a web app in Electron.
Fortunately, the new file system access API makes working with files much easier.
Although keep in mind that browser support is still fairly limited at this point, instead of relying on a file input, we can use any HTML element we want to trigger a file picker window.
Reading a file from the native system only requires 2 lines of code.
1st, we show the file picker and wait for the user to pick something.
Then second, we can call get file on the handle, which will result in a JavaScript file object.
Saving a file is just as easy.
If we have an existing file object, we can show the save file picker, create a writable object, then tell it to write that file to the location that the user chooses.
In addition to creating new files, the API can also modify existing files on the disk.
However, the user will be prompted to grant permission, and that'll place an icon in the URL bar so the user knows exactly which files they've granted permission to.
The bottom line here is that the file system access API makes it much easier to work with files on the web.
Now after you've built an awesome app using all the features I just showed you, you likely want your users to be able to share content from your app or be a share target for other native apps.
Let's start by taking a look at the web share target API.
Let's imagine you built a photo editing app, and when the user wants to share a photo, your app appears as a share target when they click the share button.
Implementing this functionality is as simple as updating the manifest dot JSON file.
It takes a share target option that contains an object with a variety of different customization options.
The action is the URL where the data will be sent when the user actually shares the content, then you can handle it accordingly in your code.
But in other cases, you may want the user to share your app content with an external native app, like maybe that same photo editing app wants to share the results with Twitter or some other social media site.
Instead of creating an old fashioned hyperlink to Twitter, we can check if the navigator has sharing capabilities, then call navigator share with a files array or URL along with a title and text describing it.
Now once your app is deployed as a PWA, you can easily share content with other apps and social media sites.
Now before we finish up, I want to point out that this is a very limited list.
There are many awesome features that were a bit too complex to add to this video.
Things like WebRTC, WebVR, WebAR, content indexing, payments, speech recognition, local font access, and many others.
I'll likely cover many of these in future videos, but if there's anything you'd like to see, let me know in the comments.
Now while it's awesome to have all these features on the web, there are still some important limitations that you should definitely be aware of.
One of the big ones is push notification support on iOS.
Developers have been complaining about this one for a long time, but at this point, you still can't send web push notifications to an iOS device.
It's so ridiculous that there's a petition on change.org for Apple to implement this feature, and I highly recommend you sign it.
That's probably the biggest limitation that sticks out, but another one is geofencing.
Geofencing allows you to define a virtual perimeter, and then trigger an event when the user steps inside or outside of that perimeter.
It's especially useful when combined with push notifications for marketing, but unfortunately, that's not a feature you can use on the web.
A couple of other missing features include screen brightness and wake lock.
So keep that in mind if you're weighing the pros and cons between PWAs and native.
I'm gonna go ahead and wrap things up there.
If you wanna learn more about progressive web consider becoming a pro member at FireShip.
Io for access to even more content.
Thanks for watching, and I will see you in the next one.

Speaker 0: By simply adding a service worker, manifest, and some logos to your code base, you can turn your website into an installable progressive web app. But the fun doesn't stop there. In today's video, you'll learn about 7 awesome features on the web that you didn't know existed, like app shortcuts, physical device connections, file system access, and many others. And make sure to stay tuned until the end of the video where we talk about the things the web can't do yet. If you're new here, like and subscribe.

And if you've never heard of a progressive web app before, check out PWAs in 100 seconds. And to follow along with this video step by step, pull up the full article on FireShip IO. Just like native apps, PWAs can be installed on a mobile device. That puts an app icon on the screen, but what you may not know is you can also add shortcuts to this icon. Every progressive web app has a manifest dot JSON file, which contains metadata about the app itself, like the name and its icons.

Native devices use this information to install the app. However, your end user may not wanna go directly to the home screen every time they tap the app icon. Shortcuts provide a convenient way to get to a popular screen within your app, and they are very easy to implement, in the manifest file, add a shortcuts array, then add some data about each shortcut you want to add, like a name, what it links to, and an icon. And that's literally all it takes to implement app shortcuts. Now when a user installs your app, one of the first things you might wanna do is access their contacts, which could easily allow one user to invite a bunch of their friends to install your app as well, we can easily make this happen with a little bit of HTML and JavaScript.

In the HTML, we have a button that when clicked will bring up the user's contact list. From there, we can write a little bit of JavaScript. We need to specify exactly which attributes we want access to from the contacts and whether or not a user can select multiple contacts at one time. And we'll also wanna check that this feature is supported by the browser. The contacts picker API should be available in the navigator and the contacts manager object in the window.

From there, we'll write an async function called get contacts, and if the feature is supported, then we'll get the contacts by awaiting a call to navigator contacts select, along with the properties that we want to view. This will prompt the user to grant access to their contacts, then allow them to select people from their contact list. When finished, the promise will resolve with an array of contacts, which you can then handle accordingly in your application code. Pretty simple stuff, but one thing to keep in mind here is that to run this code, it needs to happen over h t t p s. That means in order to develop locally, you likely need an SSH tunnel, which is actually very easy to set up, and you can learn more about that in the full article.

When it comes to mobile apps, many features rely on the device's location and movement. You probably already know that web apps can easily gain access to the GPS on a device using the geolocation API, because many websites already implement this feature. As an end user, you'll be prompted to allow access to your location. For example, calling get current position returns us with the latitude and longitude of the user's device. But what you may not know is that you also have access 2 device sensors that give you information about acceleration and rotation.

Accessing device motion data is as easy as setting up an event listener on the device motion event. When the user is in motion in the physical world or rotating the device, this event will fire multiple times per second. Then we can use a callback function to make calculations with acceleration and rotation and update the UI. Here's a quick pro tip. If you're working with geolocation or device sensors in your progressive web app, enable the sensors panel in Chrome Dev Tools.

It allows you to simulate a position or orientation on the device without ever having to leave your desktop browser, and you can also simulate the GPS position as well. Knowing where your user is going is great, but what if you have an app that relies on an external device like Bluetooth, USB, NFC or some other exotic protocol. In the past, you likely had to build an iOS app and an Android app, each with its own dedicated code base. Today, you can build a PWA that reaches everybody from a single code base while supporting external hardware connections. To demonstrate this, let's imagine we're building a heart rate monitor to compete with the Fitbit.

If you don't have a device of your own to experiment with, download the BLE simulator app, which can broadcast a mock Bluetooth device from your phone. Now that we have a device, we'll connect to it from our code using an async function. The first step is to request the device we want to interact with. This will bring up a dialogue with a list of devices that the user can connect to. After the device is selected, we can connect to it by calling device dot gat connect.

That creates a connection between the heart rate monitor and the progressive web app, which we can then use to get the primary service that we want, which is the heart rate. A service might emit multiple different values, but the one we're interested in here is the heart rate measurement. From there, we can tell it to notify us anytime the data changes by calling start notifications. And lastly, we add an event listener to characteristic value change to handle these notifications and run some application code most likely to update the UI with the current heart rate. The data is emitted in binary in the form of a data view, which means it does take some additional processing.

That's beyond the scope of this video, but check out the full source code for additional details. When you build a highly interactive real time app, you may need to know whether or not a user is currently interacting with the app. The idle detection API allows you to do just that. It tells you whether or not a user has been idle for a certain amount of time, or whether or not the device screen is locked. This could be a useful feature if you have something like a chat app that shows whether or not a user is currently online.

When the status goes to idle, you update a cloud database like Firestore so everybody else in the chat knows that that user is offline. In order to implement idle detection, we'll want to make sure that the idle detector is available in the browser. If it is, the next step is to get permission from the user to track their idle status. This will bring up a dialogue in the browser window that the user will have to agree to. From there, we instantiate an idle detector and start it with a given threshold.

The minimum threshold is 60,000 milliseconds or 1 minute. Now, whenever the status changes, the idle detector will emit a change event. We can listen to the change event and then grab the user state and screen state from the idle detector. If the user state is idle, then we might need to update our database, pause a video, or something along those lines. That's a nice feature, but traditionally, one of the biggest limitations for web developers has been access to the file system.

If you've ever dealt with files on the web, you're probably familiar with the file input element. Unfortunately, it's very limited and not really designed to build complex features. Like, imagine building an IDE or video editing software that requires you to read entire directories in addition to constantly editing, saving, and reading files. Apps like this are often packaged as desktop apps by either writing native code or wrapping a web app in Electron. Fortunately, the new file system access API makes working with files much easier.

Although keep in mind that browser support is still fairly limited at this point, instead of relying on a file input, we can use any HTML element we want to trigger a file picker window. Reading a file from the native system only requires 2 lines of code. 1st, we show the file picker and wait for the user to pick something. Then second, we can call get file on the handle, which will result in a JavaScript file object. Saving a file is just as easy.

If we have an existing file object, we can show the save file picker, create a writable object, then tell it to write that file to the location that the user chooses. In addition to creating new files, the API can also modify existing files on the disk. However, the user will be prompted to grant permission, and that'll place an icon in the URL bar so the user knows exactly which files they've granted permission to. The bottom line here is that the file system access API makes it much easier to work with files on the web. Now after you've built an awesome app using all the features I just showed you, you likely want your users to be able to share content from your app or be a share target for other native apps.

Let's start by taking a look at the web share target API. Let's imagine you built a photo editing app, and when the user wants to share a photo, your app appears as a share target when they click the share button. Implementing this functionality is as simple as updating the manifest dot JSON file. It takes a share target option that contains an object with a variety of different customization options. The action is the URL where the data will be sent when the user actually shares the content, then you can handle it accordingly in your code.

But in other cases, you may want the user to share your app content with an external native app, like maybe that same photo editing app wants to share the results with Twitter or some other social media site. Instead of creating an old fashioned hyperlink to Twitter, we can check if the navigator has sharing capabilities, then call navigator share with a files array or URL along with a title and text describing it. Now once your app is deployed as a PWA, you can easily share content with other apps and social media sites. Now before we finish up, I want to point out that this is a very limited list. There are many awesome features that were a bit too complex to add to this video.

Things like WebRTC, WebVR, WebAR, content indexing, payments, speech recognition, local font access, and many others. I'll likely cover many of these in future videos, but if there's anything you'd like to see, let me know in the comments. Now while it's awesome to have all these features on the web, there are still some important limitations that you should definitely be aware of. One of the big ones is push notification support on iOS. Developers have been complaining about this one for a long time, but at this point, you still can't send web push notifications to an iOS device.

It's so ridiculous that there's a petition on change.org for Apple to implement this feature, and I highly recommend you sign it. That's probably the biggest limitation that sticks out, but another one is geofencing. Geofencing allows you to define a virtual perimeter, and then trigger an event when the user steps inside or outside of that perimeter. It's especially useful when combined with push notifications for marketing, but unfortunately, that's not a feature you can use on the web. A couple of other missing features include screen brightness and wake lock.

So keep that in mind if you're weighing the pros and cons between PWAs and native. I'm gonna go ahead and wrap things up there. If you wanna learn more about progressive web consider becoming a pro member at FireShip. Io for access to even more content. Thanks for watching, and I will see you in the next one.
By simply adding a service worker, manifest, and some logos to your code base, you can turn your website into an installable progressive web app. But the fun doesn't stop there. In today's video, you'll learn about 7 awesome features on the web that you didn't know existed, like app shortcuts, physical device connections, file system access, and many others. And make sure to stay tuned until the end of the video where we talk about the things the web can't do yet. If you're new here, like and subscribe. And if you've never heard of a progressive web app before, check out PWAs in 100 seconds. And to follow along with this video step by step, pull up the full article on FireShip IO.
youtube
social media
multimedia
video gaming
streaming
media
entertainment
websites
software
Just like native apps, PWAs can be installed on a mobile device. That puts an app icon on the screen, but what you may not know is you can also add shortcuts to this icon. Every progressive web app has a manifest dot JSON file, which contains metadata about the app itself, like the name and its icons. Native devices use this information to install the app. However, your end user may not wanna go directly to the home screen every time they tap the app icon. Shortcuts provide a convenient way to get to a popular screen within your app, and they are very easy to implement, in the manifest file, add a shortcuts array, then add some data about each shortcut you want to add, like a name, what it links to, and an icon. And that's literally all it takes to implement app shortcuts. Now when a user installs your app, one of the first things you might wanna do is access their contacts, which could easily allow one user to invite a bunch of their friends to install your app as well, we can easily make this happen with a little bit of HTML and JavaScript. In the HTML, we have a button that when clicked will bring up the user's contact list. From there, we can write a little bit of JavaScript. We need to specify exactly which attributes we want access to from the contacts and whether or not a user can select multiple contacts at one time. And we'll also wanna check that this feature is supported by the browser. The contacts picker API should be available in the navigator and the contacts manager object in the window. From there, we'll write an async function called get contacts, and if the feature is supported, then we'll get the contacts by awaiting a call to navigator contacts select, along with the properties that we want to view. This will prompt the user to grant access to their contacts, then allow them to select people from their contact list. When finished, the promise will resolve with an array of contacts, which you can then handle accordingly in your application code. Pretty simple stuff, but one thing to keep in mind here is that to run this code, it needs to happen over h t t p s.
That means in order to develop locally, you likely need an SSH tunnel, which is actually very easy to set up, and you can learn more about that in the full article. When it comes to mobile apps, many features rely on the device's location and movement. You probably already know that web apps can easily gain access to the GPS on a device using the geolocation API, because many websites already implement this feature.
networking
As an end user, you'll be prompted to allow access to your location. For example, calling get current position returns us with the latitude and longitude of the user's device.
But what you may not know is that you also have access 2 device sensors that give you information about acceleration and rotation. Accessing device motion data is as easy as setting up an event listener on the device motion event. When the user is in motion in the physical world or rotating the device, this event will fire multiple times per second. Then we can use a callback function to make calculations with acceleration and rotation and update the UI. Here's a quick pro tip. If you're working with geolocation or device sensors in your progressive web app, enable the sensors panel in Chrome Dev Tools. It allows you to simulate a position or orientation on the device without ever having to leave your desktop browser, and you can also simulate the GPS position as well.
robotics
Knowing where your user is going is great, but what if you have an app that relies on an external device like Bluetooth, USB, NFC or some other exotic protocol. In the past, you likely had to build an iOS app and an Android app, each with its own dedicated code base. Today, you can build a PWA that reaches everybody from a single code base while supporting external hardware connections. To demonstrate this, let's imagine we're building a heart rate monitor to compete with the Fitbit. If you don't have a device of your own to experiment with, download the BLE simulator app, which can broadcast a mock Bluetooth device from your phone.
Now that we have a device, we'll connect to it from our code using an async function. The first step is to request the device we want to interact with. This will bring up a dialogue with a list of devices that the user can connect to. After the device is selected, we can connect to it by calling device dot gat connect. That creates a connection between the heart rate monitor and the progressive web app, which we can then use to get the primary service that we want, which is the heart rate. A service might emit multiple different values, but the one we're interested in here is the heart rate measurement. From there, we can tell it to notify us anytime the data changes by calling start notifications. And lastly, we add an event listener to characteristic value change to handle these notifications and run some application code most likely to update the UI with the current heart rate. The data is emitted in binary in the form of a data view, which means it does take some additional processing. That's beyond the scope of this video, but check out the full source code for additional details. When you build a highly interactive real time app, you may need to know whether or not a user is currently interacting with the app.
measurement
phones
visualization
telecommunications
data
multimedia
programming
networking
electronics
streaming
The idle detection API allows you to do just that. It tells you whether or not a user has been idle for a certain amount of time, or whether or not the device screen is locked.
This could be a useful feature if you have something like a chat app that shows whether or not a user is currently online. When the status goes to idle, you update a cloud database like Firestore so everybody else in the chat knows that that user is offline. In order to implement idle detection, we'll want to make sure that the idle detector is available in the browser.
internet
If it is, the next step is to get permission from the user to track their idle status. This will bring up a dialogue in the browser window that the user will have to agree to. From there, we instantiate an idle detector and start it with a given threshold. The minimum threshold is 60,000 milliseconds or 1 minute. Now, whenever the status changes, the idle detector will emit a change event. We can listen to the change event and then grab the user state and screen state from the idle detector. If the user state is idle, then we might need to update our database, pause a video, or something along those lines. That's a nice feature, but traditionally, one of the biggest limitations for web developers has been access to the file system. If you've ever dealt with files on the web, you're probably familiar with the file input element. Unfortunately, it's very limited and not really designed to build complex features.
Like, imagine building an IDE or video editing software that requires you to read entire directories in addition to constantly editing, saving, and reading files. Apps like this are often packaged as desktop apps by either writing native code or wrapping a web app in Electron. Fortunately, the new file system access API makes working with files much easier.
software
software development
Although keep in mind that browser support is still fairly limited at this point, instead of relying on a file input, we can use any HTML element we want to trigger a file picker window.
Reading a file from the native system only requires 2 lines of code. 1st, we show the file picker and wait for the user to pick something. Then second, we can call get file on the handle, which will result in a JavaScript file object. Saving a file is just as easy.
programming
If we have an existing file object, we can show the save file picker, create a writable object, then tell it to write that file to the location that the user chooses. In addition to creating new files, the API can also modify existing files on the disk. However, the user will be prompted to grant permission, and that'll place an icon in the URL bar so the user knows exactly which files they've granted permission to. The bottom line here is that the file system access API makes it much easier to work with files on the web. Now after you've built an awesome app using all the features I just showed you, you likely want your users to be able to share content from your app or be a share target for other native apps. Let's start by taking a look at the web share target API. Let's imagine you built a photo editing app, and when the user wants to share a photo, your app appears as a share target when they click the share button. Implementing this functionality is as simple as updating the manifest dot JSON file. It takes a share target option that contains an object with a variety of different customization options. The action is the URL where the data will be sent when the user actually shares the content, then you can handle it accordingly in your code. But in other cases, you may want the user to share your app content with an external native app, like maybe that same photo editing app wants to share the results with Twitter or some other social media site.
Instead of creating an old fashioned hyperlink to Twitter, we can check if the navigator has sharing capabilities, then call navigator share with a files array or URL along with a title and text describing it. Now once your app is deployed as a PWA, you can easily share content with other apps and social media sites. Now before we finish up, I want to point out that this is a very limited list. There are many awesome features that were a bit too complex to add to this video. Things like WebRTC, WebVR, WebAR, content indexing, payments, speech recognition, local font access, and many others. I'll likely cover many of these in future videos, but if there's anything you'd like to see, let me know in the comments. Now while it's awesome to have all these features on the web, there are still some important limitations that you should definitely be aware of. One of the big ones is push notification support on iOS.
twitter
multimedia
video gaming
youtube
streaming
television
social media
media
Developers have been complaining about this one for a long time, but at this point, you still can't send web push notifications to an iOS device. It's so ridiculous that there's a petition on change.org for Apple to implement this feature, and I highly recommend you sign it. That's probably the biggest limitation that sticks out, but another one is geofencing. Geofencing allows you to define a virtual perimeter, and then trigger an event when the user steps inside or outside of that perimeter. It's especially useful when combined with push notifications for marketing, but unfortunately, that's not a feature you can use on the web. A couple of other missing features include screen brightness and wake lock. So keep that in mind if you're weighing the pros and cons between PWAs and native.
I'm gonna go ahead and wrap things up there. If you wanna learn more about progressive web consider becoming a pro member at FireShip. Io for access to even more content. Thanks for watching, and I will see you in the next one.
blogging
websites
internet
By simply adding a service worker, manifest, and some logos to your code base, you can turn your website into an installable progressive web app. But the fun doesn't stop there. In today's video, you'll learn about 7 awesome features on the web that you didn't know existed, like app shortcuts, physical device connections, file system access, and many others. And make sure to stay tuned until the end of the video where we talk about the things the web can't do yet. If you're new here, like and subscribe. And if you've never heard of a progressive web app before, check out PWAs in 100 seconds. And to follow along with this video step by step, pull up the full article on FireShip IO. Just like native apps, PWAs can be installed on a mobile device. That puts an app icon on the screen, but what you may not know is you can also add shortcuts to this icon. Every progressive web app has a manifest dot JSON file, which contains metadata about the app itself, like the name and its icons. Native devices use this information to install the app. However, your end user may not wanna go directly to the home screen every time they tap the app icon. Shortcuts provide a convenient way to get to a popular screen within your app, and they are very easy to implement, in the manifest file, add a shortcuts array, then add some data about each shortcut you want to add, like a name, what it links to, and an icon. And that's literally all it takes to implement app shortcuts. Now when a user installs your app, one of the first things you might wanna do is access their contacts, which could easily allow one user to invite a bunch of their friends to install your app as well, we can easily make this happen with a little bit of HTML and JavaScript. In the HTML, we have a button that when clicked will bring up the user's contact list. From there, we can write a little bit of JavaScript. We need to specify exactly which attributes we want access to from the contacts and whether or not a user can select multiple contacts at one time. And we'll also wanna check that this feature is supported by the browser. The contacts picker API should be available in the navigator and the contacts manager object in the window. From there, we'll write an async function called get contacts, and if the feature is supported, then we'll get the contacts by awaiting a call to navigator contacts select, along with the properties that we want to view. This will prompt the user to grant access to their contacts, then allow them to select people from their contact list. When finished, the promise will resolve with an array of contacts, which you can then handle accordingly in your application code. Pretty simple stuff, but one thing to keep in mind here is that to run this code, it needs to happen over h t t p s. That means in order to develop locally, you likely need an SSH tunnel, which is actually very easy to set up, and you can learn more about that in the full article. When it comes to mobile apps, many features rely on the device's location and movement. You probably already know that web apps can easily gain access to the GPS on a device using the geolocation API, because many websites already implement this feature. As an end user, you'll be prompted to allow access to your location. For example, calling get current position returns us with the latitude and longitude of the user's device. But what you may not know is that you also have access 2 device sensors that give you information about acceleration and rotation. Accessing device motion data is as easy as setting up an event listener on the device motion event. When the user is in motion in the physical world or rotating the device, this event will fire multiple times per second. Then we can use a callback function to make calculations with acceleration and rotation and update the UI. Here's a quick pro tip. If you're working with geolocation or device sensors in your progressive web app, enable the sensors panel in Chrome Dev Tools. It allows you to simulate a position or orientation on the device without ever having to leave your desktop browser, and you can also simulate the GPS position as well. Knowing where your user is going is great, but what if you have an app that relies on an external device like Bluetooth, USB, NFC or some other exotic protocol. In the past, you likely had to build an iOS app and an Android app, each with its own dedicated code base. Today, you can build a PWA that reaches everybody from a single code base while supporting external hardware connections. To demonstrate this, let's imagine we're building a heart rate monitor to compete with the Fitbit. If you don't have a device of your own to experiment with, download the BLE simulator app, which can broadcast a mock Bluetooth device from your phone. Now that we have a device, we'll connect to it from our code using an async function. The first step is to request the device we want to interact with. This will bring up a dialogue with a list of devices that the user can connect to. After the device is selected, we can connect to it by calling device dot gat connect. That creates a connection between the heart rate monitor and the progressive web app, which we can then use to get the primary service that we want, which is the heart rate. A service might emit multiple different values, but the one we're interested in here is the heart rate measurement. From there, we can tell it to notify us anytime the data changes by calling start notifications. And lastly, we add an event listener to characteristic value change to handle these notifications and run some application code most likely to update the UI with the current heart rate. The data is emitted in binary in the form of a data view, which means it does take some additional processing. That's beyond the scope of this video, but check out the full source code for additional details. When you build a highly interactive real time app, you may need to know whether or not a user is currently interacting with the app. The idle detection API allows you to do just that. It tells you whether or not a user has been idle for a certain amount of time, or whether or not the device screen is locked. This could be a useful feature if you have something like a chat app that shows whether or not a user is currently online. When the status goes to idle, you update a cloud database like Firestore so everybody else in the chat knows that that user is offline. In order to implement idle detection, we'll want to make sure that the idle detector is available in the browser. If it is, the next step is to get permission from the user to track their idle status. This will bring up a dialogue in the browser window that the user will have to agree to. From there, we instantiate an idle detector and start it with a given threshold. The minimum threshold is 60,000 milliseconds or 1 minute. Now, whenever the status changes, the idle detector will emit a change event. We can listen to the change event and then grab the user state and screen state from the idle detector. If the user state is idle, then we might need to update our database, pause a video, or something along those lines. That's a nice feature, but traditionally, one of the biggest limitations for web developers has been access to the file system. If you've ever dealt with files on the web, you're probably familiar with the file input element. Unfortunately, it's very limited and not really designed to build complex features. Like, imagine building an IDE or video editing software that requires you to read entire directories in addition to constantly editing, saving, and reading files. Apps like this are often packaged as desktop apps by either writing native code or wrapping a web app in Electron. Fortunately, the new file system access API makes working with files much easier. Although keep in mind that browser support is still fairly limited at this point, instead of relying on a file input, we can use any HTML element we want to trigger a file picker window. Reading a file from the native system only requires 2 lines of code. 1st, we show the file picker and wait for the user to pick something. Then second, we can call get file on the handle, which will result in a JavaScript file object. Saving a file is just as easy. If we have an existing file object, we can show the save file picker, create a writable object, then tell it to write that file to the location that the user chooses. In addition to creating new files, the API can also modify existing files on the disk. However, the user will be prompted to grant permission, and that'll place an icon in the URL bar so the user knows exactly which files they've granted permission to. The bottom line here is that the file system access API makes it much easier to work with files on the web. Now after you've built an awesome app using all the features I just showed you, you likely want your users to be able to share content from your app or be a share target for other native apps. Let's start by taking a look at the web share target API. Let's imagine you built a photo editing app, and when the user wants to share a photo, your app appears as a share target when they click the share button. Implementing this functionality is as simple as updating the manifest dot JSON file. It takes a share target option that contains an object with a variety of different customization options. The action is the URL where the data will be sent when the user actually shares the content, then you can handle it accordingly in your code. But in other cases, you may want the user to share your app content with an external native app, like maybe that same photo editing app wants to share the results with Twitter or some other social media site. Instead of creating an old fashioned hyperlink to Twitter, we can check if the navigator has sharing capabilities, then call navigator share with a files array or URL along with a title and text describing it. Now once your app is deployed as a PWA, you can easily share content with other apps and social media sites. Now before we finish up, I want to point out that this is a very limited list. There are many awesome features that were a bit too complex to add to this video. Things like WebRTC, WebVR, WebAR, content indexing, payments, speech recognition, local font access, and many others. I'll likely cover many of these in future videos, but if there's anything you'd like to see, let me know in the comments. Now while it's awesome to have all these features on the web, there are still some important limitations that you should definitely be aware of. One of the big ones is push notification support on iOS. Developers have been complaining about this one for a long time, but at this point, you still can't send web push notifications to an iOS device. It's so ridiculous that there's a petition on change.org for Apple to implement this feature, and I highly recommend you sign it. That's probably the biggest limitation that sticks out, but another one is geofencing. Geofencing allows you to define a virtual perimeter, and then trigger an event when the user steps inside or outside of that perimeter. It's especially useful when combined with push notifications for marketing, but unfortunately, that's not a feature you can use on the web. A couple of other missing features include screen brightness and wake lock. So keep that in mind if you're weighing the pros and cons between PWAs and native. I'm gonna go ahead and wrap things up there. If you wanna learn more about progressive web consider becoming a pro member at FireShip. Io for access to even more content. Thanks for watching, and I will see you in the next one.
By
by
simply
simply
adding
adding
a
a
service
service
worker,
worker
manifest,
manifest
and
and
some
some
logos
logos
to
to
your
your
code
code
base,
base
you
you
can
can
turn
turn
your
your
website
website
into
into
an
an
installable
installable
progressive
progressive
web
web
app.
app
But
but
the
the
fun
fun
doesn't
doesn't
stop
stop
there.
there
In
in
today's
today's
video,
video
you'll
you'll
learn
learn
about
about
7
7
awesome
awesome
features
features
on
on
the
the
web
web
that
that
you
you
didn't
didn't
know
know
existed,
existed
like
like
app
app
shortcuts,
shortcuts
physical
physical
device
device
connections,
connections
file
file
system
system
access,
access
and
and
many
many
others.
others
And
and
make
make
sure
sure
to
to
stay
stay
tuned
tuned
until
until
the
the
end
end
of
of
the
the
video
video
where
where
we
we
talk
talk
about
about
the
the
things
things
the
the
web
web
can't
can't
do
do
yet.
yet
If
if
you're
you're
new
new
here,
here
like
like
and
and
subscribe.
subscribe
And
and
if
if
you've
you've
never
never
heard
heard
of
of
a
a
progressive
progressive
web
web
app
app
before,
before
check
check
out
out
PWAs
pwas
in
in
100
100
seconds.
seconds
And
and
to
to
follow
follow
along
along
with
with
this
this
video
video
step
step
by
by
step,
step
pull
pull
up
up
the
the
full
full
article
article
on
on
FireShip
fireship
IO.
io
Just
just
like
like
native
native
apps,
apps
PWAs
pwas
can
can
be
be
installed
installed
on
on
a
a
mobile
mobile
device.
device
That
that
puts
puts
an
an
app
app
icon
icon
on
on
the
the
screen,
screen
but
but
what
what
you
you
may
may
not
not
know
know
is
is
you
you
can
can
also
also
add
add
shortcuts
shortcuts
to
to
this
this
icon.
icon
Every
every
progressive
progressive
web
web
app
app
has
has
a
a
manifest
manifest
dot
dot
JSON
json
file,
file
which
which
contains
contains
metadata
metadata
about
about
the
the
app
app
itself,
itself
like
like
the
the
name
name
and
and
its
its
icons.
icons
Native
native
devices
devices
use
use
this
this
information
information
to
to
install
install
the
the
app.
app
However,
however
your
your
end
end
user
user
may
may
not
not
wanna
wanna
go
go
directly
directly
to
to
the
the
home
home
screen
screen
every
every
time
time
they
they
tap
tap
the
the
app
app
icon.
icon
Shortcuts
shortcuts
provide
provide
a
a
convenient
convenient
way
way
to
to
get
get
to
to
a
a
popular
popular
screen
screen
within
within
your
your
app,
app
and
and
they
they
are
are
very
very
easy
easy
to
to
implement,
implement
in
in
the
the
manifest
manifest
file,
file
add
add
a
a
shortcuts
shortcuts
array,
array
then
then
add
add
some
some
data
data
about
about
each
each
shortcut
shortcut
you
you
want
want
to
to
add,
add
like
like
a
a
name,
name
what
what
it
it
links
links
to,
to
and
and
an
an
icon.
icon
And
and
that's
that's
literally
literally
all
all
it
it
takes
takes
to
to
implement
implement
app
app
shortcuts.
shortcuts
Now
now
when
when
a
a
user
user
installs
installs
your
your
app,
app
one
one
of
of
the
the
first
first
things
things
you
you
might
might
wanna
wanna
do
do
is
is
access
access
their
their
contacts,
contacts
which
which
could
could
easily
easily
allow
allow
one
one
user
user
to
to
invite
invite
a
a
bunch
bunch
of
of
their
their
friends
friends
to
to
install
install
your
your
app
app
as
as
well,
well
we
we
can
can
easily
easily
make
make
this
this
happen
happen
with
with
a
a
little
little
bit
bit
of
of
HTML
html
and
and
JavaScript.
javascript
In
in
the
the
HTML,
html
we
we
have
have
a
a
button
button
that
that
when
when
clicked
clicked
will
will
bring
bring
up
up
the
the
user's
user's
contact
contact
list.
list
From
from
there,
there
we
we
can
can
write
write
a
a
little
little
bit
bit
of
of
JavaScript.
javascript
We
we
need
need
to
to
specify
specify
exactly
exactly
which
which
attributes
attributes
we
we
want
want
access
access
to
to
from
from
the
the
contacts
contacts
and
and
whether
whether
or
or
not
not
a
a
user
user
can
can
select
select
multiple
multiple
contacts
contacts
at
at
one
one
time.
time
And
and
we'll
we'll
also
also
wanna
wanna
check
check
that
that
this
this
feature
feature
is
is
supported
supported
by
by
the
the
browser.
browser
The
the
contacts
contacts
picker
picker
API
api
should
should
be
be
available
available
in
in
the
the
navigator
navigator
and
and
the
the
contacts
contacts
manager
manager
object
object
in
in
the
the
window.
window
From
from
there,
there
we'll
we'll
write
write
an
an
async
async
function
function
called
called
get
get
contacts,
contacts
and
and
if
if
the
the
feature
feature
is
is
supported,
supported
then
then
we'll
we'll
get
get
the
the
contacts
contacts
by
by
awaiting
awaiting
a
a
call
call
to
to
navigator
navigator
contacts
contacts
select,
select
along
along
with
with
the
the
properties
properties
that
that
we
we
want
want
to
to
view.
view
This
this
will
will
prompt
prompt
the
the
user
user
to
to
grant
grant
access
access
to
to
their
their
contacts,
contacts
then
then
allow
allow
them
them
to
to
select
select
people
people
from
from
their
their
contact
contact
list.
list
When
when
finished,
finished
the
the
promise
promise
will
will
resolve
resolve
with
with
an
an
array
array
of
of
contacts,
contacts
which
which
you
you
can
can
then
then
handle
handle
accordingly
accordingly
in
in
your
your
application
application
code.
code
Pretty
pretty
simple
simple
stuff,
stuff
but
but
one
one
thing
thing
to
to
keep
keep
in
in
mind
mind
here
here
is
is
that
that
to
to
run
run
this
this
code,
code
it
it
needs
needs
to
to
happen
happen
over
over
h
h
t
t
t
t
p
p
s.
s
That
that
means
means
in
in
order
order
to
to
develop
develop
locally,
locally
you
you
likely
likely
need
need
an
an
SSH
ssh
tunnel,
tunnel
which
which
is
is
actually
actually
very
very
easy
easy
to
to
set
set
up,
up
and
and
you
you
can
can
learn
learn
more
more
about
about
that
that
in
in
the
the
full
full
article.
article
When
when
it
it
comes
comes
to
to
mobile
mobile
apps,
apps
many
many
features
features
rely
rely
on
on
the
the
device's
device's
location
location
and
and
movement.
movement
You
you
probably
probably
already
already
know
know
that
that
web
web
apps
apps
can
can
easily
easily
gain
gain
access
access
to
to
the
the
GPS
gps
on
on
a
a
device
device
using
using
the
the
geolocation
geolocation
API,
api
because
because
many
many
websites
websites
already
already
implement
implement
this
this
feature.
feature
As
as
an
an
end
end
user,
user
you'll
you'll
be
be
prompted
prompted
to
to
allow
allow
access
access
to
to
your
your
location.
location
For
for
example,
example
calling
calling
get
get
current
current
position
position
returns
returns
us
us
with
with
the
the
latitude
latitude
and
and
longitude
longitude
of
of
the
the
user's
user's
device.
device
But
but
what
what
you
you
may
may
not
not
know
know
is
is
that
that
you
you
also
also
have
have
access
access
2
2
device
device
sensors
sensors
that
that
give
give
you
you
information
information
about
about
acceleration
acceleration
and
and
rotation.
rotation
Accessing
accessing
device
device
motion
motion
data
data
is
is
as
as
easy
easy
as
as
setting
setting
up
up
an
an
event
event
listener
listener
on
on
the
the
device
device
motion
motion
event.
event
When
when
the
the
user
user
is
is
in
in
motion
motion
in
in
the
the
physical
physical
world
world
or
or
rotating
rotating
the
the
device,
device
this
this
event
event
will
will
fire
fire
multiple
multiple
times
times
per
per
second.
second
Then
then
we
we
can
can
use
use
a
a
callback
callback
function
function
to
to
make
make
calculations
calculations
with
with
acceleration
acceleration
and
and
rotation
rotation
and
and
update
update
the
the
UI.
ui
Here's
here's
a
a
quick
quick
pro
pro
tip.
tip
If
if
you're
you're
working
working
with
with
geolocation
geolocation
or
or
device
device
sensors
sensors
in
in
your
your
progressive
progressive
web
web
app,
app
enable
enable
the
the
sensors
sensors
panel
panel
in
in
Chrome
chrome
Dev
dev
Tools.
tools
It
it
allows
allows
you
you
to
to
simulate
simulate
a
a
position
position
or
or
orientation
orientation
on
on
the
the
device
device
without
without
ever
ever
having
having
to
to
leave
leave
your
your
desktop
desktop
browser,
browser
and
and
you
you
can
can
also
also
simulate
simulate
the
the
GPS
gps
position
position
as
as
well.
well
Knowing
knowing
where
where
your
your
user
user
is
is
going
going
is
is
great,
great
but
but
what
what
if
if
you
you
have
have
an
an
app
app
that
that
relies
relies
on
on
an
an
external
external
device
device
like
like
Bluetooth,
bluetooth
USB,
usb
NFC
nfc
or
or
some
some
other
other
exotic
exotic
protocol.
protocol
In
in
the
the
past,
past
you
you
likely
likely
had
had
to
to
build
build
an
an
iOS
ios
app
app
and
and
an
an
Android
android
app,
app
each
each
with
with
its
its
own
own
dedicated
dedicated
code
code
base.
base
Today,
today
you
you
can
can
build
build
a
a
PWA
pwa
that
that
reaches
reaches
everybody
everybody
from
from
a
a
single
single
code
code
base
base
while
while
supporting
supporting
external
external
hardware
hardware
connections.
connections
To
to
demonstrate
demonstrate
this,
this
let's
let's
imagine
imagine
we're
we're
building
building
a
a
heart
heart
rate
rate
monitor
monitor
to
to
compete
compete
with
with
the
the
Fitbit.
fitbit
If
if
you
you
don't
don't
have
have
a
a
device
device
of
of
your
your
own
own
to
to
experiment
experiment
with,
with
download
download
the
the
BLE
ble
simulator
simulator
app,
app
which
which
can
can
broadcast
broadcast
a
a
mock
mock
Bluetooth
bluetooth
device
device
from
from
your
your
phone.
phone
Now
now
that
that
we
we
have
have
a
a
device,
device
we'll
we'll
connect
connect
to
to
it
it
from
from
our
our
code
code
using
using
an
an
async
async
function.
function
The
the
first
first
step
step
is
is
to
to
request
request
the
the
device
device
we
we
want
want
to
to
interact
interact
with.
with
This
this
will
will
bring
bring
up
up
a
a
dialogue
dialogue
with
with
a
a
list
list
of
of
devices
devices
that
that
the
the
user
user
can
can
connect
connect
to.
to
After
after
the
the
device
device
is
is
selected,
selected
we
we
can
can
connect
connect
to
to
it
it
by
by
calling
calling
device
device
dot
dot
gat
gat
connect.
connect
That
that
creates
creates
a
a
connection
connection
between
between
the
the
heart
heart
rate
rate
monitor
monitor
and
and
the
the
progressive
progressive
web
web
app,
app
which
which
we
we
can
can
then
then
use
use
to
to
get
get
the
the
primary
primary
service
service
that
that
we
we
want,
want
which
which
is
is
the
the
heart
heart
rate.
rate
A
a
service
service
might
might
emit
emit
multiple
multiple
different
different
values,
values
but
but
the
the
one
one
we're
we're
interested
interested
in
in
here
here
is
is
the
the
heart
heart
rate
rate
measurement.
measurement
From
from
there,
there
we
we
can
can
tell
tell
it
it
to
to
notify
notify
us
us
anytime
anytime
the
the
data
data
changes
changes
by
by
calling
calling
start
start
notifications.
notifications
And
and
lastly,
lastly
we
we
add
add
an
an
event
event
listener
listener
to
to
characteristic
characteristic
value
value
change
change
to
to
handle
handle
these
these
notifications
notifications
and
and
run
run
some
some
application
application
code
code
most
most
likely
likely
to
to
update
update
the
the
UI
ui
with
with
the
the
current
current
heart
heart
rate.
rate
The
the
data
data
is
is
emitted
emitted
in
in
binary
binary
in
in
the
the
form
form
of
of
a
a
data
data
view,
view
which
which
means
means
it
it
does
does
take
take
some
some
additional
additional
processing.
processing
That's
that's
beyond
beyond
the
the
scope
scope
of
of
this
this
video,
video
but
but
check
check
out
out
the
the
full
full
source
source
code
code
for
for
additional
additional
details.
details
When
when
you
you
build
build
a
a
highly
highly
interactive
interactive
real
real
time
time
app,
app
you
you
may
may
need
need
to
to
know
know
whether
whether
or
or
not
not
a
a
user
user
is
is
currently
currently
interacting
interacting
with
with
the
the
app.
app
The
the
idle
idle
detection
detection
API
api
allows
allows
you
you
to
to
do
do
just
just
that.
that
It
it
tells
tells
you
you
whether
whether
or
or
not
not
a
a
user
user
has
has
been
been
idle
idle
for
for
a
a
certain
certain
amount
amount
of
of
time,
time
or
or
whether
whether
or
or
not
not
the
the
device
device
screen
screen
is
is
locked.
locked
This
this
could
could
be
be
a
a
useful
useful
feature
feature
if
if
you
you
have
have
something
something
like
like
a
a
chat
chat
app
app
that
that
shows
shows
whether
whether
or
or
not
not
a
a
user
user
is
is
currently
currently
online.
online
When
when
the
the
status
status
goes
goes
to
to
idle,
idle
you
you
update
update
a
a
cloud
cloud
database
database
like
like
Firestore
firestore
so
so
everybody
everybody
else
else
in
in
the
the
chat
chat
knows
knows
that
that
that
that
user
user
is
is
offline.
offline
In
in
order
order
to
to
implement
implement
idle
idle
detection,
detection
we'll
we'll
want
want
to
to
make
make
sure
sure
that
that
the
the
idle
idle
detector
detector
is
is
available
available
in
in
the
the
browser.
browser
If
if
it
it
is,
is
the
the
next
next
step
step
is
is
to
to
get
get
permission
permission
from
from
the
the
user
user
to
to
track
track
their
their
idle
idle
status.
status
This
this
will
will
bring
bring
up
up
a
a
dialogue
dialogue
in
in
the
the
browser
browser
window
window
that
that
the
the
user
user
will
will
have
have
to
to
agree
agree
to.
to
From
from
there,
there
we
we
instantiate
instantiate
an
an
idle
idle
detector
detector
and
and
start
start
it
it
with
with
a
a
given
given
threshold.
threshold
The
the
minimum
minimum
threshold
threshold
is
is
60,000
60,000
milliseconds
milliseconds
or
or
1
1
minute.
minute
Now,
now
whenever
whenever
the
the
status
status
changes,
changes
the
the
idle
idle
detector
detector
will
will
emit
emit
a
a
change
change
event.
event
We
we
can
can
listen
listen
to
to
the
the
change
change
event
event
and
and
then
then
grab
grab
the
the
user
user
state
state
and
and
screen
screen
state
state
from
from
the
the
idle
idle
detector.
detector
If
if
the
the
user
user
state
state
is
is
idle,
idle
then
then
we
we
might
might
need
need
to
to
update
update
our
our
database,
database
pause
pause
a
a
video,
video
or
or
something
something
along
along
those
those
lines.
lines
That's
that's
a
a
nice
nice
feature,
feature
but
but
traditionally,
traditionally
one
one
of
of
the
the
biggest
biggest
limitations
limitations
for
for
web
web
developers
developers
has
has
been
been
access
access
to
to
the
the
file
file
system.
system
If
if
you've
you've
ever
ever
dealt
dealt
with
with
files
files
on
on
the
the
web,
web
you're
you're
probably
probably
familiar
familiar
with
with
the
the
file
file
input
input
element.
element
Unfortunately,
unfortunately
it's
it's
very
very
limited
limited
and
and
not
not
really
really
designed
designed
to
to
build
build
complex
complex
features.
features
Like,
like
imagine
imagine
building
building
an
an
IDE
ide
or
or
video
video
editing
editing
software
software
that
that
requires
requires
you
you
to
to
read
read
entire
entire
directories
directories
in
in
addition
addition
to
to
constantly
constantly
editing,
editing
saving,
saving
and
and
reading
reading
files.
files
Apps
apps
like
like
this
this
are
are
often
often
packaged
packaged
as
as
desktop
desktop
apps
apps
by
by
either
either
writing
writing
native
native
code
code
or
or
wrapping
wrapping
a
a
web
web
app
app
in
in
Electron.
electron
Fortunately,
fortunately
the
the
new
new
file
file
system
system
access
access
API
api
makes
makes
working
working
with
with
files
files
much
much
easier.
easier
Although
although
keep
keep
in
in
mind
mind
that
that
browser
browser
support
support
is
is
still
still
fairly
fairly
limited
limited
at
at
this
this
point,
point
instead
instead
of
of
relying
relying
on
on
a
a
file
file
input,
input
we
we
can
can
use
use
any
any
HTML
html
element
element
we
we
want
want
to
to
trigger
trigger
a
a
file
file
picker
picker
window.
window
Reading
reading
a
a
file
file
from
from
the
the
native
native
system
system
only
only
requires
requires
2
2
lines
lines
of
of
code.
code
1st,
1st
we
we
show
show
the
the
file
file
picker
picker
and
and
wait
wait
for
for
the
the
user
user
to
to
pick
pick
something.
something
Then
then
second,
second
we
we
can
can
call
call
get
get
file
file
on
on
the
the
handle,
handle
which
which
will
will
result
result
in
in
a
a
JavaScript
javascript
file
file
object.
object
Saving
saving
a
a
file
file
is
is
just
just
as
as
easy.
easy
If
if
we
we
have
have
an
an
existing
existing
file
file
object,
object
we
we
can
can
show
show
the
the
save
save
file
file
picker,
picker
create
create
a
a
writable
writable
object,
object
then
then
tell
tell
it
it
to
to
write
write
that
that
file
file
to
to
the
the
location
location
that
that
the
the
user
user
chooses.
chooses
In
in
addition
addition
to
to
creating
creating
new
new
files,
files
the
the
API
api
can
can
also
also
modify
modify
existing
existing
files
files
on
on
the
the
disk.
disk
However,
however
the
the
user
user
will
will
be
be
prompted
prompted
to
to
grant
grant
permission,
permission
and
and
that'll
that'll
place
place
an
an
icon
icon
in
in
the
the
URL
url
bar
bar
so
so
the
the
user
user
knows
knows
exactly
exactly
which
which
files
files
they've
they've
granted
granted
permission
permission
to.
to
The
the
bottom
bottom
line
line
here
here
is
is
that
that
the
the
file
file
system
system
access
access
API
api
makes
makes
it
it
much
much
easier
easier
to
to
work
work
with
with
files
files
on
on
the
the
web.
web
Now
now
after
after
you've
you've
built
built
an
an
awesome
awesome
app
app
using
using
all
all
the
the
features
features
I
i
just
just
showed
showed
you,
you
you
you
likely
likely
want
want
your
your
users
users
to
to
be
be
able
able
to
to
share
share
content
content
from
from
your
your
app
app
or
or
be
be
a
a
share
share
target
target
for
for
other
other
native
native
apps.
apps
Let's
let's
start
start
by
by
taking
taking
a
a
look
look
at
at
the
the
web
web
share
share
target
target
API.
api
Let's
let's
imagine
imagine
you
you
built
built
a
a
photo
photo
editing
editing
app,
app
and
and
when
when
the
the
user
user
wants
wants
to
to
share
share
a
a
photo,
photo
your
your
app
app
appears
appears
as
as
a
a
share
share
target
target
when
when
they
they
click
click
the
the
share
share
button.
button
Implementing
implementing
this
this
functionality
functionality
is
is
as
as
simple
simple
as
as
updating
updating
the
the
manifest
manifest
dot
dot
JSON
json
file.
file
It
it
takes
takes
a
a
share
share
target
target
option
option
that
that
contains
contains
an
an
object
object
with
with
a
a
variety
variety
of
of
different
different
customization
customization
options.
options
The
the
action
action
is
is
the
the
URL
url
where
where
the
the
data
data
will
will
be
be
sent
sent
when
when
the
the
user
user
actually
actually
shares
shares
the
the
content,
content
then
then
you
you
can
can
handle
handle
it
it
accordingly
accordingly
in
in
your
your
code.
code
But
but
in
in
other
other
cases,
cases
you
you
may
may
want
want
the
the
user
user
to
to
share
share
your
your
app
app
content
content
with
with
an
an
external
external
native
native
app,
app
like
like
maybe
maybe
that
that
same
same
photo
photo
editing
editing
app
app
wants
wants
to
to
share
share
the
the
results
results
with
with
Twitter
twitter
or
or
some
some
other
other
social
social
media
media
site.
site
Instead
instead
of
of
creating
creating
an
an
old
old
fashioned
fashioned
hyperlink
hyperlink
to
to
Twitter,
twitter
we
we
can
can
check
check
if
if
the
the
navigator
navigator
has
has
sharing
sharing
capabilities,
capabilities
then
then
call
call
navigator
navigator
share
share
with
with
a
a
files
files
array
array
or
or
URL
url
along
along
with
with
a
a
title
title
and
and
text
text
describing
describing
it.
it
Now
now
once
once
your
your
app
app
is
is
deployed
deployed
as
as
a
a
PWA,
pwa
you
you
can
can
easily
easily
share
share
content
content
with
with
other
other
apps
apps
and
and
social
social
media
media
sites.
sites
Now
now
before
before
we
we
finish
finish
up,
up
I
i
want
want
to
to
point
point
out
out
that
that
this
this
is
is
a
a
very
very
limited
limited
list.
list
There
there
are
are
many
many
awesome
awesome
features
features
that
that
were
were
a
a
bit
bit
too
too
complex
complex
to
to
add
add
to
to
this
this
video.
video
Things
things
like
like
WebRTC,
webrtc
WebVR,
webvr
WebAR,
webar
content
content
indexing,
indexing
payments,
payments
speech
speech
recognition,
recognition
local
local
font
font
access,
access
and
and
many
many
others.
others
I'll
i'll
likely
likely
cover
cover
many
many
of
of
these
these
in
in
future
future
videos,
videos
but
but
if
if
there's
there's
anything
anything
you'd
you'd
like
like
to
to
see,
see
let
let
me
me
know
know
in
in
the
the
comments.
comments
Now
now
while
while
it's
it's
awesome
awesome
to
to
have
have
all
all
these
these
features
features
on
on
the
the
web,
web
there
there
are
are
still
still
some
some
important
important
limitations
limitations
that
that
you
you
should
should
definitely
definitely
be
be
aware
aware
of.
of
One
one
of
of
the
the
big
big
ones
ones
is
is
push
push
notification
notification
support
support
on
on
iOS.
ios
Developers
developers
have
have
been
been
complaining
complaining
about
about
this
this
one
one
for
for
a
a
long
long
time,
time
but
but
at
at
this
this
point,
point
you
you
still
still
can't
can't
send
send
web
web
push
push
notifications
notifications
to
to
an
an
iOS
ios
device.
device
It's
it's
so
so
ridiculous
ridiculous
that
that
there's
there's
a
a
petition
petition
on
on
change.org
change.org
for
for
Apple
apple
to
to
implement
implement
this
this
feature,
feature
and
and
I
i
highly
highly
recommend
recommend
you
you
sign
sign
it.
it
That's
that's
probably
probably
the
the
biggest
biggest
limitation
limitation
that
that
sticks
sticks
out,
out
but
but
another
another
one
one
is
is
geofencing.
geofencing
Geofencing
geofencing
allows
allows
you
you
to
to
define
define
a
a
virtual
virtual
perimeter,
perimeter
and
and
then
then
trigger
trigger
an
an
event
event
when
when
the
the
user
user
steps
steps
inside
inside
or
or
outside
outside
of
of
that
that
perimeter.
perimeter
It's
it's
especially
especially
useful
useful
when
when
combined
combined
with
with
push
push
notifications
notifications
for
for
marketing,
marketing
but
but
unfortunately,
unfortunately
that's
that's
not
not
a
a
feature
feature
you
you
can
can
use
use
on
on
the
the
web.
web
A
a
couple
couple
of
of
other
other
missing
missing
features
features
include
include
screen
screen
brightness
brightness
and
and
wake
wake
lock.
lock
So
so
keep
keep
that
that
in
in
mind
mind
if
if
you're
you're
weighing
weighing
the
the
pros
pros
and
and
cons
cons
between
between
PWAs
pwas
and
and
native.
native
I'm
i'm
gonna
gonna
go
go
ahead
ahead
and
and
wrap
wrap
things
things
up
up
there.
there
If
if
you
you
wanna
wanna
learn
learn
more
more
about
about
progressive
progressive
web
web
consider
consider
becoming
becoming
a
a
pro
pro
member
member
at
at
FireShip.
fireship
Io
io
for
for
access
access
to
to
even
even
more
more
content.
content
Thanks
thanks
for
for
watching,
watching
and
and
I
i
will
will
see
see
you
you
in
in
the
the
next
next
one.
one
success
The speaker explains the benefits of using a progressive web app, including app shortcuts, physical device connections, and file system access. They provide a step-by-step guide on installing the app, including adding manifest dot JSON files and installing shortcuts to the icon. Access to contacts and device motion data are also discussed, along with a tip on how to use device motion data in a PWA. The speaker emphasizes the importance of accessing contacts and setting up device motion data to access users' location. The use of GPS and device motion data in web apps is also discussed, along with the use of file input and file writing in native code to create a new file and give users permission to save them. Finally, the speaker discusses the concept of idle detection in web development, how to track active status and update a cloud database, and the use of file input elements and file sharing for sharing content. The speaker recommends becoming a pro member at Fire freight, emphasizing the limitations with web push notifications and
7 Web Features You Didn’t Know Existed
By simply adding a service worker, manifest, and some logos to your code base, you can turn your website into an installable progressive web app. But the fun doesn't stop there. In today's video, you'll learn about 7 awesome features on the web that you didn't know existed, like app shortcuts, physical device connections, file system access, and many others. And make sure to stay tuned until the end of the video where we talk about the things the web can't do yet. If you're new here, like and subscribe. And if you've never heard of a progressive web app before, check out PWAs in 100 seconds. And to follow along with this video step by step, pull up the full article on FireShip IO. Just like native apps, PWAs can be installed on a mobile device. That puts an app icon on the screen, but what you may not know is you can also add shortcuts to this icon. Every progressive web app has a manifest dot JSON file, which contains metadata about the app itself, like the name and its icons. Native devices use this information to install the app. However, your end user may not wanna go directly to the home screen every time they tap the app icon. Shortcuts provide a convenient way to get to a popular screen within your app, and they are very easy to implement, in the manifest file, add a shortcuts array, then add some data about each shortcut you want to add, like a name, what it links to, and an icon. And that's literally all it takes to implement app shortcuts. Now when a user installs your app, one of the first things you might wanna do is access their contacts, which could easily allow one user to invite a bunch of their friends to install your app as well, we can easily make this happen with a little bit of HTML and JavaScript. In the HTML, we have a button that when clicked will bring up the user's contact list. From there, we can write a little bit of JavaScript. We need to specify exactly which attributes we want access to from the contacts and whether or not a user can select multiple contacts at one time. And we'll also wanna check that this feature is supported by the browser. The contacts picker API should be available in the navigator and the contacts manager object in the window. From there, we'll write an async function called get contacts, and if the feature is supported, then we'll get the contacts by awaiting a call to navigator contacts select, along with the properties that we want to view. This will prompt the user to grant access to their contacts, then allow them to select people from their contact list. When finished, the promise will resolve with an array of contacts, which you can then handle accordingly in your application code. Pretty simple stuff, but one thing to keep in mind here is that to run this code, it needs to happen over h t t p s. That means in order to develop locally, you likely need an SSH tunnel, which is actually very easy to set up, and you can learn more about that in the full article. When it comes to mobile apps, many features rely on the device's location and movement. You probably already know that web apps can easily gain access to the GPS on a device using the geolocation API, because many websites already implement this feature. As an end user, you'll be prompted to allow access to your location. For example, calling get current position returns us with the latitude and longitude of the user's device. But what you may not know is that you also have access 2 device sensors that give you information about acceleration and rotation. Accessing device motion data is as easy as setting up an event listener on the device motion event. When the user is in motion in the physical world or rotating the device, this event will fire multiple times per second. Then we can use a callback function to make calculations with acceleration and rotation and update the UI. Here's a quick pro tip. If you're working with geolocation or device sensors in your progressive web app, enable the sensors panel in Chrome Dev Tools. It allows you to simulate a position or orientation on the device without ever having to leave your desktop browser, and you can also simulate the GPS position as well. Knowing where your user is going is great, but what if you have an app that relies on an external device like Bluetooth, USB, NFC or some other exotic protocol. In the past, you likely had to build an iOS app and an Android app, each with its own dedicated code base. Today, you can build a PWA that reaches everybody from a single code base while supporting external hardware connections. To demonstrate this, let's imagine we're building a heart rate monitor to compete with the Fitbit. If you don't have a device of your own to experiment with, download the BLE simulator app, which can broadcast a mock Bluetooth device from your phone. Now that we have a device, we'll connect to it from our code using an async function. The first step is to request the device we want to interact with. This will bring up a dialogue with a list of devices that the user can connect to. After the device is selected, we can connect to it by calling device dot gat connect. That creates a connection between the heart rate monitor and the progressive web app, which we can then use to get the primary service that we want, which is the heart rate. A service might emit multiple different values, but the one we're interested in here is the heart rate measurement. From there, we can tell it to notify us anytime the data changes by calling start notifications. And lastly, we add an event listener to characteristic value change to handle these notifications and run some application code most likely to update the UI with the current heart rate. The data is emitted in binary in the form of a data view, which means it does take some additional processing. That's beyond the scope of this video, but check out the full source code for additional details. When you build a highly interactive real time app, you may need to know whether or not a user is currently interacting with the app. The idle detection API allows you to do just that. It tells you whether or not a user has been idle for a certain amount of time, or whether or not the device screen is locked. This could be a useful feature if you have something like a chat app that shows whether or not a user is currently online. When the status goes to idle, you update a cloud database like Firestore so everybody else in the chat knows that that user is offline. In order to implement idle detection, we'll want to make sure that the idle detector is available in the browser. If it is, the next step is to get permission from the user to track their idle status. This will bring up a dialogue in the browser window that the user will have to agree to. From there, we instantiate an idle detector and start it with a given threshold. The minimum threshold is 60,000 milliseconds or 1 minute. Now, whenever the status changes, the idle detector will emit a change event. We can listen to the change event and then grab the user state and screen state from the idle detector. If the user state is idle, then we might need to update our database, pause a video, or something along those lines. That's a nice feature, but traditionally, one of the biggest limitations for web developers has been access to the file system. If you've ever dealt with files on the web, you're probably familiar with the file input element. Unfortunately, it's very limited and not really designed to build complex features. Like, imagine building an IDE or video editing software that requires you to read entire directories in addition to constantly editing, saving, and reading files. Apps like this are often packaged as desktop apps by either writing native code or wrapping a web app in Electron. Fortunately, the new file system access API makes working with files much easier. Although keep in mind that browser support is still fairly limited at this point, instead of relying on a file input, we can use any HTML element we want to trigger a file picker window. Reading a file from the native system only requires 2 lines of code. 1st, we show the file picker and wait for the user to pick something. Then second, we can call get file on the handle, which will result in a JavaScript file object. Saving a file is just as easy. If we have an existing file object, we can show the save file picker, create a writable object, then tell it to write that file to the location that the user chooses. In addition to creating new files, the API can also modify existing files on the disk. However, the user will be prompted to grant permission, and that'll place an icon in the URL bar so the user knows exactly which files they've granted permission to. The bottom line here is that the file system access API makes it much easier to work with files on the web. Now after you've built an awesome app using all the features I just showed you, you likely want your users to be able to share content from your app or be a share target for other native apps. Let's start by taking a look at the web share target API. Let's imagine you built a photo editing app, and when the user wants to share a photo, your app appears as a share target when they click the share button. Implementing this functionality is as simple as updating the manifest dot JSON file. It takes a share target option that contains an object with a variety of different customization options. The action is the URL where the data will be sent when the user actually shares the content, then you can handle it accordingly in your code. But in other cases, you may want the user to share your app content with an external native app, like maybe that same photo editing app wants to share the results with Twitter or some other social media site. Instead of creating an old fashioned hyperlink to Twitter, we can check if the navigator has sharing capabilities, then call navigator share with a files array or URL along with a title and text describing it. Now once your app is deployed as a PWA, you can easily share content with other apps and social media sites. Now before we finish up, I want to point out that this is a very limited list. There are many awesome features that were a bit too complex to add to this video. Things like WebRTC, WebVR, WebAR, content indexing, payments, speech recognition, local font access, and many others. I'll likely cover many of these in future videos, but if there's anything you'd like to see, let me know in the comments. Now while it's awesome to have all these features on the web, there are still some important limitations that you should definitely be aware of. One of the big ones is push notification support on iOS. Developers have been complaining about this one for a long time, but at this point, you still can't send web push notifications to an iOS device. It's so ridiculous that there's a petition on change.org for Apple to implement this feature, and I highly recommend you sign it. That's probably the biggest limitation that sticks out, but another one is geofencing. Geofencing allows you to define a virtual perimeter, and then trigger an event when the user steps inside or outside of that perimeter. It's especially useful when combined with push notifications for marketing, but unfortunately, that's not a feature you can use on the web. A couple of other missing features include screen brightness and wake lock. So keep that in mind if you're weighing the pros and cons between PWAs and native. I'm gonna go ahead and wrap things up there. If you wanna learn more about progressive web consider becoming a pro member at FireShip. Io for access to even more content. Thanks for watching, and I will see you in the next one.
The speaker explains the benefits of using a progressive web app, including app shortcuts, physical device connections, and file system access. They provide a step-by-step guide on installing the app, including adding manifest dot JSON files and installing shortcuts to the icon. Access to contacts and device motion data are also discussed, along with a tip on how to use device motion data in a PWA. The speaker emphasizes the importance of accessing contacts and setting up device motion data to access users' location. The use of GPS and device motion data in web apps is also discussed, along with the use of file input and file writing in native code to create a new file and give users permission to save them. Finally, the speaker discusses the concept of idle detection in web development, how to track active status and update a cloud database, and the use of file input elements and file sharing for sharing content. The speaker recommends becoming a pro member at Fire freight, emphasizing the limitations with web push notifications and

        [INST]
        You are youtuber called Fireship you make engaging high-intensity and entertaining coding tutorials and tech news. 
        you covers a wide range of topics relevant to programmers, aiming to help them learn and improve their skills quickly.
        
        Given the title of the video : 7 Web Features You Didn’t Know Existed 
        and a small summary : The speaker explains the benefits of using a progressive web app, including app shortcuts, physical device connections, and file system access. They provide a step-by-step guide on installing the app, including adding manifest dot JSON files and installing shortcuts to the icon. Access to contacts and device motion data are also discussed, along with a tip on how to use device motion data in a PWA. The speaker emphasizes the importance of accessing contacts and setting up device motion data to access users' location. The use of GPS and device motion data in web apps is also discussed, along with the use of file input and file writing in native code to create a new file and give users permission to save them. Finally, the speaker discusses the concept of idle detection in web development, how to track active status and update a cloud database, and the use of file input elements and file sharing for sharing content. The speaker recommends becoming a pro member at Fire freight, emphasizing the limitations with web push notifications and
        [/INST]
        
        Generate the video : By simply adding a service worker, manifest, and some logos to your code base, you can turn your website into an installable progressive web app. But the fun doesn't stop there. In today's video, you'll learn about 7 awesome features on the web that you didn't know existed, like app shortcuts, physical device connections, file system access, and many others. And make sure to stay tuned until the end of the video where we talk about the things the web can't do yet. If you're new here, like and subscribe. And if you've never heard of a progressive web app before, check out PWAs in 100 seconds. And to follow along with this video step by step, pull up the full article on FireShip IO. Just like native apps, PWAs can be installed on a mobile device. That puts an app icon on the screen, but what you may not know is you can also add shortcuts to this icon. Every progressive web app has a manifest dot JSON file, which contains metadata about the app itself, like the name and its icons. Native devices use this information to install the app. However, your end user may not wanna go directly to the home screen every time they tap the app icon. Shortcuts provide a convenient way to get to a popular screen within your app, and they are very easy to implement, in the manifest file, add a shortcuts array, then add some data about each shortcut you want to add, like a name, what it links to, and an icon. And that's literally all it takes to implement app shortcuts. Now when a user installs your app, one of the first things you might wanna do is access their contacts, which could easily allow one user to invite a bunch of their friends to install your app as well, we can easily make this happen with a little bit of HTML and JavaScript. In the HTML, we have a button that when clicked will bring up the user's contact list. From there, we can write a little bit of JavaScript. We need to specify exactly which attributes we want access to from the contacts and whether or not a user can select multiple contacts at one time. And we'll also wanna check that this feature is supported by the browser. The contacts picker API should be available in the navigator and the contacts manager object in the window. From there, we'll write an async function called get contacts, and if the feature is supported, then we'll get the contacts by awaiting a call to navigator contacts select, along with the properties that we want to view. This will prompt the user to grant access to their contacts, then allow them to select people from their contact list. When finished, the promise will resolve with an array of contacts, which you can then handle accordingly in your application code. Pretty simple stuff, but one thing to keep in mind here is that to run this code, it needs to happen over h t t p s. That means in order to develop locally, you likely need an SSH tunnel, which is actually very easy to set up, and you can learn more about that in the full article. When it comes to mobile apps, many features rely on the device's location and movement. You probably already know that web apps can easily gain access to the GPS on a device using the geolocation API, because many websites already implement this feature. As an end user, you'll be prompted to allow access to your location. For example, calling get current position returns us with the latitude and longitude of the user's device. But what you may not know is that you also have access 2 device sensors that give you information about acceleration and rotation. Accessing device motion data is as easy as setting up an event listener on the device motion event. When the user is in motion in the physical world or rotating the device, this event will fire multiple times per second. Then we can use a callback function to make calculations with acceleration and rotation and update the UI. Here's a quick pro tip. If you're working with geolocation or device sensors in your progressive web app, enable the sensors panel in Chrome Dev Tools. It allows you to simulate a position or orientation on the device without ever having to leave your desktop browser, and you can also simulate the GPS position as well. Knowing where your user is going is great, but what if you have an app that relies on an external device like Bluetooth, USB, NFC or some other exotic protocol. In the past, you likely had to build an iOS app and an Android app, each with its own dedicated code base. Today, you can build a PWA that reaches everybody from a single code base while supporting external hardware connections. To demonstrate this, let's imagine we're building a heart rate monitor to compete with the Fitbit. If you don't have a device of your own to experiment with, download the BLE simulator app, which can broadcast a mock Bluetooth device from your phone. Now that we have a device, we'll connect to it from our code using an async function. The first step is to request the device we want to interact with. This will bring up a dialogue with a list of devices that the user can connect to. After the device is selected, we can connect to it by calling device dot gat connect. That creates a connection between the heart rate monitor and the progressive web app, which we can then use to get the primary service that we want, which is the heart rate. A service might emit multiple different values, but the one we're interested in here is the heart rate measurement. From there, we can tell it to notify us anytime the data changes by calling start notifications. And lastly, we add an event listener to characteristic value change to handle these notifications and run some application code most likely to update the UI with the current heart rate. The data is emitted in binary in the form of a data view, which means it does take some additional processing. That's beyond the scope of this video, but check out the full source code for additional details. When you build a highly interactive real time app, you may need to know whether or not a user is currently interacting with the app. The idle detection API allows you to do just that. It tells you whether or not a user has been idle for a certain amount of time, or whether or not the device screen is locked. This could be a useful feature if you have something like a chat app that shows whether or not a user is currently online. When the status goes to idle, you update a cloud database like Firestore so everybody else in the chat knows that that user is offline. In order to implement idle detection, we'll want to make sure that the idle detector is available in the browser. If it is, the next step is to get permission from the user to track their idle status. This will bring up a dialogue in the browser window that the user will have to agree to. From there, we instantiate an idle detector and start it with a given threshold. The minimum threshold is 60,000 milliseconds or 1 minute. Now, whenever the status changes, the idle detector will emit a change event. We can listen to the change event and then grab the user state and screen state from the idle detector. If the user state is idle, then we might need to update our database, pause a video, or something along those lines. That's a nice feature, but traditionally, one of the biggest limitations for web developers has been access to the file system. If you've ever dealt with files on the web, you're probably familiar with the file input element. Unfortunately, it's very limited and not really designed to build complex features. Like, imagine building an IDE or video editing software that requires you to read entire directories in addition to constantly editing, saving, and reading files. Apps like this are often packaged as desktop apps by either writing native code or wrapping a web app in Electron. Fortunately, the new file system access API makes working with files much easier. Although keep in mind that browser support is still fairly limited at this point, instead of relying on a file input, we can use any HTML element we want to trigger a file picker window. Reading a file from the native system only requires 2 lines of code. 1st, we show the file picker and wait for the user to pick something. Then second, we can call get file on the handle, which will result in a JavaScript file object. Saving a file is just as easy. If we have an existing file object, we can show the save file picker, create a writable object, then tell it to write that file to the location that the user chooses. In addition to creating new files, the API can also modify existing files on the disk. However, the user will be prompted to grant permission, and that'll place an icon in the URL bar so the user knows exactly which files they've granted permission to. The bottom line here is that the file system access API makes it much easier to work with files on the web. Now after you've built an awesome app using all the features I just showed you, you likely want your users to be able to share content from your app or be a share target for other native apps. Let's start by taking a look at the web share target API. Let's imagine you built a photo editing app, and when the user wants to share a photo, your app appears as a share target when they click the share button. Implementing this functionality is as simple as updating the manifest dot JSON file. It takes a share target option that contains an object with a variety of different customization options. The action is the URL where the data will be sent when the user actually shares the content, then you can handle it accordingly in your code. But in other cases, you may want the user to share your app content with an external native app, like maybe that same photo editing app wants to share the results with Twitter or some other social media site. Instead of creating an old fashioned hyperlink to Twitter, we can check if the navigator has sharing capabilities, then call navigator share with a files array or URL along with a title and text describing it. Now once your app is deployed as a PWA, you can easily share content with other apps and social media sites. Now before we finish up, I want to point out that this is a very limited list. There are many awesome features that were a bit too complex to add to this video. Things like WebRTC, WebVR, WebAR, content indexing, payments, speech recognition, local font access, and many others. I'll likely cover many of these in future videos, but if there's anything you'd like to see, let me know in the comments. Now while it's awesome to have all these features on the web, there are still some important limitations that you should definitely be aware of. One of the big ones is push notification support on iOS. Developers have been complaining about this one for a long time, but at this point, you still can't send web push notifications to an iOS device. It's so ridiculous that there's a petition on change.org for Apple to implement this feature, and I highly recommend you sign it. That's probably the biggest limitation that sticks out, but another one is geofencing. Geofencing allows you to define a virtual perimeter, and then trigger an event when the user steps inside or outside of that perimeter. It's especially useful when combined with push notifications for marketing, but unfortunately, that's not a feature you can use on the web. A couple of other missing features include screen brightness and wake lock. So keep that in mind if you're weighing the pros and cons between PWAs and native. I'm gonna go ahead and wrap things up there. If you wanna learn more about progressive web consider becoming a pro member at FireShip. Io for access to even more content. Thanks for watching, and I will see you in the next one.
        