'Set start_url in web app manifest based on the URL that was added to homescreen

My site has several subsections. When a user adds the site to their homescreen, I'd like to make sure that the home screen icon launches them into the subsection they were on when they added to homescreen.

I can register a different manifest for each subsection, but this doesn't work for single page apps where there's no page reload. I'm considering storing the subsection in a cookie and then redirecting from a generic start URL based on that cookie.

Is there a better way to do this?

progressive-web-appsarduinobluetooth-lowenergyarduino-esp32


Solution 1:[1]

If you remove the start_url from the manifest.json file then it will default to the page user was browsing while adding pwa app to homescreen. ref : https://developers.google.com/web/tools/lighthouse/audits/manifest-contains-start_url

Solution 2:[2]

Have you tried changing the web app manifest url when the user navigates between different subsections?

document.querySelector('link[rel=manifest]').href = '/example-manifest.json';

Solution 3:[3]

One solution is for each page do you have a separated manifest with attribute start_url specific to each page.

Editing: in the HTML for /your_path:

<link rel="manifest" href="/path/to/your_path-manifest.json">

in the HTML for other pages:

<link rel="manifest" href="/path/to/any_other_page-manifest.json">

Solution 4:[4]

Had the same problem just now. Here is my solution:

I completely removed the manifest tag from the initial HTML. Instead I now put the manifest together entirely in JS with the start_url set to window.location.href. Then I add it to the head as a Base64 data URL:

const manifest = {
  name: 'My App',
  short_name: 'My App',
  display: 'standalone',
  theme_color: '#ffffff',
  background_color: '#ffffff',
  icons: [
    { src: `${window.location.origin}/path/to/icon.png`, sizes: '192x192', type: 'image/png' },
    { src: `${window.location.origin}/path/to/icon.png`, sizes: '512x512', type: 'image/png' },
    { src: `${window.location.origin}/path/to/icon.png`, sizes: '192x192', type: 'image/png', purpose: 'maskable' },
    { src: `${window.location.origin}/path/to/icon.png`, sizes: '512x512', type: 'image/png', purpose: 'maskable' }
  ],
  start_url: window.location.href
};

const link = document.createElement('link');
link.rel = 'manifest';
link.href = `data:application/json;base64,${btoa(JSON.stringify(manifest))}`;
document.head.appendChild(link);

Seems to work on both Android and iOS.

Note: Since data URLs don't have a root you cannot specify any root-relative URLs within the manifest (e.g. for icons). But it's easy to fix by prepending with window.location.origin. Also the start_url may not be relative. E.g. using just window.location.pathname doesn't work, that's why I am using window.location.href.

Note 2: If you are using a tool to autogenerate the PWA support of your app make sure this tool doesn't generate its own manifest during the build. Usually there should be a config option to disable this. For the Vite PWA Plugin I was able to configure manifest: false.

Solution 5:[5]

It seems that only @2 is designed for ESP32 module. It's quite popular, for ESP32 it won't be a bad choice.

As a kickstart for @2, take a look at this project: BLEProof on gihtub - contains BLE Central & Peripheral for Android and ESP32, simple demo of BLE read, write and notify.

When starting a project, please choose the hardware wisely:

  • ESP32 modules are powerful but have high power consumption, minimum 60mA, they cannot sleep while advertising or keeping the active BLE connection
  • Other modules (for libraries @1 and @3), especially only-BLE-modules (without Wi-Fi), designed for lower power consumption: e.g. Nordic nRF51/nRF52 series processors consume 10-15mA when processor runs all the time, or 1-2mA when combining sleep with keeping active BLE connection

ESP32 with library @2 is a convenient way to prototype your project, but it's not an energy-efficient solution when you use only Bluetooth Low Energy. Also note that I don't have any experience with libraries @1 and @3.

Solution 6:[6]

I was having the same question. I tried @2 and it worked fine but @3 had better API so I jumped to that option. Apparently @3 does not support esp32. There is an issue for the same with a pull request link. However, when I tried it, it had compile errors. So I'm going to use @2 for my project and suggest the same to anyone looking here at least until the @3 library supports it.

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 Fawaz
Solution 2 Matt Gaunt
Solution 3
Solution 4 Ricki-BumbleDev
Solution 5 alexander.cpp
Solution 6

Related Questions