mobile/lifecycle.html

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>Application Lifecycle</title>
  </head>
  <body>
    <header>
      <h1>Application Lifecycle</h1>

      <p>An important aspect of the user experience of applications is linked to how the application integrates with the rest of the system to provide a native-like experience that features a responsive user interface that is permanently available, even when offline, which is particularly important on mobile devices, installable on the user's home screen, and re-engageable (meaning that it is easy to push notifications to the user to re-engage her into the application).</p>

      <p>These notions are part of the overall <strong>application lifecycle</strong>: how applications get installed, shown to the user in applications list, started, stopped, woken up from remote notifications, synced up when the device goes on-line. They form the backbone of <strong>Progressive Web Applications</strong> (PWA).</p>
    </header>
    <main>
      <section class="featureset well-deployed">
        <h2>Well-deployed technologies</h2>

        <div data-feature="Foreground Detection">
          <p>The <a data-featureid="page-visibility">Page Visibility</a> specification lets developers detect when their application is in the foreground, and thus adapt their operations and resource consumption accordingly.</p>
        </div>
      </section>

      <section class="featureset in-progress">
        <h2>Technologies in progress</h2>
        <div data-feature="Packing">
          <p>Whether packaged or not, users rely on a variety of metadata (name, icons) to identify the apps they want to use among their list of regularly used applications. The <a data-featureid="appmanifest">Web App Manifest</a> specification lets developers group all these metadata into a single JSON file.</p>
        </div>

        <div data-feature="Offline Web Apps">
          <p>The <a data-featureid="serviceworkers">Service Workers</a> specification describes a method that enables applications to take advantage of persistent background processing, opening the door to running applications offline.</p>
          <p>Not only does Service Workers enables Web applications to work seamlessly offline or in poor network conditions, it also creates a model for Web applications to operate when they have not been opened in a browser window, or even if the browser itself is not running. That ability opens the door for Web applications that run in the background and can react to remotely triggered events.</p>
        </div>

        <div data-feature="Remote Notifications">
          <p>The <a data-featureid="push">Push API</a> enables Web applications to subscribe to remote notifications that, upon reception, wake them up. Native applications have long enjoyed the benefits of greater user engagement that these notifications bring.</p>
        </div>

        <div data-feature="Geofencing">
          <p>Through support for background operations, the <a data-featureid="geolocation-sensor">Geolocation Sensor</a> specification allows Web applications to be woken up when a device enters a specified geographical area, also known as geofencing.</p>
        </div>
      </section>

      <section class="featureset exploratory-work">
        <h2>Exploratory work</h2>

        <div data-feature="Packing">
          <p>The <a data-featureid="packaging">Web Packaging</a> document describes use cases for a new package format for web sites and applications and outlines such a format.</p>
          <p>The <a data-featureid="badging">Badging API</a> defines a more subtle notification mechanism than <a href="https://www.w3.org/TR/notifications/">Web Notifications</a>, allowing Web applications that have been installed on the device (e.g. through a manifest file) to set an application-wide badge, typically shown next to the application's icon on the home screen, to notify the user when the state of the application has changed and might require their attention (e.g. a new message has arrived).</p>
        </div>

        <div data-feature="State transition">
          <p>Applications running on mobile devices can go through different application states, from running to being idle, paused, stopped, discarded, or terminated. Transitions between these states are triggered by the underlying operating system, and hidden from web applications. The <a data-featureid="page-lifecycle">Page Lifecycle</a> proposal seeks to expose application state transitions to applications so that these applications can persist/restore state, enable/disable use of network, etc.</p>
        </div>

        <div data-feature="Sharing content">
          <p>The <em>share action</em> is a common paradigm on mobile devices to pass content across application boundaries, for instance to post a URL or an image to one's favorite social network application. The <a data-featureid="web-share">Web Share API</a> proposal allows a Web application to share text, links and other content to an arbitrary destination of the user's choice. The API is a more focused version of the <a href="https://plus.google.com/116171619992010691739">Web Intents</a> proposal, which was abandoned end of 2012, in part because its genericity triggered user experience issues.</p>
          <p>The <a data-featureid="web-share-target">Web Share Target API</a> proposal allows web applications to declare, in their application manifest, that they can receive content shared from other applications. This allows Web applications, that the user chose to install, to be listed among other native applications in share menus.</p>
        </div>

        <div data-feature="Seamless navigation">
          <p>Various sites embed content from a third party origin (e.g. news content) within their own user interface, or load third party content into an iframe to provide a faster, reliable loading experience, which is particularly crucial on mobile devices. One main drawback of this approach is that the third party's origin is not preserved: only the first party's origin appears in the address bar, which makes it difficult for users to identify the provenance and trustworthiness of the content they are browsing. Another drawback is that the third party page cannot leverage client-side resources and permissions that are attached to their origin. <a data-featureid="portals">Portals</a> is a proposal for enabling seamless navigations between sites or pages. In particular, it enables a page to show another page as an inset and perform a seamless transition between an inset state and a navigated state, thus solving the origin issues mentioned above.</p>
        </div>

        <div data-feature="Background execution">
          <p>The <a data-featureid="background-sync">Web Background Synchronization</a> specification builds on top of Service Workers to enable Web applications to keep their user data up to date seamlessly, by running network operations in the background, adjusting to possibly unreliable connections that users often experience on mobile devices.</p>

          <p><a data-featureid="background-fetch">Background Fetch</a> defines a similar service worker based download and upload mechanism in the background, but allows the background operation to continue, with user visibility, even if the user closes all windows and workers. The specification is specifically tailored to enable downloads/uploads of large assets (podcasts, movies, textures).</p>
        </div>
      </section>

      <section>
        <h2>Discontinued features</h2>

        <dl>
          <dt>Application caches</dt>
          <dd>The <a data-featureid="appcache">application cache</a> mechanism was introduced in HTML5 to enable access to Web applications offline through the definition of a manifest of files that the browser is expected to keep in its cache. The feature is well deployed but raises security issues and is extremely limited in terms of how much developers can control what gets cached when. The feature was obsoleted in HTML 5.1, and dropped from HTML 5.2, in favor of the <a href="https://www.w3.org/TR/service-workers-1/">Service Workers</a> specification, which defines a much more powerful approach.</dd>

          <dt>Task Scheduling</dt>
          <dd>The <a data-featureid="task-scheduler">Task Scheduler API</a> made it possible to trigger a task at a specified time via the service worker associated with a Web app. This specification was in scope of the now-closed System Applications Working Group and was shelved as a result.</dd>

          <dt>Geofencing API</dt>
          <dd>The <a data-featureid="geofencing">Geofencing API</a> made it possible to wake up a Web app when a device enters a specified geographical area. This work has been discontinued, partly out of struggles to find a good approach to permission needs that such an API triggers to protect users against privacy issues. Through support for background operations, the <a href="https://www.w3.org/TR/geolocation-sensor/">Geolocation Sensor</a> specification now provides similar functionalities.</dd>

          <dt>Background execution control</dt>
          <dd>User agents will restrict the ability for Web applications to run operations in the background so that users remain in control of what an application can do at all times. The <a data-featureid="budget-api">Web Budget API</a> proposed a mechanism by which applications could determine the cost and budget at their disposal to run operations in the background, allowing them to decide whether to perform or postpone these operations. Various parameters could influence the cost of an operation, including whether the device is on battery power and the type of network the device is connected to. This proposal was dropped for <a href="https://github.com/WICG/budget-api/issues/23#issuecomment-413224865">lack of adoption</a> and <a href="https://discourse.wicg.io/t/proposal-budget-api/1717/7">concerns over the design of such an API</a>.</dd>
        </dl>
      </section>
    </main>
    <script src="../js/generate.js"></script>
  </body>
</html>