* Now all the downloading files will store in this public app-specific directory.
* Refactored the code to show this new location in storageSelection dialog for both internal and external storage.
* Updated the `README.md` file to educate user that how they can read already downloaded zim files in PS version.
* Refactored the test cases according to this change.
* 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.
