Add feature to fire event when application resumed from background

[SHanded]

Describe the bug Wallpanel doesn't seem to receive any sort of event when turning the screen on or off. No onfocus/onblur, no onvisibilitychange.

To Reproduce Add an onfocus/onblur/onvisibilitychange eventlistener to your page, turn the screen off and on, no event fires. (Visibilitychange fires when pressing HOME or App Switcher button and then returning to Wallpanel.)

Expected behavior On turning off the screen, the browser should get a visibilitychange and document.visibilityState = hidden On turning on the screen, the browser should get a visibilitychange and document.visibilityState = visible

Smartphone (please complete the following information): Samsung Tab A10.1, everything up-to-date.

Additional context Maybe I'm just too blind, but I haven't found a single way to detect via JS that the tablet screen has been turned back on. This event would be super important to re-sync my smarthome page to its actual, current state in case someone else used the interface on their phone to turn devices on/off.

My tablet's lock screen is completely off (not even swipe). I've tried different lock screens as well but since Wallpanel renders in front of them, no change. Ideally, it should work with lockscreen off. Just a simple double-tap on the screen, it turns on, Wallpanel fires the event, the page updates.

For reference, event fires correctly on -Firefox for Android -Samsung Internet -Bromite

[aukedejong]

Hi, I had the same issue.

See this link: https://community.thanksmister.com/t/wallpanel-updating-home-assistant-ui-only-after-touchscreen-touch/112

I fixed it by changing wallpanel code myself, but I'm not an Android app developer. I think Mister himself can make a more elegant fix.

The problem is that after tablet wake up the WebView component doesn't get focus.

Auke

[thanksmister]

This application is meant to run as a dedicated wall mounted app, it is not meant for that device to have the screen turned off for the device to sleep.

Having the device sleep or having the device off breaks the the other features of the application the require a constant connection such as MQTT, Motion, Sensors, and HTTP streaming.

It sounds as though you want to run a mobile app, one that receives notifications when the device sleeps or is locked. For that, you can try something built for mobile devices like Home Assistant mobile companion app, it can receive push notifications through push when the device is asleep.

[SHanded]

I don't quite understand. Do you think no one uses your software on a tablet whose screen turns off? Because I think a LOT of your users use it that way. Especially with the new Android versions that support double-tap-on-screen to turn it on. Even dedicated, wall mounted panels can profit from having the screen turned off when features such as MQTT aren't needed.

I don't need push notification receiving or anything like that, it should just correctly fire the visibilitychange event. Do you know what I mean? It's a normal Javascript event like focus, blur, change, mouseover, etc.

All browsers I tried it in, it works. But they offer an ugly address bar and aren't full screen. I need exactly WallPanel and nothing else, but with working visibilitychange... :(

[aukedejong]

I agree with SHanded.

The tablet goes to sleep (at least the screen is off) but MQTT keeps working. That's why you have the MQTT wake command, right?

My tablet is wall mounted, only charging when needed. Text to speech is working, while the screen is off. Sound playing is working when the screen is off.

I made the fix myself and it's working. It's not a big change.

Can you explain why not? Are there technical reasons?

[thanksmister]

MQTT wake command is to turn off screensaver. The app uses deprecated feature called wake lock to keep screen on when screensaver feature active. If screensaver feature is off then you can use whatever device options to have to control the screen. Devices do continue to allow background tasks android services until those tasks garbage collected. A sleeping device will try to kill background task or services when charging, when’s in sleep mod, when sleep locked. There is not guarantee that a device will allow a background service to continue while the screen is off.

If the app continues to function when the deuce is off then you can simply not use the app screensaver and the app will not initiate screen lock override or try the prevent the screen from sleeping. I thing is preventing your use case, you can do whatever your device allows with the screen. However, the reason your asking for a method to be placed into the resume of the application is because the aplicación was actually put into the background. As I stated, when the app is put into the background, the functionality stops working. This is why I recommend using a screensaver.

You two are arguing both sides of the same argument. Your telling me that the app continues to work when the device sleeps but then also asking me to fix it so that when the app resumes from the background, we add additional methods so that iWebView renders the page again. You also presume to know the app users and suggesting that many these users require this feature and that I have neglected them. I can tell you that is not true at all. Most devices are Fore OS and running older version of Android. I am definitely not neglecting users by designing the app to work as a dedicated foreground application. It’s actually the opposite, most of the features are to support the app in a kiosk like mode.

I have a backlog of features from users who think their feature is also as important to them as you think this feature is to you. Yet I have only ever had a handful of contributors at most to support a community of 50k. I work on bugs and features I think support the purpose of the app and the user base.

I appreciate that you like the app and that you have communicated your opinions. You are welcome to create a pull request, fork the application and make your own, or use another application such as Fully Kiosk Browser. Please be mindful that just because you use the application does not entitle to have your request or features added. This is a free and open source project which supports a large number of users. As the maintainer, I decide what features are important and what features support the purpose of the application. I maintain this project freely in my spare time and outside my role as a full-time mobile developer.

[aukedejong]

You seam a little offended, but I could be wrong. I don't think our intention was to offend you. Just trying to understand why you closed the feature request. But it is open again. Thanks for that!

Ok, why the wake command. I understand now. Just happy it also turns the screen on and not only turns off the screensaver.

Maybe I can find some time to make a pull request.

Thanks for the great work.

[thanksmister]

I closed this feature request because it's not a supported use case. The application does not need to support users who want to put the application in the background. Your only evidence that this is something everyone does and that it causes no issues is "it works for me".

You state both that this works for you, but that you also need a "fix" to make it work for you when the app is put into the background. I haven't seen a PR yet, but when I do see a PR, I will review it and determine if it aligns with the application purpose and make a decision about if this feature should be supported at all.

[aukedejong]

Just wanted to start working on a pull request, but couldn't reproduce the problem anymore.

The changes made by Mark Godwin on 15 Januari 2021 fixed it.

I tried to find out why, just to learn something. This statement in the hideScreensaver method seams to do the magic, even when the screensaver is disabled.

window.clearFlags(WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON)

After a wake from sleep, Home Assistant UI updates the entity states. @SHanded, I'm not sure if this fixes your issues.

Disclaimer, only tested this in de emulator. Before I could reproduce it in the emulator, but not anymore.

Thanks.