Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Saving and Restoring the Web View Navigation History Across Sessions #3996

Draft
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

Saifuddin53
Copy link

@Saifuddin53 Saifuddin53 commented Sep 13, 2024

Fixes #398

Still in development

  • Enhanced history restoration by managing back and forward stacks separately and loading URLs accordingly.
  • The integrated room database is used to fetch and restore page history asynchronously using RxJava.
  • Implemented a mechanism to clear and retrieve history based on database entries.

How It Works:

  • When the reader fragment is paused the history is stored in the room
  • Upon resuming the WebView/ReaderFragment, the history is fetched from the Room database and restored.
  • Backward and forward navigation is re-established based on the saved history.

Screenshots

@Saifuddin53
Copy link
Author

Saifuddin53 commented Sep 19, 2024

Hello @MohitMaliFtechiz @kelson42
I've implemented a history restoration approach for WebView that loads pages sequentially from the back and forward stacks (stored in our room database) when the reader fragment is resumed. This solution is functional, but I would appreciate your feedback on the implementation and suggestions for improvement.

WhatsApp.Video.2024-09-19.at.11.05.05_9d0b7924.mp4

But it has some cons.

  • Currently, the time taken to restore history is directly proportional to the size of the back and forward stacks. Each URL load has a delay of 500ms, which means for a history with many items, the total restoration time could be several seconds. This could negatively impact user experience, particularly if the restoration feels too slow.

  • Ideally, the Reader screen should be blocked with a loading indicator until the history is fully restored to avoid interruptions.

  • The restoration only loads the page URLs but does not retain the user’s scroll position. When the Reader is reopened, users are taken to the top of each page, losing the context of where they left off, which can be frustrating for longer content.

On the bright side, the current approach makes sure everything is restored in order, so the navigation history stays consistent.

Also, I’ve experimented with a few other approaches to reduce the restoration time, but none of them offered the same level of accuracy. It seems like there’s a trade-off between speed and ensuring the history is restored correctly.

I’d appreciate your input on how we might address these challenges and any suggestions you have for further refinement of this approach

@Saifuddin53 Saifuddin53 changed the title Saving the Web View Navigation History Across Sessions Saving and Restoring the Web View Navigation History Across Sessions Sep 19, 2024
@MohitMaliFtechiz
Copy link
Collaborator

@Saifuddin53 Thanks for your PR, and inputs. I will test and review your PR. I have fixed the detekt issue you were facing, Now, you can continue doing your work. The codeFactor is failing can you please fix it?

@kelson42
Copy link
Collaborator

@MohitMaliDeveloper Any news?

Copy link
Collaborator

@MohitMaliFtechiz MohitMaliFtechiz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Saifuddin53 For the restoration timing issue, I am seeing the possible solution. In the meantime can you please make these review changes?

@@ -1,7 +1,5 @@
<component name="ProjectCodeStyleConfiguration">
<code_scheme name="Project" version="173">
<option name="USE_SAME_INDENTS" value="true" />
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why we are removing these codeStyle from our project?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Automated changes probably

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please revert these changes.

import org.kiwix.kiwixmobile.core.dao.entities.PageHistoryRoomEntity

@Dao
abstract class PageHistoryRoomDao {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WebViewHistoryRoomDao would be a better name for this Dao.

import org.kiwix.kiwixmobile.core.page.history.adapter.PageHistoryItem

@Entity
data class PageHistoryRoomEntity(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WebViewHistoryEntity would be a better name for this entity class.

@@ -51,4 +53,8 @@ interface DataSource {
fun saveNote(noteListItem: NoteListItem): Completable
fun deleteNote(noteTitle: String): Completable
fun deleteNotes(noteList: List<NoteListItem>): Completable

fun insertPageHistoryItem(pageHistory: PageHistoryItem): Completable
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The naming conventions are not good for these methods. It sounds like it is for getting the page history but which page history? These methods names should be:

insertWebViewHistoryItem()
getAllWebViewPagesHistory()
clearWebViewPagesHistory()

@@ -1,111 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why we are removing this file?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Automated changes

@@ -1,8 +1,4 @@
<?xml version="1.0" encoding="utf-8"?>
<!-- Authors:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please do not commit this file, it is automatically updated at runtime.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think these files are automatically updated when I have committed

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, these tarask, and tarask+old files are automatically generated while the build task is ongoing. Please do not push these changes as these are automatically done via Gradle.

@@ -68,11 +73,32 @@ class MainRepositoryActions @Inject constructor(private val dataSource: DataSour
.subscribe({}, { e -> Log.e(TAG, "Unable to save book", e) })
}

fun savePageHistory(pageHistory: PageHistoryItem) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same for these methods.


import org.kiwix.kiwixmobile.core.dao.entities.PageHistoryRoomEntity

data class PageHistoryItem(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The name should be WebViewHistoryItem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Save the back stack of visited pages before exiting from app
4 participants