* Loading the video on the background thread so that it will not block the UI thread, and the user can easily use the UI(For better video loading in case of a large video file) while ensuring that it returns the inputStream.
* This video's size was already coming in the data, and we were again loading the url for getting the size of content while returning the webViewResponse to webView for rendering so we have refactored our code to use the same existing data, and if existing data does not have the size then we are getting the video size from libzim.
* Rendering the HTML data on the IO thread.
* We were creating the file objects twice to get the inputStream of a video file which takes more time to render. Now we are using the same file object for getting the inputStream.
* These changes reduced the video loading time
* Articles containing special characters like # in the URL were causing problems. We had previously implemented logic to retrieve data from libzim by trimming the URL before these characters to properly load videos, images, and other articles. However, this logic caused the URL to break under certain conditions.
* To address this, we implemented a fallback mechanism. If libzim does not return the expected data using our initial logic, we now attempt to retrieve the data using the full, unmodified URL. This change ensures that URLs with special characters (e.g., #, ?) will be processed correctly, preventing loading issues for such media and articles.
* Caught the exception if any thrown by the libzim when getting the random entry.
* When this type of error occurs then we have refactored our code to show the random article instead of a (blank/ same page) currently loaded in the webView.
* In custom apps we are using the assetFileDescriptor, and the `dup()` method of `parcelFileDescriptor` is internally throwing resource leak exception(found in the debug stacktrace while running the application under the strace) and it somehow impacting the suggestion API.
* Removed the dup method of the `parcelFileDescriptor`.
* 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.
