There are several top-level changes in this PR all related to implementing the SpotifyObserverEmitter, which is responsible for observing changes to the state of Spotify and emitting events for the rest of the SynQ application to react to.
SpotifyObserverEmitter Implementation
Exclusively used MutationObservers for monitoring Spotify application state changes. Unfortunately, I have found no other way to tap into the state of the application beyond using the API, but polling the API for changes too frequently may draw unwanted attention to SynQ - we want to be good API citizens.
PlayerState Updates
Split out the SongInfo from the PlayerState because they're different enough in both implementation and usage to warrant being separate. Updated the model and the IController interface (which now has getPlayerState and getCurrentSongInfo instead) and modified the implementations of these for each of the services to match the new interfaces.
SpotifyController.getPlayerState Implementation
SpotifyController.getPlayerState previously used the Spotify API to get the player state. This would have been called at least once per second with the new SpotifyObserverEmitter, plus every increment of the volume change, etc. It was also somewhat slow considering that all of the info was immediately available on the UI without an API call. With that, it made sense to change this implementation to just scrape the UI for the data rather than make noisy API calls.
QUEUE_UPDATED Event Removal
After realizing the it's tough to monitor the queue and only possible with intervals in both Spotify and Amazon Music, plus Spotify's would require more noisy API calls, I considered whether we even need this, and realized we don't. The reason to have it would have been because the user may have the SynQ popup open and the queue changes on the service UI so we want the mini player to reflect that. However, the queue can only really change when the user interacts with the music service, and doing that automatically closes the SynQ popup anyway. So we only need to get the queue when the popup first opens and don't need events to continually update the mini player.
Overview
There are several top-level changes in this PR all related to implementing the
SpotifyObserverEmitter
, which is responsible for observing changes to the state of Spotify and emitting events for the rest of the SynQ application to react to.SpotifyObserverEmitter
ImplementationExclusively used
MutationObserver
s for monitoring Spotify application state changes. Unfortunately, I have found no other way to tap into the state of the application beyond using the API, but polling the API for changes too frequently may draw unwanted attention to SynQ - we want to be good API citizens.PlayerState
UpdatesSplit out the
SongInfo
from thePlayerState
because they're different enough in both implementation and usage to warrant being separate. Updated the model and theIController
interface (which now hasgetPlayerState
andgetCurrentSongInfo
instead) and modified the implementations of these for each of the services to match the new interfaces.SpotifyController.getPlayerState
ImplementationSpotifyController.getPlayerState
previously used the Spotify API to get the player state. This would have been called at least once per second with the newSpotifyObserverEmitter
, plus every increment of the volume change, etc. It was also somewhat slow considering that all of the info was immediately available on the UI without an API call. With that, it made sense to change this implementation to just scrape the UI for the data rather than make noisy API calls.QUEUE_UPDATED
Event RemovalAfter realizing the it's tough to monitor the queue and only possible with intervals in both Spotify and Amazon Music, plus Spotify's would require more noisy API calls, I considered whether we even need this, and realized we don't. The reason to have it would have been because the user may have the SynQ popup open and the queue changes on the service UI so we want the mini player to reflect that. However, the queue can only really change when the user interacts with the music service, and doing that automatically closes the SynQ popup anyway. So we only need to get the queue when the popup first opens and don't need events to continually update the mini player.