PWA to get Add To Homescreen functionality on phones and make zites look more like Apps

[ghost]

Just an idea, not sure how possible it is:

Also, I know that you can already add sites to your homescreen. But making it a PWA will remove the address bar, put them into seperate windows, and add a splash screen. I also think I read somewhere that they will also be put into the App Drawer in the future.

This would require Service Worker support also, I believe.

[AnthyG]

Implementing a Service-worker could also provide real offline access for zites, as the ZeroNet-client wouldn't need to run.

But it's kind of a bad thing if the Service-worker would cache all the stuff again in the browser.

And AFAIK, the PWA-function does only work in Chrome for Android.

[ghost]

Yes, only Chrome mobile works with full support, but Firefox mobile and opera mobile have partial support. Currently the Add To Homescreen function works in firefox mobile, but it doesn't open in it's own window. According to MDN, Firefox Mobile (53+) supports icons, name, short_name, and theme_color used for Add to home screen feature. if you enable the flag manifest.install.enabled in about:config (this doesn't appear to exist in 54, so maybe it's now on by default?). https://developer.mozilla.org/en-US/docs/Web/Manifest#Browser_compatibility

[ghost]

I can confirm that with Opera Mobile for Android, it also has the functionality of bringing up PWA's (that were added to the home screen) in their own window with the splash screen and without the address bar - similar to Chrome. Firefox Mobile is working on supporting this stuff (https://bugzilla.mozilla.org/show_bug.cgi?id=997779).

[ghost]

Firefox mobile has now implemented this in version 58!

[danimesq]

Other thing is ZeroFrame API supporting Electron/Cordova APIs, then deploy programs/apps with built-in ZeroNet.

[styromaniac]

Currently, the best solution for sites not dependent on JavaScript is to set a theme-color and icon in meta tags and accessed through raw/ prefix, for Chrome. With iOS devices you also need content="yes" meta tag. I've looked into creating a manifest.json and adding lines to content.json to apply in the regular view (no raw/ prefix), but I hadn't gotten them to work for such a purpose. These are needed for app-like presentation and treatment by browsers. An API that applies similar properties for multiple browsers would be nice, like theme colors, background colors for splash screens, full screen or standalone, screen orientation, icons, etc. Most important though is providing prerequisites for sites requiring JavaScript, which, I'll repeat, I have no idea how to set. Even the smallest support or wisdom here would be great, because opening ZeroMe or KopyKate from home/desktop/taskbar shortcuts in full screen would be nice. A service worker isn't a requirement for that.

[ghost]

Even the smallest support or wisdom here would be great, because opening ZeroMe or KopyKate from home/desktop/taskbar shortcuts in full screen would be nice. A service worker isn't a requirement for that.

Actually, it is last time I checked. You need at the very least an empty service worker when I first posted this issue - if you want an app-like experience (which means no address bar).

Edit: https://docs.pwabuilder.com/what/is/a/pwa/2018/02/03/pwa-min-requirements.html

[styromaniac]

Krixano, what about this? Add a shortcut. On Android at the very least, it opens in full screen. Not a PWA, but just a WA: http://127.0.0.1:43110/raw/4Kave.bit/

[styromaniac]

(not Progressive) Web Apps don't need service workers.

[styromaniac]

I'm calm, not being arrogant, just showing you what I learned, and it's valid for what you and I wanted. We just need to figure out how this can work outside /raw. In general, meta tags don't work when we'd want them to. Content.json needs equivalent strings or ZeroNet needs to read meta tags always.

[styromaniac]

Showing you up is never my goal. I see what sometimes works and hope Nofish can make it always work. I'm seeking his wisdom, not questioning yours, such as anything I can use now. You've done great things for ZeroNet. You're bigger than me in all of this and I'm giving my best answers without erroneous absolutes.

[styromaniac]

The last sentence of my first comment was hoping for wisdom from Nofish.

[styromaniac]

Rest well. I hope as much you do for an all-encompassing solution. I'm unsubscribing. The first dynamic site taking advantage of a future tip or patch that resolves this issue, I'll be studying.

[danimesq]

I'm not reading all this discussion, but Cordova/Electron frameworks with built-in ZeroNet is better.

[HughIsaacs2]

I might be able to build this as a plug-in (been tinkering with ZeroNet lately for fun), if I figure it out I'll have it rely on content.json for generating the web app manifest data (can't let the manifest be directly edited for security reasons).

Main reason I'm interested and why I found this is it would open the door for adding the native share target API to ZeroNet zites (https://developers.google.com/web/updates/2018/12/web-share-target).

Also, it doesn't require a service worker. Chrome only looks for one to have the banner displayed. Everything that's not offline, backround sync and push notifications works without it.

[filips123]

@HughIsaacs2 What security issues would be if manifest would be edited directly? Because it would be easier to just specify path to manifest file in content.json so wrapper would then include it.

[HughIsaacs2]

@filips123 the "scope", "start_url", "serviceworker" and "related_applications" sections of a web app manifest all would make it possible for a zite to hijack ZeroNet in some capacity.

So basically even if we allow linking to a manifest from content.json, ZeroNet itself will have to generate one of it's own based on the one linked, to avoid letting zites potentially hijack everything.

Also the other upside to just having the information in content.json is it can clear any overlap that the two specs may have ("background_color", "icon" , etc...).

[filips123]

What if web app manifest would be linked in content.json, but the program would overwrite "danger" sections with the safe one?

[HughIsaacs2]

@filips123 now that's you've gotten me thinking about it, I'm weighing both options.

My original idea was just to make a "web_app_manifest" section in content.json that supports everything but the dangerous stuff and generates one accordingly.

But linking to a separate manifest can't hurt.

It might make things easier for some developers.

I could also just read the manifest from a meta tag like the standards, to support multiple installable apps within one site.

[filips123]

I could also just read the manifest from a meta tag like the standards, to support multiple installable apps within one site.

That would probably be the best way.

You would then need to replace danger parts of sections like scope and start_url. It would be good to only replace parts upper than the current site, so developers would be able to create multiple apps with multiple scopes.

But not forget to prevent ../ and related "escaping" techniques.

[purplesyringa]

Whitelist is better than blacklist. I'd recommend to have a specific list of settings to allow.

[filips123]

@HughIsaacs2 Did you started anything? I would like to test and contribute to it.