* 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.
* It was not showing the article when fresh application is installed on device with list of fds, and after the first install it works normally(It starts loading the article). So we have placed a fix for this.
* Introduced the splitting zim file with 500MB for custom apps. Since the bundle has a limit for a file to upload it uses the play asset delivery mode, and for new custom apps, playStore does not allow to upload the apk (with apk we can upload more than 1GB file). So to address this issue we have introduced a feature in libzim where we can load the zim files via the fd list.
* We have modified our code to upload the files with 500MB chunks in the asset folder, and later we are accessing these files from the asset folder and creating the archive object with the help of the new libzim feature.
* YouTube videos were not playing in the Android reader because the response code for the video URL was 206 (Partial Content). The `Content-Range` header of the incoming data was being set incorrectly. This happened because the `data` had a size of 0, as the content was being written on the IO thread (to avoid blocking the UI thread) when loading in the WebView. Due to this, the `Content-Range` was set incorrectly, preventing the YouTube video from playing.
* To fix this, the correct content length is now passed to the `Content-Range` header, ensuring that the video plays correctly.
