Open nt4f04uNd opened 1 month ago
Tracking and waiting for all unawaited futures seems non trivial, and I like the idea of creating the controllers at the start and passing them in when creating the widgets, because it could eliminate a bunch of late variables. The downside is that we would have to pass the controllers in and can't use the global singletons anymore. Would you be ok with that approach?
Tracking and waiting for all unawaited futures seems non trivial, and I like the idea of creating the controllers at the start and passing them in when creating the widgets, because it could eliminate a bunch of late variables. The downside is that we would have to pass the controllers in and can't use the global singletons anymore. Would you be ok with that approach?
Yes, singletones are a tech debt https://github.com/nt4f04uNd/sweyer/issues/81
Although, please let's not do any major refactorings just yet. There is a new open source library coming out next week, which will be perfect for rewriting our application DI and business logic. I'll let you know.
I was looking into the root cause of this some more and I'm certain that the main cause is the Stream
s we use throughout the app, like the player.playingStream
. Adding a value to the stream causes a new in awaited future to be spawned that calls the listeners, which can cause the listeners to run after a test has completed.
This is obviously not good even if we remove the singletons, because it means that tests potentially don't use the fake clock and test specific device configurations (e.g. if we ever want to add a test for landscape mode).
I found binding.pumpEventQueue
which does work and runs all stream listeners, but it also causes some tests to run forever and never finish, so I'm still investigating that.
https://github.com/nt4f04uNd/sweyer/actions/runs/11412091655/job/31757501525?pr=161
Possible solution https://github.com/nt4f04uNd/sweyer/pull/161#issuecomment-2423351681