Up next in 10
Progressive Web Applications are the state of art of modern web solutions. With the proper caching strategy it is possible to drastically improve the overall performance and providing data even without a network connection. In an increasingly mobile first world, optimising the time to load of web pages can be the success of our business. In this presentation, we’ll focus on how to ensure that our apps are fast, native-like and able to provide a truly seamless experience, delivering a unique experience to our users.
Conference Website: https://www.2020twenty.net/lightup
#lightup #2020twenty
Show More Show Less View Video Transcript
0:00
Can you see me? Yeah, I can see you
0:03
Yeah, and you are live at the video, OK? Then let's start
0:15
OK, so if you don't see my screen or if anything goes wrong
0:19
you don't hear anymore. Just stop interrupt me and I will take over from where I left
0:25
I will do that. OK, very, very good. So welcome everybody and tonight we will talk about the progressive web apps
0:33
and we will see this technology under different perspectives. Every time when I talk about this
0:39
topic to a conference or a meetup I usually ask the audience about their experience with this
0:47
technology and unfortunately many people don't know exactly what progressive web apps are even
0:54
even though it's not exactly a new technology, it's already out since a few years
0:59
Even less people had really experience, a practical experience with Progressive Web Apps in their own project
1:06
This is a pity because Progressive Web App has a lot of capabilities and a lot of
1:13
potentiality to offer that we can use in our web application to improve performance and to
1:19
provide a much better user experience. During this session we will see the basic concept of PWAs and how can we bring these concepts in our next projects
1:31
Let's start seeing first of all the differences between Progressive Web Apps and Native Apps
1:38
This doesn't want to be a fight nor a competition, just some concrete differences between these two very different technologies
1:47
First of all, when we implement the Progressive Web Apps, we don't have to depend on the time
1:53
schedules, and conditions of the app or the Play Store. We can just deploy to our server
1:59
our Progressive Web App and that's live immediately. Secondly, we don't have to support the multiple version
2:07
There will be just one version, the ones we have live. So it's much more simple to manage
2:13
Then the cost to implement the progressive apps are typically smaller than a native app
2:22
This is because we can reuse that they know-how that is kept by the web team to implement also progressive apps
2:31
So we don't need to have a specialized native app team of developers to create this application
2:38
Lastly, the progressive apps have typically compared to native apps, a much smaller memory footprint
2:45
And this is very good, especially if we consider a mobile device that they use them
2:52
Before going on, just a couple of words about me. My name is Francesco Lerdini
2:56
and I work as a software engineer and Angular trainer in Trivadis
3:01
It's a consulting company based in Switzerland. But I'm originally from Italy in the north
3:08
And the picture you can see is taken from my hometown. It's a very lovely place in summer
3:15
If you are interested about web technologies and PWAs, I wrote some articles on Dev.to portal
3:24
and you can follow me on Twitter where I publish or notify
3:28
when new articles are available. Let's say, let's start our PWA journey
3:34
Let's imagine we are traveling in a remote area outside of the city where the internet connection
3:40
is not so stable or is absent at all. Maybe we are reading a website with the news
3:47
so jumping from one article to the next, and this is what might happen
3:52
So if we don't have an internet connection, this is the offline page in Chrome in this case that we get
3:58
Indeed, not a very nice user experience. But thanks to Progressive Web App
4:04
we can provide a better user experience. In the left side, we can see the simplest example where we can offer our users a branded offline page where we can provide the corporate colors, the logo, and eventually some static data
4:20
Maybe some phone numbers that the users can still find useful or eventually some information about a sales campaign that our company is running
4:31
All these static information are available even offline, thanks to the Progressive Web Apps
4:36
On the right side, we have even a further example or how can we bring the user experience to a next level
4:45
And this is an example provided by Trivago. It's a company that provides information about travels and booking hotels
4:54
And if we access their website a second time and we are offline, the application provides us a labyrinth game
5:02
So this is a very interesting idea because it keeps the user's attention locked on the screen, on the game
5:12
And then as soon as the internet connection is restored, the user will be redirected to the originally requested page
5:20
So that with this functionality, Trivago is capable of retaining a potential client that otherwise, if it would be just offline, would have been lost
5:32
This is one of the potential aspects of Progressive Web Apps. Let's see now a small test
5:41
This is a screenshot of my phone. I have an Android phone where I have
5:46
installed the Twitter native app and the PWA version of Twitter. The differences are just on the shape
5:53
If we open it, we can see that also the layout is very similar
5:58
There are just a few details that differentiate one to the other
6:02
but other than that, they are exactly almost the same. I leave you just a couple of seconds
6:07
try to figure out which one is the PWA application of Twitter and which one is
6:14
the native app from Twitter. Indeed, it is not very easy. Colors are slightly different
6:20
but icons, text, and the layout is really, really similar. I give you just a little hint that will make it very easy to
6:30
find out which one is the native app and which one is the PWA
6:35
This is the size of each of the two applications installed on my phone
6:41
Of course, as you might have guessed, on the left side we have a native app
6:46
so the icon is the squared one, and on the right side we have the PWA
6:50
We can see that the memory footprint used on the mobile device is indeed much smaller compared to a native app
6:59
So looking now again to the layout, it's very hard or almost impossible to define or to
7:06
find out which one is the native app and which one is the PWA
7:09
This is indeed the goal of Progressive Web Apps. Thanks to the modern web technologies
7:15
Progressive Web Apps want to be as close as possible to a native app and provide with that a much
7:22
more native experience to our users Let see now some components that are at the core at the base of a Progressive Apps So let go a bit more in the technical settings
7:40
The core of Progressive Apps is indeed the service worker. A service worker is a component
7:46
a JavaScript component similar to a web worker, but with a specific task
7:51
being or acting as a proxy between our application and the network
7:57
So a service worker will intercept all the requests that go out from our application
8:05
and then according to the caching strategy that we might have implemented
8:10
we'll provide the response or the assets from the cache or from the web
8:15
But let's see a little animation to better understand how the service worker works on the client side
8:22
So we access with our device, our website, and in the response
8:28
we also download and install locally a service worker. That as we say, it is just a JavaScript file
8:34
Then we can eventually already cache some assets into the local cache according to
8:41
how we will implement caching strategies. We will see later what does it mean or how can this be possible
8:48
Then let's imagine we are traveling or in any case we don't have an Internet connection and we try anyway to access the website
8:58
Now the service worker intercepts our request and is capable of provide the cached data from the local cache so that the client or the application can be still rendered the data or can still be rendered and displayed even without an online
9:17
and an online reliable connection because all these requested assets are already available
9:24
online locally. Another important core component is the web manifest. The web manifest is a json file that
9:35
instructs the browser saying how our progressive web app will be displayed in the browser
9:43
It's proposing different properties. Let's start seeing the name and the short name
9:52
As it's easy to understand, it will display the name under the icon once installed on the user device
10:00
A display property that has a browser value. In that case, the Progressive Web App will be displayed in a default way
10:11
so that as we access with a mobile device, any website. We can see we still have
10:17
the URL address and all the UI elements of the browser. Much more interesting is the standalone value
10:24
where we remove some of these UI elements of the browser. There is also full-screen value that use
10:32
as the name suggests, use the full screen of the device. This value is more suited for applications that
10:40
are rich in media or games because we can use the full device tree
10:47
Start URL is also an important property because allow us to define the starting page
10:54
We don't have to forget that the progressive apps are just a web application
10:59
but we want to provide the idea and the feeling that the user is assessing a native app
11:05
Therefore, we want that the user every time clicks on the icon of our PWA
11:10
the application always opens to the same starting URL. So again, giving the feeling of a real native app
11:18
It's possible then to define a set of icons. Chrome, for example, suggested to have at least two sizes
11:25
192 and 512 pixels, and then Chrome will be in charge of
11:32
scaling according to the device resolution. Of course, if you want to provide
11:37
a much better user experience, we should provide different sizes, so different resolutions for our icons
11:47
according to the target clients that we want to address. Another important property is the purpose
11:56
We can see here, maskable, any. Purpose is a way to say how these icons should be used
12:03
Should be a maskable icon or should be any, that is the default value
12:08
meaning that that can be used for any purpose. But let's see what is maskable and that this will be useful to
12:15
understand why we should provide the maskable icons if we want to target
12:21
Android devices for our progressive web apps. From Samsung and then after Samsung
12:32
many other producers, they started deciding to have a unique common shape for
12:39
their icons that will be displayed on their phone. So that all the icons on Samsung, for example
12:47
will have these squared with a round edges icon or shape, and then pixel and the LG
12:54
a different other shape. Because of this from the version 8, so from Android Oreo
13:01
Android introduced the concept of adaptive icons. So the possibility of changing the shape of icons
13:10
on the phone by providing an extra space around the edges so that the Android then will crop
13:18
this space to provide and to give this a target or different shape as wished
13:25
This is a thought as a drawback because if we don't provide maskable icons
13:31
we will see that our icons will have either a white background or might be cropped. So not all
13:37
our icons will be present on the home screen of the device once the user installs our PWA
13:46
If we provide a maskable icon on the other side, then we don't have this white background and our
13:53
icons are not cropped. So how can we provide maskable icons? It's not so difficult. We have to
14:00
define a safe area, meaning that 40% of the width of our image is considered to be the safe area. So
14:10
everything that is contained in this 40 percent width or radius will be displayed
14:18
no matter which final shape will Android display or the user will select
14:25
Everything that is outside of the safe area might be cropped according to the shape that will be
14:30
selected. In order to create these maskable icons, there is a very useful tool. You can
14:38
access the URL in the top right, so maskable.app editor, where you can simply upload an image and by adjusting a padding
14:47
you can then export your image as a maskable icon. So by doing this you will be sure that your icons on Android devices from the version 8 or newer won be cropped in case the user selects one or another shape
15:06
Let's see now how Progressive Web Apps can benefit the performance of our web application and how can
15:14
we improve the speed of our web app. This is done thanks to caching strategies
15:22
Caching strategies are very important because a service worker doesn't know what has to be cached or which requests, which assets should be targeted
15:34
We have to define and we have to instruct the service worker accordingly
15:39
And this is done thanks to caching strategies. This is very important because since the past year, we could see that the mobile traffic constantly increased
15:50
and in 2019 even took over the traffic compared to desktop accesses
15:56
Therefore, it's even more crucial being able to optimize our web apps for mobile devices
16:01
so that our web apps will be fast even for mobile devices
16:06
so that we can provide a much better experience for our mobile users
16:14
The first caching strategy we will see is probably the simplest one
16:18
is called Cache First. Cache First is ideal whenever we want to implement an offline
16:26
strategy or an offline first approach and that provides the best performance
16:32
It works like this. When our application requests for an asset, for example, the service worker
16:39
intercepts this request and tries first to provide these assets from the cache if available. If not
16:47
then there will be a fallback to the network so there will be a normal network request but if the
16:54
values or the assets are available in the cache these will be returned immediately from the cache
17:01
therefore the response time is extremely good is extremely fast on the other side there is a network first approach or network first strategy in this
17:12
case we go first to the network because we wanted to provide the up to the most up-to-date values
17:21
for example we can think about the values of a stock exchange market or shares and therefore
17:31
we want to provide always the very up-to-date the very latest values therefore when we request these
17:38
assets or we make another big call the service worker can intercept this call and try to get to
17:46
the network but if there is a latency that we can define like a timeout so if there is a timeout of
17:53
five seconds if we define so and this timeout is exceeded then the service worker goes and provides
18:00
and tries at least to provide these calls or these responses from the cache this is also the case in
18:07
case the network is completely absent or we don't have an internet connection. In that case
18:13
the service worker will go straight to the cache and provide from that the requested assets or
18:20
resources. Of course, this is good because we can provide data even when the user is offline
18:28
but we have to be aware that if our domain or requirements are that we have to provide always
18:35
the up-to-date data, we should eventually notify the users that the data he or she is viewing
18:41
are not the live one but are coming from the cache. This is important
18:49
Another strategy is called stale while revalidate and this is a kind of a mix of the previous one
18:57
When we request for an asset, the service worker intercepts these requests and provides or attempts to provide the response from the cache
19:08
Therefore, we can benefit from a very quick and very performant answer or response because it comes from the cache
19:17
But in the background, the service worker also goes over the network and tries to fetch a newer version of the cached data so that the next request, the service worker will provide the data from the cache
19:31
But this time the data has been updated in the meantime. So we can provide a very fast response and the data gets updated much more regularly compared to the previous versions
19:44
This is the code to implement this strategy. It's not very complex
19:48
We can see that we have to go over the cache, try to see if there is a match
19:52
and if not, we go over the network. In any case, we go anyway over the network in case
20:01
we can fetch a newer version and then update the cached version with that
20:08
So it's not very complex, but there are some lines of code that we have to write
20:13
Luckily for us, there are tools that help us to abstract this complexity and let us focus on
20:21
the business logic rather than on the complexity of caching strategies. One of these tools is called Workbox
20:29
It's an open source set of libraries from Google that makes it very easy to cache assets
20:36
for example, or HTTP calls. Here in the example, we define a route and we can define a router by using a string or like in
20:48
this code snippet by providing a regular expression. Here we are targeting all JavaScript and CSS files
20:57
and we want for these requested assets, we want to provide or implement a stale while revalidate strategy
21:05
But thanks to Workbox, we can see that this is possible just with one line of code
21:11
Indeed, that is much more simple than the previous code we saw
21:17
Workbox is a framework agnostic, meaning that we can use it in any framework
21:23
We can use it in a reactor, in a vanilla JavaScript project, or even in Angular
21:28
It works with any kind of framework. There are also other kinds of tools
21:34
for example, PWA Builder from Microsoft, that allows that to easily define
21:40
some caching strategies and provide the code snippets that we can copy and use
21:47
straight in our project. So the capabilities of Workbox are a bit more complex and
21:54
advanced compared to PWA Builder, but this is also a very good tool
22:00
Of course, there are also some frameworks that provide the specific way to implement the Progressive Web Apps
22:08
Angular, for example, thanks to ng add schematic command allow us to introduce
22:15
and inject Progressive Web App capabilities in a very easy way into an existing Angular project
22:22
When we execute this command what Angular does it allows all the needed service worker modules instantiate for us register for us and create files
22:36
Like for example, the manifest file that we saw before, and the Angular service worker configuration file
22:42
where we can define all our caching strategies. This is very easy
22:47
Let's see now the first example. I will show you a demo
22:53
It's a very simple basic Angular application where I execute this command to
22:59
inject the progress web app capabilities. The demo will be available on GitHub
23:05
and this is the address. In any case, at the end, I will post on my Twitter account
23:10
the link to the slide and also to the demo, so you can get in there
23:15
see the full source code. Let's see first the code
23:26
As we say that when we executed this command, what Angular does is downloading
23:33
the service worker module for us and register the service worker file
23:38
This ngsw worker is the effective real code of Angular service worker and we should
23:46
not edited it because it comes straight from the node modules folder
23:52
Every time we execute the build, this file is rewritten or copied
24:00
Therefore, if we edit it straight, our changes will be wiped away to the next build
24:06
So we should not change it manually. The other file that has been created
24:11
we saw before, is the manifest file. We can see here there are much more file sizes
24:18
and as defaulted, this icon, PNG in different sizes is the Angular logo
24:24
So Angular makes already available for us a wide set of sizes
24:29
plus define some default settings or property values that we can, of course, change according to our needs
24:36
like the name, background color, and so on. But much more interesting is the Angular service worker file
24:43
This is the file that is generated by default. We can see we have an asset group array where we have two objects
24:52
The first one with name up and this install mode prefetch. This means that all the files that we
24:59
defined or declare here in these files array, will be downloaded by the service worker while
25:06
the service worker is installing, therefore install mode prefetch. Meaning that when the service worker will be installed
25:15
we can be sure that all these files will be already cached in the local cache
25:21
Therefore, we should define here all the files that will compose our core application or all the pages
25:30
assets, images that we want to provide as an offline page. For example, whenever the user access our web application
25:39
so that by doing like prefetch install mode, we can be sure that the service worker will have
25:45
these assets available as soon as it's installed. We can also define for install mode a value of lazy
25:54
In this case, we can see the second object. We have a name assets and here with install mode lazy
26:04
we mean we target all assets and font files that are not so
26:08
relevant, not so crucial. Therefore, with InstallMode lazy, we tell the service worker to download and store in the cache
26:16
these files only if they are requested at least once. Here, you can see UpdateMode prefetch means that we wanted
26:27
to download the newer version as soon as the service worker detects that there is a newer version
26:33
We could have also defined for the UpdateMode property, a value of lazy instead of prefetch
26:39
In that case, then the cached version of this asset file or font files
26:46
would have been downloaded only if they would have been asked a second time, so not eagerly
26:52
Therefore, we could have used lazy. So these file or these properties are created
27:01
automatically for us and with this setup, we can store static assets
27:07
But Angular allow us also to cache network request. Let's see how this is possible
27:19
We have to define a data groups array. In here, we can target
27:26
the different endpoints that we wanted to cache. We have these for the sake of the demo
27:32
I created the two endpoints. The first one where I create a cache named jokes cache
27:39
target an endpoint that provides random dead jokes. For that, we use a strategy performance
27:49
In Angular, strategy performance is the cache first. So we will go straight to the cache and provide
27:56
there a value if available. Then we can define how many entries we want to keep
28:02
in the cache and for how long, in this case, 15 minutes
28:06
but could have been one day or hours as we want. The second cache is a CATS cache
28:15
We are a fan of CATS, so I provide here as a target endpoints
28:20
two endpoints that provide random images of CATS. For that, we want the strategy freshness
28:27
Strategy freshness is network first, as we saw before. So we go first over the cache
28:34
And if there is no network connectivity, or if the network is not reliable or very slow
28:40
we can define a timeout of 5 seconds in this case. If this timeout occurs
28:47
then the service worker will provide the latest cached images from the cache
28:54
We can again here also provide how many entries in the cache we want to keep and for how long
29:02
So these are two examples are to provide a very fast response
29:07
In that case, we use a strategy performance, or if we want to provide the very latest values
29:12
in that case, we use strategy freshness. So that's it to explain or to show how easy is it to
29:22
implement the Progressive Web with Angular. Let's see now how is this application
29:29
So this is the layout. we can see that we have two cards
29:33
One that provides the joke that we use the performance caching strategy and the other one that
29:42
every time provides a cut image. Now, if we refresh it, we can see that the joke remains the same
29:52
Before it was different because it was already expired, the max life of
29:59
cache, but the cat image always changes. If we open the Chrome DevTools in this case and we see the network tab
30:10
we can see that that joke comes from the service worker. There is no network request while the cat's API goes over the network
30:21
This is exactly how we expect. Now, the interesting thing is that if I go offline and I refresh the page
30:28
we can see that I can still provide all my data. So not only the icons
30:34
but also the two cards providing data from the API. And this is because this data has been cached
30:44
And if we now look at the network tab, we can see that both API and points are provided
30:51
the responses are provided both from the service worker. so there is no traffic or no payload that goes over the network
30:59
This is a very powerful and indeed, the complexity to implement this solution already is a minimum
31:07
Let's go online again, refresh the page. Yeah. We can see that we have also an Angular ServiceWorker JSON file
31:23
This file has all in the hash table, all the ashes of the target cached assets
31:35
so that if we change anything for these assets, then the service worker can understand that
31:42
the new version is available and that he can download it. Another interesting thing to know is that if we make
31:51
a production build because the service worker need a production build. At least that is here is by default
31:58
it works only on a production environment. The production build will create a distribution folder and we can
32:07
see here are all our files that we need to deploy to the server
32:12
For our progressive web app. We can see here there is this angular service worker dot JSON file
32:20
Now, if we delete this, yes, remove it, and then I refresh the page
32:28
So I use a web server as a server. We can see that if this
32:37
Angular service worker is not downloaded anymore, my service worker will be deleted
32:45
Now we can see that is active and running, and in the cache storage section
32:50
I have all my cached assets. So let's imagine we made a mistake
32:56
we delivered a faulty version and we want to be sure that
33:00
all the caches and the service worker with the bugs from all the clients will be deleted
33:06
We can make a new deployment deleting as we saw before, deleting the service worker ng-service-worker.json file
33:15
from the distribution folder. So what this will do whenever then the user downloads again
33:23
or just simply refreshes the page and then the application attempts to download
33:34
the Angular service worker file, there will be a 404 because this file is not anymore in the package
33:42
and we can see that our cache storage is completely wiped out
33:48
So before here, we had all our assets and now this has been wiped out
33:53
And our service worker, we can see, has been deleted, as we can see here
33:58
So this is a safety measure that we can implement in order to be sure that
34:05
we wipe all the cached version on the client side, if this was a faulty or if the service worker had fault
34:13
so that we can then be sure that we can provide a newer version that is correct
34:19
So let's say this was a first demo to see how easy it's to go on
34:27
and start with the Progressive Rebabs and Angular. Really few commands that makes it possible in a matter of half an hour
34:36
to have already a running Progressive Rebabs application There is also a limitation or there are many but one of the limitation is that the service worker implements and uses the cache API
34:50
and this allows only to cache get calls. So we cannot cache any put nor post calls
34:58
Is there a way we can do it better? On one side, we might think to implement
35:03
a custom solution where we implement locally an indexed DB, Whenever the application that text that the user is offline
35:12
we'll save in this indexedb all put and post calls, so that whenever the connectivity will be restored
35:22
the application will go one by one through all the entries of this indexedb and try to execute in the proper order
35:31
This would be an option. Of course, not very complex, but this is some code that we have to implement by ourselves
35:38
Of course, manage, be careful that it will scale well and so on
35:43
But again, luckily for us, there are some tools that take over this complexity and
35:50
make us focus only on the real business logic. This tool is a Cloud Firestore
35:58
Cloud Firestore is a NoSQL database that belongs to the Firebase Platform Services
36:05
is a Google platform that provides several services and the tools that we can use for web or mobile applications
36:15
In the specific, Cloud Firestore allows in a very easy way to provide the offline storage of the documents that we access
36:26
So we can enable persistence by invoking the method called enable persistence
36:32
And that's it. We don't need to make anything else. This has to be invoked explicitly on web application
36:39
while on mobile application is turned on by default. After that, all the documents that we
36:47
request and we get to show in our application, will be made available for offline access and
36:55
stored in an index DB for us locally. There is a default threshold of 40 megabytes
37:02
and of course we can increase or reduce it as we want. While then the user is offline
37:08
it will be still possible to write, read, and query all these cached data
37:14
Then once back online, Cloud Firestore will automatically synchronize all the pending local changes with the server database
37:23
This is done completely transparently for us. So the user won't perceive at all being offline or online
37:34
Let's see now the second demo to better understand how this works and to also to see the reason of my title
37:47
So why nowadays with these modern technologies, we can provide the web application that are never offline
37:59
Let's switch to another demo. This time is always an Angular application
38:12
using Angular material and Cloud Firestore as NoSQL database with the offline storage
38:21
Here on the right side, I will mirror my phone and I will access the same application
38:29
So we can see that of course the layout is different because another very important aspect of the progressive map is the responsive design
38:38
So that if I am on a mobile device, all the cards will be displayed in a vertical way
38:44
while if I have more space available, the layout will adapt accordingly
38:49
And this is done automatically in a responsive way. Just a few words about the domain of this application
38:57
This is a personal project I implemented in order to to keep track of all nice restaurants or bars or places that I visited
39:07
so that I can then suggest to my friends or actually suggest to avoid in case they were not good enough
39:15
One thing that I can show you is that we can see here that our PWA in this case is called OPR is treated as a native app is not displayed inside the Chrome tab but is displayed in a completely separate and
39:34
independent application tab. This is done thanks to this display standalone property of the web manifest that we saw before
39:42
Again, once more to give an idea and the feeling to the users of using a native app
39:48
even though this is just a web application. of course with the progressive web capabilities
39:55
So another cool thing of Cloud Firestore is the so-called three-way binding
40:02
meaning that I can access one document, I open it and I can change here the title, for example
40:10
Here are just all the details, but are not important. Let's focus. I change the title
40:18
I add some x66 just to see it, and I save it. This change
40:24
we can see automatically, is propagated to the other client, so in this case, my phone
40:29
This is because Cloud Firestore took this change and, thanks to WebSockets, propagates it to all the listening clients
40:40
In this case, I have the phone that is listening to it
40:44
is connected to the same database, and receive immediately these changes. But let's see now something really interesting
40:53
So I switch on my airplane mode. So I simulate the case that I'm traveling and I'm offline
41:02
Even though I'm in offline mode, I can still refresh my page
41:06
my application, and I can see all the data because we have a Progressive Web App that provides data even while offline
41:13
But the interesting thing is that now I can access a document they didn't visit before
41:19
Here, for example, a pizza restaurant, very nice. I add, for example
41:24
offline just to market. I save it and I go again on the main page
41:31
We can see now that the pizzeria, restaurant entry has been updated in the title offline
41:39
But if we look on the left side, nothing changed because this change is just
41:45
local on my phone, we have to keep in mind that we are offline
41:49
so we are not connected to the network. So let me just change another file
42:01
save it, and then we can see that on my device, so on the right side
42:10
I have two changed entries, All the other files are just untouched
42:17
and these changes are not propagated on the left side. Now, when I will switch on again
42:24
so switch off the airplane mode, so I will go online again
42:28
What I would expect is that the Cloud Firestore will detect the changes that I did for these two entries
42:36
and will save them and show them on the left side. So I switch off my airplane mode
42:42
I go online again and then after some time, yeah, here, these two entries have been updated for us
42:51
So these other client got these changes from the server. The mirror changed
43:00
Yes, sorry. So this is a very cool mix of technologies that allow us indeed to
43:09
Yeah, let's go back to our application. It doesn't allow me to go back to the emulator anymore
43:27
Sorry. But in a case, important thing that I could run all the demo and you could see how
43:34
indeed it was almost impossible to see whether we were online or offline because our application simply kept working in the same way
43:43
So either we are online or offline, the application was just working
43:49
So the user doesn't have any idea of being online or offline
43:53
And all the changes that will be done while the user is offline
43:58
will be then automatically propagated to the server. So updated and pushed to the other listening clients And because of this the idea of the talk that nowadays a web application offline web application don exist anymore
44:18
Often I get the question that, OK, but then Progressive Web looks so promising
44:22
They are so great. Will they take over native apps? Well, the answer is not yet at least because
44:29
Progressive Web App can do only what web application can do. So there are still some limitations
44:38
For example, we cannot access the contact list on the device, even though Google is providing
44:47
some beta APIs called the Contact Picker API that are attempting to fill these gaps
44:55
On the other side, Apple, for example, is not supporting many of
45:00
the progressive web app functionalities. for example, web notification or some web manifest properties
45:07
Therefore, if we wanted to support or to target also Apple users
45:15
that are still a big part of the market, then we have to keep in mind that
45:19
progressive apps are not completely supported by Apple devices. Lastly, native apps have in general a better performance
45:28
because they can tie into the underlying operating system. while the Progressive Web Apps are rendered and served through browsers
45:37
But still, Progressive Web Apps can provide a lot of benefits in terms of user experience
45:45
in terms of performance. We don't have to bring all the functionalities that Progressive Web Apps offer
45:53
We don't have to bring them all as up in our web application
45:58
We can start with some and then eventually, progressively enhance more and more or provide more and more of these functionalities
46:07
Before concluding, I would like to show some resources about PWA so that you can go on
46:15
and explore more in details about this technology. The first two, PWA Rocks and the AppScope
46:23
are a sort of a gallery about existing progressive web apps that can give you an idea of what is possible and also give you inspiration of what can be achieved
46:36
with the Progressive Web Apps. Some of them are really really cool applications
46:42
pwstats.com is a website that collects all success stories of different companies from
46:49
different domains that they introduce and adopted the Progressive Web Apps. In some cases there will
46:55
be an increase of access or increase of sales but many of them share the same trends the same
47:05
benefits by introducing progressive web apps lastly the last two are more educational
47:13
one is the stack overflow progressive web app site that is a website collecting all the
47:18
or the most important, the most visited service worker questions on the Stack Overflow
47:25
And what PWA can do today is a website collecting all the capabilities
47:32
APIs and features that are possible through Progressive Web Apps. So these five examples or resources
47:41
can give you really a lot of more information and the stimulus to go on and explore
47:47
further progressive web apps that I think are really cool technology. That's it. Thank you very much for your attention
47:57
I will, as I said, I will put on my Twitter account the link for
48:02
my slides and also the GitHub repo. And you can follow me to get notified if I post a new
48:11
new articles or get straight to the dev.u portal to read what I already wrote there
48:17
Thank you very much. Of course, if you have any question, I'm open
48:24
Thank you for this. Go for today. Amazing. Thank you very much
48:30
I thank you for being the part of the cause. Thank you so much for joining. Thank you for organizing and thank you very
48:36
much for inviting me and I'm very pleased that to be here. Thank you
48:39
Thank you so much. Take care. Bye bye bye. Hi Mark, I see you on the call
#Computers & Electronics
#Programming
#Internet Software
#Mobile & Wireless
#Mobile Apps & Add-Ons
#Web Services
#File Sharing & Hosting
#Online Goodies
#Social Network Apps & Add-Ons
#Virtual Worlds