Prepared for the MiniApp Virtual Meeting 2020, July 30-31

Video hosted by Web Castor on their StreamFizz platform.

Transcript

Hello, everyone, this is Qing An from Alibaba Group.

In this presentation, I will talk about the details about the MiniApp Lifecycle Proposal.

Okay, in this slide, here I list the link of the draft proposal and this draft has been submitted to the MiniApp CG and we have many discussions on this topic.

And here I want to give a very brief introduction.

Because we know that the MiniApp is composed of two layers, the application layer and the page layer.

Therefore, the MiniApp lifecycle were contained two parts, the first is application lifecycle and the second is a page lifecycle.

So in order to Okay, in the next slide, in order to better understand the MiniApp working mechanism, we need to first get to know how the MiniApp works.

And first, here I list six working mechanisms.

And the first one is download.

It means that the first time the user opens a MiniApp, the hosted native environment, such as the hosted app or download the MiniApp package from the backend sever.

And then the downloaded package is cached locally and when the user reopens this same MiniApp, the download procedure can be skipped, which can let the user to open the MiniApp more quickly.

And the second one is the cold launch.

It means that to open a MiniApp that has never been launched locally or to open a MiniApp that has been destroyed.

So, in this cold launch the MiniApp will start from the very first step, the initialization.

And the In contrast to this is the concept of hot launch.

Hot launch, it means that to open a MiniApp that is running in the background, so it simply means that the MiniApp only switches from running in the background to be running in the foreground.

And then in the first working mechanism is a running in the foreground.

It means that when you first open a MiniApp it is in the state of running in the foreground.

And also we have the concept of running in the background.

It means that when the user closes the MiniApp or leaves the hosted native environment, the MiniApp will not be destroyed directly.

Instead, it was switched to run in the background.

And the last one is destroying.

It means that only after the MiniApp has been running in the background for a specific duration, like several minutes.

Or the MiniApp has occupied too many system resources, then the MiniApp will be destroyed and closed permanently.

So based on this Okay, in the slide four, based on this MiniApp working mechanisms we can see that first, for the MiniApp application lifecycle, it contains four events.

And the first event is initialization.

It means that when the user opens the MiniApp for the first time, the MiniApp will start the initialization procedure.

And second event is running in the foreground.

It means that the MiniApp initialization is completed or when the user reopens the same MiniApp that has been closed The third event is the running in the background.

It means that when the user closes the MiniApp or goes to the mobile phone's home screen.

Then the MiniApp is in the event of running in the background.

And the last event is error.

It notes that the MiniApp is confronted with some script error.

So accordingly, then we can have the corresponding four MiniApp application lifecycle states.

The first state is Launched, it is the lifecycle state for the MiniApp initialization.

And the MiniApp is at this application lifecycle state once the MiniApp's initialization is completed or the MiniApp is And this state is triggered only once.

The second state is the Shown.

It is a state for the MiniApp running in the foreground.

And the MiniApp is at this lifecycle state once the MiniApp initialization is completed or the MiniApp switched to be running in the foreground from the background.

And the third state is the Hide.

It is the lifecycle state for the MiniApp running in the background and the MiniApp enters this state once the MiniApp switches to be running from foreground to the background.

The last state is Error.

It is the lifecycle state for the MiniApp error.

The MiniApp is at this state once the MiniApp is confronted with script error.

So accordingly, based on the definition of the MiniApp lifecycle states.

Then in slide six, here is the proposed APIs for the MiniApp application lifecycle.

So, we can have the, first, we have the onLaunch API to monitor the callback of the MiniApp initialization.

And its object contains three parameters.

First is query.

It is inputted UI query for the current MiniApp.

And the path parameter, which is the UI page path for the current MiniApp.

And also it contains the referral information.

It means the source information for the MiniApp, including the MiniApp ID and some optional extra data.

And second it has onShow API to monitor the callback of MiniApp foreground display.

And the definition of its object is same as onLaunch.

And third it has the onHide to monitor the callback of MiniApp switching to be running in the background.

Last, it has onError to monitor the callback of MiniApp error.

So in the slide seven, here I list some simple codes.

First is based on the assumption that it is used MiniApp URI here a list in the first slide.

And then based on the URI after running this different MiniApp application lifecycle APIs, it will get it will be at different states and it can get the information.

For example, the information from the URI.

And here in the slide eight, here we come to the second part, the MiniApp page lifecycle.

Here, first, similar to the application lifecycle, here I list the five events used by the MiniApp page lifecycle.

The first event is loading.

It means the MiniApp page loading procedure.

And second is the first rendering, ready event.

It means the MiniApp page's first rendering procedure.

The third event is the running in the foreground.

It means the MiniApp page is running in the foreground.

The forth one is MiniApp page running in the background.

And the last one is the event of unloading.

It means that the MiniApp page is destroyed.

So accordingly, based on the MiniApp lifecycle events in the slide nine, it lists the five MiniApp page lifecycle states.

First is the state of the loaded.

It is lifecycle state for the MiniApp page loading.

And the MiniApp page will enter this state once the MiniApp page loading is completed.

And at this moment, the worker has obtained the initialization data, and the developers can obtain the MiniApp page path and query and this event can be monitored.

And the second state is the ready.

It is the lifecycle state for the MiniApp page first rendering.

And the MiniApp page is at this stage once the MiniApp page first rendering is completed.

At this moment, the page UI can be configured.

The third is the lifecycle state for the MiniApp page display called shown.

And the MiniApp page enters this state once the page switches to be running in the foreground from the background.

At this moment, the developers can update the data and refresh the page.

And the forth one is Hidden It is the lifecycle state for the MiniApp page running in the background.

And the MiniApp page enters this state once the page switches to be running from foreground to background.

And the last state is Unloaded.

It's the lifecycle state for the MiniApp page destroying and the MiniApp page will enter this state once the page is destroyed.

And at this moment, the registered monitoring event is destroyed too.

So, based on the MiniApp page lifecycle stage in slide ten, here is a list of the MiniApp page lifecycle APIs.

First it has the onLoad API to monitor the callback of the MiniApp page loading.

And it contains query parameter to denote the inputted query for the current MiniApp page.

And also it has onReady to monitor the callback of MiniApp page's first rendering.

It has onShow to monitor the callback of MiniApp page display.

Then it has onHide to monitor the callback of MiniApp page switching to be running in the background.

And last, it is the onUnload to monitor the callback of destroying MiniApp page.

In slide eleven I list the simple code.

It's kind of very simple and very easy to understand.

And next in the slide twelve, here is the figure illustrating the MiniApp page lifecycle, the MiniApp lifecycle.

Here we can see that when the user firstly opens a MiniApp, the RenderView and the Worker will simultaneously start the initialization.

After the Worker is initialized, The Worker will run the MiniApp application lifecycle event app.onLaunch and app.onShow to create the MiniApp instance.

Afterwards, the Worker runs MiniApp page lifecycle event page.onLoad.

Then, after this, the Worker sends the initial data to RenderView to start the first rendering.

Once the first rendering is completed, RenderView will notify Worker, then the Worker can run the MiniApp page lifecycle event page.onReady.

Afterwards, at this moment, the user can interact with the MiniApp.

The RenderView can be triggered to deliver the user event to the Worker for further processing.

Then, also the Worker will return the result data to the RenderView for the re-render of the page.

Sometimes, if the MiniApp page switches to be running in the background, The Worker will run the MiniApp page lifecycle event page.onHide to keep it alive.

If MiniApp page switches to foreground, then the Worker will run the MiniApp page lifecycle event page.onShow.

If to destroy MiniApp page, the Worker runs the MiniApp page lifecycle event page.onUnload.

This is a very simple illustration on MiniApp lifecycle.

Then, in the next slide, slide thirteen here is some consideration on the privacy and security of the MiniApp.

First, onShow and onHide event can enable the developers to know when a MiniApp is visible.

By use of onShow event, developers can choose to process and hide the sensitive data, before the MiniApp page switches to be running in the foreground.

Also, the onUnload event provides a notification that the page is being unloaded.

Next slide, slide fourteen.

Here is a comparison between some related work in W3C, and this also has been asked many times by other W3C groups.

First, here I listed some of the lifecycle states required by the MiniApp.

And in the second column I listed some of the work that is being discussed in the W3C current other groups.

and we can see that most of the states required by the MiniApp lifecycle has not been discussed or supported in the W3C.

And only the lifecycle states of the page Shown, page Hidden, and page onLoaded we found some similar things being discussed.

First is the page visibility draft.

It discusses the visible state and in the same draft, it also introduces the hidden states.

In the page lifecycle draft we find that there's discarded state, very similar to the page onLoad in the MiniApp lifecycle state.

So in this comparison, we can find that most of the lifecycle states required by the MiniApp has not been discussed or developed in the W3C.

So we can see that it is very necessary for the W3C to develop some lifecycle states that can support the requirement for the MiniApp.

Okay, here is all the content I want to share with you and looking forward to the Q&A sessions in the real-time workshop.

Thank you very much.