At this point its primary usage is the daily challenge event feed, but
the leaderboard will be using this too shortly.
Because the playlists results screen that exists in `master` is
hard-coupled to showing the *local user's* best result on a given
playlist by way of hard-coupling itself to the relevant API request,
allowing show of *arbitrary* score by ID requires a whole bunch of
subclassery as things stand. Oh well.
Class naming is... best effort, due to the above.
Addresses https://github.com/ppy/osu/discussions/23787
I originally wanted to set `allowShowingResults` to false if there are
no results but because this involves an API request to fetch the scores
that would mean all the scores would have to be fetched all at once so
that it knows whether to hide or show the "View results" button on a
beatmap.
Because that would slow things down and be very inefficient, this still
allows the user to view the scores screen but if there aren't any
scores, it shows a text, which I think is at least for now better than
nothing.
As for the testing of this, I wasn't sure how to not generate scores
only for one specific test so I opted into not using `SetUpSteps` and
doing it that way.
Basically, the failing delayed test would fire two web requests during
the proceedings. In unfortunate timing, the first would succeed and the
test would think "everything is okay", but the actual request loading
results has not yet run.
This check ensures *something* is loaded, which seems to be enough to
make things reliable.
As seen: https://github.com/ppy/osu/pull/17252/checks?check_run_id=5545717506
The `PlaylistsResultsScreen` takes a lease on the `Beatmap` bindable
when entered. During `SetUp`, the `Beatmap` bindable is reassigned but
fails in cases where an existing test instance of the screen hasn't been
exited yet. This fix moves the assignment into the `SetUpSteps` function
after `base.SetUpSteps` is called which will exit the existing screens
first.
One of my pending work items for post-realm merge.
The lowest-level import task is no longer asynchronous, as we don't want
it to span multiple threads to allow easier interaction with realm.
Removing the `Task` spec simplifies a heap of usages.
Individual usages should decide whether they want to run the import
asynchronously, by either using an alternative override or spooling up a
thread themselves.
