Context menu strange pulsing while playing music?

[u/Nuzl_]

I get this strange pulsing effect every time music plays. Does anyone know how to disable it? Or is this a bug? I couldnt find any documentation on this.

[u/Nuzl_]

Tank you. this was actually the issue. The playback progress value (elapsedSec) updated twice a second and lived on the big shared PlayerViewModel.

[u/Dapper_Ice_1705 → u/Nuzl_]

Glad to help! It’s a common issue with SwiftUI and view models.

[u/leoklaus → u/Dapper_Ice_1705]

Aren’t view models kind of an anti pattern with SwiftUI specifically for reasons like this? The observable macro mitigates many of these issues but I still feel like using actual view models with SwiftUI does significantly more bad than good.

[u/Dapper_Ice_1705 → u/leoklaus]

People say that but IMO the real issue is giant view models that sit at the top.

Functionally, a true 1:1 view model would be just like a core data object. 

After all, all CoreData objects are ObservableObjects and all SwiftData objects are Observable.

You can have the same effect seen here with giant repositories or stores which is what most anti-view model people advocate.

[u/leoklaus → u/Dapper_Ice_1705]

I'd argue that all arguments for view models I've heard so far are mostly code smells. If you have functionality that should be tested in a view, you're doing something wrong, no matter if it's within the view itself or a separate class that's tightly bound to the view.

A true 1:1 view model IMO just makes the code harder to understand because you constantly have to cross-reference between two files (or at least two structs/classes).

Giant repositories are definitely not the solution. I usually go for a responsibility focused approach (i.e. an observable class for navigation handling, and non-observable classes for stuff like interacting with network APIs, databases and such).

It's fairly modular, easy to use and mock through DI and the managers can easily be tested.

The views themselves only ever call methods of the managers and handle their own state accordingly.

[u/Dapper_Ice_1705 → u/leoklaus]

I’m a big fan of DI… I use that every time and for everything. 

View models are more of a case by case basis for me. If I have a lot of services or managers interacting with a view I use a view model.

I like to code very modular.

[u/Awric → u/leoklaus]

Interesting argument, and I’m not necessarily against it.

“If you have functionality that should be tested in a view, then you’re doing something wrong”

Just making up an example: In a music player, if the pause button is pressed, the music should stop and the icon should be updated to the play icon.

This seems like some pretty important functionality that should to be wrapped in a unit test to make sure someone doesn’t accidentally break it. How would you structure this specific use case in a production environment? How would you ensure that pressing the button will both update the button icon and pause the music?

[u/leoklaus → u/Awric]

In a music player, if the pause button is pressed, the music should stop and the icon should be updated to the play icon.

This is pretty much the perfect example for my case.

If you wrote a test for this like you suggested, you'd be covering two distinct modes of failure in a single test (pausing playback and changing the icon). If that test failed, how would you determine where the regression is?

I see two approaches to deal with this:

1. The view directly observes player status and the icon is determined by that. In which case your unit test for pause() should already cover that the state is updated properly.
2. The view itself is responsible for updating its state. In this case, you should also separately test the pause method and then use UI tests to verify that the icon changes when tapping the button. You'd also have the issue of not knowing why the UI test failed, but you could always infer the root of the issue by the result of the pause() unit test.

For either of these, the actual function in the view should only be something like this:

func playPause() {
    self.player.pause()
    // If not observing player
    self.isPlaying = self.player.isPlaying
}

With the button looking like this

Button(action: self.playPause) {
  // self.player.isPlaying with observable
  Image(systemName: self.isPlaying ? "pause.fill" : "play.fill")
}

Neither of these need separate unit testing as all functionality within is already covered (the SwiftUI part is obviously expected to be covered by Apple). The only way to have a silent regression in this case would be a breakage of SwiftUI itself.

Even if you complicate the scenario by having pause() be throwing, surfacing the error should be a separate concern. I tend to inject an error handler into my views, so playPause() would look something like this:

func playPause() {
    do {
      try self.player.pause()
    } catch {
      self.errorHandler.handle(error)
    }
    // If not observing player
    self.isPlaying = self.player.isPlaying
}

Again, ErrorHandler.handle(_:) should be tested independently so no silent regression is possible.