Rotate device: App reloads overview-page #2606
Comments
|
Basic UI is used to render sitemaps. The Android app renders them natively, so there's no Basic UI involved. |
Sorry yes thats what i meant 😅 |
|
Can you visit start page and the subpage in a browser and post both URLs? You can redact everything before the first |
|
Yes no problem
|
|
In addition: |
|
Can you check the demo mode and open "Positions" there? When I do so and rotate my device, the same page gets loaded again. Maybe there's a change in Android 12. The tabs on the main page (e,g. "Properties" on https://demo.openhab.org/) won't be restored on device rotation, because the don't change the URL. |
|
No Problem and thanks to your effort. Also in demo-mode, always the Overview-Page with activated Overview-tab gets loaded. Sorry if i cause work for you, just because im using Android 12 already ... |
|
And one more thing that (you sure already know) may help you: Also when i
As the app opens, i see the custom page opened before for a short moment, but than it also reloads to the overview page |
See openhab#2606 Signed-off-by: mueller-ma <mueller-ma@users.noreply.github.com>
See openhab#2606 Signed-off-by: mueller-ma <mueller-ma@users.noreply.github.com>
See #2606 Signed-off-by: mueller-ma <mueller-ma@users.noreply.github.com>
|
Thank you very much! |
|
Thanks q all
…On សុក្រ 28 ឧសភា 2021, 4:00 PM SHU-red ***@***.***> wrote:
And one more thing that (you sure already know) may help you:
Also when i
1. Open the app and go to a custom page
2. Do not rotate the device
3. Swipe away the app to the background
4. Open up the app immediately again
As the app opens, i see the custom page opened before for a short moment,
but than it also reloads to the overview page
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2606 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ATZQUZVBPYTG34NJZL5TGSDTP5LUBANCNFSM45RMQ7OQ>
.
|
|
You should receive an update to 2.17.5-beta soon. |
|
Im not at Home and Had to do it with my Phone |
|
The log doesn't contain the information I need. Can you disable debug logging in the app, clear the log and reproduce the issue? |
|
No Problem |
|
That looks better. I'll investigate this later. |
Thank you again very much |
The app loads the previous page, but short after that the webview fragment is created again and therefore loads the default start page. I'm not sure why this happens, but it might be related to Android 12. |
|
Thank you very much for your investigation! So maybe
If i can support im some way, then just tell me |
|
Update: Still the same behaviour |
|
Android 12 beta 3 is here Still same behaviour |
|
I have been seeing the UI reload on rotate ever, too. On Android 11, currently 2.18.0. |
|
The reload is not a/the problem ... the problem is jumping to the overview page in the reload process. |
That jump back problem I'm having, too. |
I'm not sure if there are any side effects of this in the Sitemaps. Maybe change AbstractWebViewFragment to an activity? Fixes openhab#2606 Signed-off-by: mueller-ma <mueller-ma@users.noreply.github.com>
|
This patch avoids the reload of the WebView: diff --git a/mobile/src/main/AndroidManifest.xml b/mobile/src/main/AndroidManifest.xml
index f2a01884..0b327bb5 100644
--- a/mobile/src/main/AndroidManifest.xml
+++ b/mobile/src/main/AndroidManifest.xml
@@ -81,6 +81,7 @@
android:label="@string/widget_type_image" />
<activity
android:name=".ui.MainActivity"
+ android:configChanges="orientation|screenSize"
android:label="@string/app_name"
android:launchMode="singleTop">However this breaks the change from one pane to two panes in the sitemaps. Maybe change AbstractWebViewFragment to an activity? |
This would lead to an empty WebView as |
|
I also suffer from jumps to the default overview page by rotation and think I have even seen it while switching network connections (mobile <->WLAN but also changing accesspoints) earlier - but I cannot reproduce it right now, maybe this part is already fixed in the meantime. What is definitly still an issue in those situations is the reload itself, as it takes quite some time. The best would be in my eyes, if the HTML is even cached on the devices locally totally for all sitemaps until they page is modified in openHAB (or a manual refresh in the app is triggered) and only the data of the shown items is reloaded - which is also done during normal operation. Edit: Forgot to mention: I am on Android 10, server: openHAB 3.2.0 and android app openHAB 2.19.10-beta from fdroid. |
|
I'm facing the same problem the UI is reloaded both on rotate and on restore. mueller-ma Your patch only fixed reload on rotate, it didn't fix reload on restore (when app is reopened while running in background) I traced the problem to be related to the WebUI fragment being recreated every time. The full patch including mueller-ma changes it fixes all reloads for me: Index: mobile/src/main/java/org/openhab/habdroid/ui/activity/ContentController.kt
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/mobile/src/main/java/org/openhab/habdroid/ui/activity/ContentController.kt b/mobile/src/main/java/org/openhab/habdroid/ui/activity/ContentController.kt
--- a/mobile/src/main/java/org/openhab/habdroid/ui/activity/ContentController.kt (revision 6be8232ad56385dee827f6a6feb581ad2404bfec)
+++ b/mobile/src/main/java/org/openhab/habdroid/ui/activity/ContentController.kt (date 1653768352713)
@@ -264,13 +264,15 @@
}
fun showWebViewUi(ui: WebViewUi, isStackRoot: Boolean, subpage: String?) {
- val webViewFragment = ui.fragment.newInstance()
- webViewFragment.arguments = bundleOf(
- KEY_IS_STACK_ROOT to isStackRoot,
- KEY_SUBPAGE to subpage
- )
- webViewFragment.setCallback(this)
- showTemporaryPage(webViewFragment)
+ if (temporaryPage == null) {
+ val webViewFragment = ui.fragment.newInstance()
+ webViewFragment.arguments = bundleOf(
+ KEY_IS_STACK_ROOT to isStackRoot,
+ KEY_SUBPAGE to subpage
+ )
+ webViewFragment.setCallback(this)
+ showTemporaryPage(webViewFragment)
+ }
}
/**
Index: mobile/src/main/AndroidManifest.xml
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/mobile/src/main/AndroidManifest.xml b/mobile/src/main/AndroidManifest.xml
--- a/mobile/src/main/AndroidManifest.xml (revision 6be8232ad56385dee827f6a6feb581ad2404bfec)
+++ b/mobile/src/main/AndroidManifest.xml (date 1653768741323)
@@ -87,6 +87,7 @@
android:exported="false" />
<activity
android:name=".ui.MainActivity"
+ android:configChanges="orientation|screenSize"
android:label="@string/app_name"
android:launchMode="singleTop"
android:exported="true">Some other unrelated things that I noticed that may potentially cause problems in future with the state saving:
|
'This' being what exactly?
The fragment being recreated on activity recreation is expected behavior. Or what exactly does 'every time' mean? The stack trace makes it look like the app was opened by a shortcut to OH3 UI?
Which unfortunately is a combination of two ugly hacks. Maybe the check for the existence of temporaryPage isn't a bad idea, but when doing that one needs to check whether the temporary page has the same parameters and type as the expected new page. |
Example Steps:
Expected:
Actual:
I'm not arguing that from a code perspective this is what we should do on activity recreation, my point is this is what is breaking usability, maybe the proper fix should be to figure out why we do activity recreation when you switch to already running app in the background.
I agree these are ugly hacks, this is why we need someone familiar with the project to come up with the correct solution. I would look into why we create a new instance of fragment when you switch into app from background. |
|
It seems in the current beta version of the app, the behavior has been improved. Rotation refreshes the page, but does not change the page anymore. |
|
Instead of trying to improve our fullscreen webview, we could switch to custom tabs. I started on this and was able to fix this issue: https://github.com/mueller-ma/openhab.android/commits/custom-tabs (Needs some rework of existing classes). Also see https://developer.chrome.com/docs/android/custom-tabs/integration-guide/ |
While I generally think this is a good idea, there's two possible caveats here:
|
I currently tested it and after a device rotation, im getting thrown back to the Overview pate again
Im not sure if this is related to the topic here? |
The idea is to show all web pages (OH3 main UI, HabPanel etc.) in custom tabs. |
We could move all the sitemap code to a new activity
Custom tabs can be run by many browsers: "Custom Tabs is supported by most Android browsers." (from https://developer.chrome.com/docs/android/custom-tabs/integration-guide/#what-happens-if-the-user-doesnt-have-a-browser-that-supports-custom-tabs-installed)
With custom tabs we can use browsers to display the UIs that are based on websites (vs sitemaps that are based on a JSON API). These browsers have been built with more developer resources so issues like this, #3048, #2974, #2819 and maybe some more should be fixed. |
And how would one access e.g. the preferences in that kind of setup? If you now say 'via SitemapActivity', you have just given MainActivity a new name. If you say 'via MainActivity', how does one get there and what is its content?
Isn't that kind of helpers exactly what distinguishes the dedicated app from a browser? IOW, what's the advantage of using the app instead of the browser in the proposed setup?
I'd rather look at it from a different angle: maybe we just have to accept that a WebView is not a fully fledged browser, and rather check whether main UI can help us, e.g. by consistently reflecting navigation in the URL? Nevertheless, introducing custom tabs is a good idea, but IMHO only for opening content that currently is redirected to a browser. |
I didn't think at that.
Good point 👍
I think the issue here is that the WebView reloads at all: The content disappears for a short moment and e.g. the scroll position is lost. |
This seems to be the case: Switching tabs in Main UI also changes the URL now, so the Android app reloads exactly this page. |
Actual behaviour
Example:
Expected behaviour
Steps to reproduce
Environment data
Client
Logs
App log
Click to expand
The text was updated successfully, but these errors were encountered: