I've also changed the cutoffs to 5% rather than zero, as this seems like
a saner method of showing this dialog. With levels 5% or less, the game
is basically inaudible.
Arguably, the cutoff can be increased to 10%.
- Removed the Xamarin.Essentials package from osu.Game and added it to osu.iOS and osu.Android only.
- iOS and Android implementations use Xamarin.Essentials.Battery, while the Desktop implementation
only returns 100% battery for now.
- Added a BatteryCutoff property to PowerStatus so it can be different for each platform (default 20%, 25% on iOS)
- Uses Xamarin.Essentials in osu.Game.PlayerLoader to check battery level
- Encapsulated battery checking in the public BatteryManager class so battery level and plugged in status can be accessed and edited in TestPlayerLoader
- When checking battery level, catch NotImplementedException thrown by Xamarin.Essentials.Battery on non-mobile platforms
- Added visual unit tests for battery notification
To mock battery status and level, we had to define a batteryManager object in TestPlayerLoader and add a new function ResetPlayerWithBattery()
Co-Authored-By: Marlina José <marlina@umich.edu>
Previously it was being scheduled another time each OnResume, resulting
in more and more calls as a user retries the same beatmap multiple
times.
To simplify things I've decided to just schedule once ever. This means
that on resuming there's no 400ms delay any more, but in testing this
isn't really an issue (load time is still high enough that it will never
really be below that anyway). Even if gameplay was to load faster, the
animation should gracefully proceed.
Previously the beatmap would begin loading at the same time the
`PlayerLoader` class was. This can cause a horribly visible series of
stutters, especially when a storyboard is involved.
Obviously we should be aiming to reduce the stutters via changes to the
beatmap load process (such as incremental storyboard loading,
`DrawableHitObject` pooling, etc.) but this improves user experience
tenfold in the mean time.
