SynQApp / Extension

Your music companion for the web, with a portable mini player and the ability to listen to any music link on your preferred service!
https://www.synqapp.io
Apache License 2.0
24 stars 2 forks source link

Implemented SpotifyObserverEmitter and refactored a couple things #9

Closed tekkeon closed 1 year ago

tekkeon commented 1 year ago

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 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.