The preloading of the topmost cards has been moved into the browser,
since it's not useful for the JS API, but this makes the
searchCardsNumberOfResultCount() test harder to port. Since the
CardCache should be removed in the future, I don't think it's worth the
effort of getting the test working again.
Closes#12223
PartialSearch offers no value anymore, as the entire SQL query is
calculated by the backend before the legacy Kotlin code gets access
to it.
Tweaks were required to the Finder tests, as previously the legacy
code path was being used even when testing with the new schema enabled.
Easier to follow, and exceptions when calling sched.answerCard() are
now caught, so with issues like #12179 and #12155 will result in a
message being shown to the user instead of an app crash.
The two additional runTest calls take advantage of the unconfined
dispatcher introduced in a previous commit, ensuring the coroutine
completes in time. Without adding them, the two tests fail due to a
race condition.
This appears to allow us to avoid explicitly waiting for coroutines in
the common case. See the comment in RobolectricTest for why this and
not StandardTestDispatcher was used.
Also opted in to the coroutines API at the module level, so we don't
have to tag every unit test with @OptIn.
The recommended way to test coroutines in Kotlin is to wrap tests in
runTest(). Unfortunately, doing so was tending to trigger deadlocks.
It appears to be caused by calls to runBlocking() inside runTest().
These happen fairly frequently, as legacy code fetching the collection
from CollectionHelper end up invoking a runBlocking() call inside
CollectionManager.
To work around this, I've made CollectionManager bypass the runBlocking
call, and access the collection directly.
This change caused the verifyStartupNoCollection() test to start failing,
presumably due to a change in timing. It was calling colIsOpen() and
being told the collection was open, because enableNullCollection() was
closing the collection but not preventing it from being implicitly
reopened.
Our code coverage fluctuates, meaning that CI is often shown as failed
even on no-op operations
This is bad for our developer experience: we can't trust CI status to
be reporting correctly, and this slows fixing actual issues
So, we mark codecov as 'informational' so only 'real' CI failures are
shown to users
> If `true` is specified the resulting status will pass no matter what
> the coverage is or what other settings are specified. Informational
> mode is great to use if you want to expose codecov information to
> other developers in your pull request without necessarily gating PRs
> on that information.
https://docs.codecov.com/docs/commit-status#informational
Related issue: 12227 - fixing the flakiness in other ways
* NF: JSONTokener takes non null string
The original implementation state that a null value would lead to NPO at first
function call.
* NF: JSONObject's copyFrom constructor take non null key
That's a requirement from parent's implementation
* NF: ensure JSONObject's constructor takes a non null tokenizer
It was already enforced with !!
* NF: remove checkName
As indicated, it was always called on nonNull so identity
* NF: numberToString non null
* NF: deepClonedInto: make clone non null
My understanding is that this method will often be called either on fragments,
and using the fragment's activity. So it seems to make sense to simplify it,
ensuring that we avoid a parameter that will probably never change.
Actually, since activities are also LifecycleOwner, it may be possible to ensure
this method is even simpler, by defining it on activities instead of defining it
on LifecycleOwner. Unless we have a reason to use an activity distinct from the
LifecycleOwner.
Also cleaning from function I viewed at the same time
* Displays the App Introduction System
* Handles only displaying it once
* Handles syncing if the app intro loads an existing AnkiWeb account
* (special case) Handles an upgrade from 2.15 -> 2.16 where
the preference for the app intro was unset.
A screen which appears on the first run of the application
Displaying:
* Get Started
* Sync from AnkiWeb
This aims to handle the use case of an existing user.
If they do not sync immediately, then they risk creating
two collections, which are incompatible and cause a sync conflict
Based on 9130 by Shridhar Goel
The Introduction activity is the first activity that users see
and therefore should be nicely designed.
* intro_gradient.xml
Contains a background gradient for the top of the introduction:
a blue to white/black gradient
* intro_ankidroid_logo:
Contains the AnkiDroid logo, encircled in a semi-transparent colour
* Due to bugs with `<aapt:attr>` in ankidroid_logo, in v21-23 this is
just the AnkiDroid logo with no transparent circle
Designed to go on top of intro_gradient
If disabled, auto-sync isn't triggered on metered connections and the user is asked if they want to continue if they trigger a manual sync
If enabled, sync occurs normally
