mirror of
https://github.com/tzapu/WiFiManager.git
synced 2026-04-27 00:55:52 +03:00
[GH-ISSUE #657] Proposal for strategy to create in-device web apps accessible from mobile device home screen #548
Labels
No labels
📶 WiFi
🕸️ HTTP
Branch
DEV Help Wanted
Discussion
Documentation
ESP32
Example
Good First Issue
Hotfix
In Progress
Incomplete
Needs Feeback
Priority
QA
Question
Task
Upstream/Dependancy
bug
duplicate
enhancement
invalid
pull-request
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/WiFiManager#548
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @jonathan-annett on GitHub (Jul 14, 2018).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/657
i've had some success on a small scale creating web apps that are served entirely within an esp8266 and are "launched" by tapping an icon on my phones home screen. this approach is fine for one-off deployment to "my phone" as i can hard code values as i see fit, but not really useful for deployment to third parties
I've been thinking wifimanager's startup logic could be massaged slightly to facilitate this approach, and perhaps a mini framework that launches a relatively useless starting point for more useful apps (for example the default functionality of the the "app" would be to allow the user to use their phone to toggle the LED on and off). once this project exists as a boilerplate framework, developers could replace this "hello world, i'm an LED app" to do what they want.
attached is starting flowchart of how the logic might be adapted to do this.
( there's another concept that would be simpler for the user, but requires them to edit the name of their phone's SSID to conform to a pattern based on their devices MAC, along with a preselected PSK based on that MAC, which they can later update to whatever they want, should they choose to)
Untitled Diagram (3).pdf
just wondering if you would consider working on a fork that takes this approach on board, or maybe incorporating ideas into the existing framework that would make this a function set of the whole project
@tablatronix commented on GitHub (Jul 14, 2018):
Once we figure out #461, this should be pretty easy for users to do without having to bloat the library.
and eventually we can add a spiffs webserver with some kind of webpack for making apps. I am just not convinced this needs to be a wm feature.
@jonathan-annett commented on GitHub (Jul 14, 2018):
the main issue is the user needs to be in a position where the phone is displaying the launch page on the correct ip. you can't just create a home page link with a "future ip address". since the phone is responsible for generating the ip address and serving it by dhcp. you can't guess at what that ip address might be.
@jonathan-annett commented on GitHub (Jul 14, 2018):
once allocated however. phone generally issue the same ip to connected MACs, assuming you use the app relatively regularly
@jonathan-annett commented on GitHub (Jul 14, 2018):
the PWA approach would work. however since it's a requirement for PWAs to have https, it's not easy to do that in a situation where the device doing the serving (the esp8266) would need to corrrectly serve a valid cert tied to a valid dns entry, so we need to use plain http to an ip which "add to home screen" still supports.
@tablatronix commented on GitHub (Jul 14, 2018):
I still am not sure I understand how this solves this issue, the only way you can get to the server without an ip is captive portal(sotap) or sta with hostnames set ( and a compatible device for mdns )
@jonathan-annett commented on GitHub (Jul 14, 2018):
it's not a problem to save a home screen shortcut to an ip address. thats' not the hard part, it's communicating to the user what that address is, so they can display it in the first place.
my flowchart deals with this by serving a page to the user that contains a link to the ip addreess, it just means they need to start their hot spot up a few times so the 8266 can figure out what it is and then display that link page.
@tablatronix commented on GitHub (Jul 14, 2018):
You cannot save a home screen from captive portal, the user has to manually goto the ip in a browser.
At least that I know of, am I wrong ?
@jonathan-annett commented on GitHub (Jul 14, 2018):
sure however if the captive portal serves some html with an A link to an ip address, the user clicks on that and they end up at a hard coded ip address in the address bar. they then add that url to the home screen.
@jonathan-annett commented on GitHub (Jul 14, 2018):
all "add to home screen" does is save a cached copy of the existing content, and the url that served it to a shortcut file. on reopen, it displays the cached content while it attempts to reload the url. it then updates the browser with actual content.
there are some other things it does in terms of permissions - eg allowing full screen access without an address bar, but that's irrelevant to this discussion
@tablatronix commented on GitHub (Jul 14, 2018):
I will try on my iphone tomorrow , but I am pretty sure the captive portal is sandboxed fairly well, as in there is no way to do any of that.