* Now, the storage selection (internal/external) is directly visible in the settings, allowing users to select storage without using a dialog box.
* The total and available space for each storage option is displayed.
* Additionally, the selected storage path is shown in the settings, so users know where the downloaded files will be saved.
* Now, it asks for an evaluation when the user has opened the application at least 20 times, has been using the application for the past two weeks, and has one or more ZIM files in their library.
* The issue was that we were writing the content on the IO thread using a coroutine, which was called from a `suspend` function. The function was suspended while loading the content, causing the `PipedOutputStream` to be flushed prematurely and resulting in the failure to render the remaining data.
* To fix this, we removed the content rendering from the coroutine and are now using `Completable` to render the content on the IO thread.
* Created a new package name for the website and nightly APK so that the playStore does not recognize it and do not show updates for these apks.
* Refactored the release CI to upload the app with this new appId.
* Refactored the code to correctly retrieve the file name from the URL or source, which was causing issues with TED ZIM files.
* Added test cases to prevent this situation in the future.
* Implemented a method to automatically generate a unique version code by calculating the number of days from the reference date (July 17, 2024) to the current date and adding this value to the base version code (231101) from the last release.
* Added a workflow that automatically generates the bundle and uploads it to internal testing every Monday at 12:00. This workflow will also trigger under the `internal_testing` tag.
* Since we are implementing this, it is necessary to directly release the bundle to internal testing instead of placing it in draft (to eliminate manual steps), so we have refactored our code accordingly.
* The getData method of the Item class was throwing an error due to any condition, the reason is unknown(may be the data is corrupted or anything) since there are only very less occurrences but it was crashing the application so we are catching the exception if thrown by the `getData()` method so that our application will not crash.
* The application was crashing while casting activityMainRoot to ViewGroup, which was null at that point (possibly because the user switched to another fragment). We were attempting to cast a null variable to a non-nullable type.
* The WebView can return null, and we handle that in our CoreReaderFragment when creating the WebView object.
* To fix this, we modified the `createWebView` method to avoid casting any null variables and to ensure that no null variables are passed when creating the `ToolbarScrollingKiwixWebView`. If a null variable is encountered, it will throw an `IllegalArgumentException`, which we handle during the creation of this object.
* 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.
