* feat: db changes to accommodate new syncing logic.
Using timestamp to sync is a bit skewed due to system clock etc and therefore there was a lot of issues with it such as removing a manga that shouldn't have been removed. Marking chapters as unread even though it was marked as a read. Hopefully by using versioning system it should eliminate those issues.
* chore: add new line.
* chore: remove isSyncing from Chapter/Manga model.
* chore: remove isSyncing leftover.
* chore: remove isSyncing.
* refactor: remove isSync guard.
Just use it directly to 1 now since we don't have the isSyncing field in Manga or Chapter.
* Lint and stuff
* Add missing ,
---------
Co-authored-by: AntsyLich <59261191+AntsyLich@users.noreply.github.com>
* replace the windowInsetsPadding for navigationBarsPadding + statusBarsPadding
* Enabling TYPESAFE_PROJECT_ACCESSORS
* Adding typesafe project accessors in the app module
* Adding typesafe project accessors in the core module
* Adding typesafe project accessors in the core-metadata module
* Adding typesafe project accessors in the data module
* Adding typesafe project accessors in the domain module
* Adding typesafe project accessors in the presentation-core module
* Adding typesafe project accessors in the presentation-widget module
* Adding typesafe project accessors in the source-local module
* Adding typesafe project accessors in the source-api module
* Rolling back
* Changing TYPESAFE_PROJECT_ACCESSORS line
* Removing extra spaces
This is sort of a workaround for sources that tend to only give you the first few and
most recent few chapters, which would have been 28 day intervals before due to
the big gap in the middle.
Some behavior changes:
- It prioritizes new entries, then anything more recently updated
- It copies the more recently updated entry's metadata (description, thumbnail, etc.)
Closes#1652
Also removes the ability to trigger refreshes for the entire library or
as part of a library update as it should no longer be needed. Opening
the tracking sheet already refreshes the data too, so stale data is
irrelevant there.
Also closes#4775 since it would no longer be relevant.
These are basically 1-to-1 replacements for the existing RxJava APIs.
This will make the initial migration off of RxJava simpler. We'll
revisit the actual call flows in followup versions of the API.
