* Removed the custom logic for color inversion of WebView content so that ZIM files can automatically apply the `prefered-color-scheme` setting based on the app theme.
* Removed unused code and test cases from the project.
* Displaying the downloaded size and total size in the download notification.
* Displaying the same information in the Download screen UI. We have moved the Download Progress text ("In Progress", "Downloading", "Paused") above the progress bar, and now show the size information in its place.
* Refactored code to retrieve the ZIM file from `LibkiwixBookOnDisk` instead of `NewBookDao`, since `NewBookDao` no longer exists and books are now stored in `Libkiwix`.
* Added a UI test case for this deep link to verify correct behavior.
* Added `testZimHostDeepLink` to specifically test the new compose deep link and help prevent future regressions.
* This happened because ZIM file scanning was moved to the IO thread while the WebView was restored on the main thread (a WebView can only be accessed from the main thread) as part of the fix for #710. As a result, the main page sometimes loaded into the current WebView — on some pages it appeared immediately after the searched page. We have now fixed this behavior.
* Previously, the ZIM file was always fetched and loaded in ZimFileReader whenever the reader screen became visible. This was redundant for custom apps, since they only use a single ZIM file. Once the ZIM file is set in the reader, there is no need to fetch and load it again. We have improved this as well: if there is no ZIM file in ZimFileReader, it will fetch it from the assets folder or storage and load it into the reader. If the ZIM file is already loaded, it will simply restore the previous history in the reader. This reduces unnecessary fetching and setting of the ZIM file. Since custom ZIM files can be large, avoiding redundant fetching and loading saves both time and computation.
* This happened because we moved the file scanning logic to the IO thread, and inside that, we were also opening the ZIM file in the reader on the IO thread, and then restoring the tabs (which is now done on the Dispatcher’s main thread instead of the UI main thread). Because of this, the WebView was loading freely and saving new history in the database, which cleared the previous history. As a result, the tabs were not restoring.
* Now, we are not saving new WebView history while restoring tabs, which avoids this issue in a multi-threading environment.
* Made `restoreViewStateOnValidWebViewHistory` and `restoreViewStateOnInvalidWebViewHistory` suspend functions so they can run in the same scope from where we are opening and restoring tabs.
* In Compose, when the screen rotates and the screen width is above `600dp`, the `drawerState` is automatically set to `open`. Because of this, the issue was happening.
* Now we are storing the `drawerState` and updating the `leftDrawerState` based on the previously saved value when the orientation changes.
* Fixed: `LongMethod` lint error.
* The issue occurred when reopening the `ZimHostScreen`. The presenter was detaching the view of the previous `ZimHostScreen`, but since the presenter is a singleton, it also cleared the reference to the view attached to the new `ZimHostScreen`. As a result, the `ZimHostPresenter` could not post books because the view reference was null.
* Updated `BasePresenter` so that it only detaches the view if it matches the one currently attached, preventing accidental clearing of the new screen’s view.
* The failure was caused by immutable arguments in navBackStackEntry that could not be cleared. To work around this earlier, we replaced the reader fragment with a new one before navigating to another screen so that arguments could be reset. However, this approach had side effects: reopening the same fragment in the background triggered extra computation, since everything in the reader screen renders on the IO thread. As a result, the previously opened page was sometimes only partially rendered, and when the test navigated back, it failed to load correctly.
* To resolve this, we have completely removed the use of navArguments, as they made handling different scenarios more difficult. Instead, we now rely on the savedStateHandle and set arguments directly on the backStackEntry. These can be cleared immediately after use, ensuring they don’t affect other scenarios. This approach not only fixes the failing test but also eliminates redundant fragment rendering, reducing unnecessary work on the IO thread.
* Moved the file-scanning logic to the IO thread, allowing smooth directory scanning or ZIM file preparation from the asset directory while keeping the main thread free.
* Refactored `CustomFileValidatorTest` to align with this change.
* Corrected the ZIM URL in `testZimFileRendering` test.
* Improved the `manageExternalLaunchAndRestoringViewState` for thread safety.
* Removed the code that auto-scrolled the list to show the progress bar. Now, users will see the progress bar only when they scroll down to load more items.
* Improved `isLoadingMoreItem` handling to avoid duplicate `loadMore` calls after appending items
* Fixed: When opening a new ZIM file from the local library and pressing the back button repeatedly, the previously loaded empty ZIM file reappeared in the reader.
* Fixed: Cached book for bookmarks sometimes returned "null" because it wasn’t properly cleared when navigating to other screens.
* Fixed: Tabs were not restoring when navigating to another screen via the bottomAppBar.
* Refactored the "FIND_IN_PAGE" flow — since we can now directly set the result on the previous back stack entry, relaunching the reader screen is no longer required.
* Fixed: Tabs not restoring when returning from left drawer screens.
* The issue occurred because the reader screen route was not being created properly, as both modules had different destination classes. We made the openPage method abstract so that each module can provide its own destination with arguments to correctly open pages.
* Improved WebView creation in Compose.
* Cause: The request object emitted after user confirmation was identical to the previous one, so the flow collector skipped it and the fetch was never triggered.
* Solution: Added a `System.nanoTime()` field to the request to ensure a unique emission while still preserving existing values.
* Refactored the `updateOnlineLibraryFilters updates onlineLibraryRequest` according to this new change.
* Fixed: When launching the app fresh (cold start), the search screen could appear before the ZIM file was ready (because ZIM file loading in the reader happens on the IO thread), resulting in no search results. Now, incoming actions are delayed until the ZIM file finishes loading so that search works correctly.
* Fixed: Multiple fragment instances were created when repeatedly opening different fragments via bottomAppBar buttons, causing the back button to bring them to the foreground one by one instead of expected behavior.
* NavBackStackEntry arguments are immutable, so switching to `FIND_IN_PAGE` used arguments from the previous ReaderFragment backstack entry.
* Fixed by popping the old ReaderFragment from the backstack and launching a fresh instance with the new search arguments.
* Fixed: Multiple `SearchScreen` instances showing when repeatedly opening the search screen.
* Fixed: Reader screen showing an older ZIM file after opening a new one and pressing back.
* Refactored `SearchInPreviousScreenTest` according to the new changes.
* Minor improvement in navigation.
