* Previously, we are checking the bookmark is added or not when a page is fully loaded in the webView. In the meantime previously set bookmark toggle is showing e.g. if the previous page is added as a bookmark then until the page is fully loaded the toggle is showing that the current is added as a bookmark. However, this new page is not added as a bookmark.
* To fix this latency, we moved our `updateUrlProcessor()` method to the `webViewProgressChanged` method to update the bookmark toggle when a page starts loading in the webView. This fixes the latency in updating the bookmark toggle.
* In the notification, the information coming from `fetch` does not include the ZIM title (only the file name is currently shown in the notification). However, we have the `FetchDownloadDao` where we save all the details related to downloads. We have created a method in `FetchDownloadDao` that retrieves the downloadEntity from the file name, which includes the ZIM title, and we are now displaying that title in the notification.
* The serialization issue was fixed in coroutine version `1.7.0`, so we have upgraded the coroutine dependency to `1.7.0` to address this issue.
* In the new version of coroutines, `ConflatedBroadcastChannel` is replaced with `StateFlow`, so we have refactored our code to use `StateFlow`.
* Fixed some detekt issues which occurs after upgrading this dependency.
* id is the primary key for notes/history and when there is an already id available in the room database, and if there is the same id present in the objectbox database and we try to put that entity in the room it gives the SQLiteConstraintException. To fix this we have modified our saving functions of history and notes. If there is already an ID that exists in the room database that we are trying to put in the database it will set the ID to 0 so that the room will automatically assign the ID to that entity and our history/notes will prevent to be lost.
* Added the test cases to properly test these scenarios.
* We have implemented `setHasStableIds(true)` in our RecyclerView, which handles data updates efficiently and enhances view recycling. It also provides smooth animations when data is refreshed. However, it requires unique IDs to perform these operations effectively. Since our bookmarks are stored in libkiwix and do not have unique IDs (database IDs), this sometimes results in duplicate data being displayed in the list instead of the actual data, as the lack of unique IDs causes the same data to be repeated when recycling non-visible items.
* To fix this, we have explicitly provided unique IDs by combining a UUID with the maximum value of a long. This ensures that RecyclerView can efficiently handle large data sets.
* Outdated text was showing when a zim file could not open in the kiwix, this text was for the older UI, and now we have removed the "Device Tab" from the "Library" screen so this text is outdated and misleading the users. so we have changed this text according to the new UI.
* Enhanced the loadMoreSearchResults method to accommodate this modification.
* Refined the render method to effectively cancel any previously running tasks upon its subsequent execution.
* Enhanced retrieval of suggestion lists from libzim.
* Implemented task cancellation if the fragment is not visible.
* Refactored getVisibleResults into a suspend method to ensure efficient job cancellation.
* Handled exceptions thrown by coroutines.
* Transitioned to Kotlin Flow instead of Flowable after making getVisibleResults suspend.
* Employed lifecycleScope for coroutine launch to prevent unnecessary calls when the fragment is hidden.
* ServiceWorker was being initialized every time the `CoreApp` instance was created. When the application crashed, `ErrorActivity` was invoked to send a crash report, running in a separate process. In this new process, the ServiceWorker was also being initialized.
* Upon user interaction (e.g., clicking "No Thanks" to relaunch the app), the application returned to the main process, leading to a second initialization of the ServiceWorker with the same data directory, causing a crash.
* Since `ErrorActivity` does not require any WebView-related functionality, it is unnecessary to initialize the ServiceWorker in this process.
* The fix involves modifying the initialization code to ensure the ServiceWorker is only initialized in the main process of the application.
