[V4] Développement service Spotify

Hello, je viens tout juste de commencer le développement un module Spotify pour la v4, afin de gérer le multiroom de la maison.

L’idée est de pouvoir contrôler sa musique sur n’importe quel appareil connecté à Spotify connect

Pour cela, j’ai une question technique, et une question UX :

Technique :
Est ce qu’il y a un système de CRON intégré dans la v4 ? (j’ai lu quelque part qu’il y en avait un dans la v3)

  1. Un système de cron est déjà développé dans la v4, et dans ce cas la, je veux bien un coup de pouce car je ne l’ai pas trouvé dans le code
  2. Un système est prévu, mais pas encore développé, et dans ce cas la, je peux faire un controller sur l’API et un CRON système le temps du développement
  3. C’est pas prévu, et dans ce cas la, je suis un peu bloqué car la solution 2 est juste temporaire, dans le sens ou je me vois mal demander à l’utilisateur qui se servira de ce module de faire une tache CRON système (même si c’est juste une ligne de commande, ça me parait impensable que l’utilisateur ait a le faire manuellement)

UX :
Suite à ma réflexion sur la mutualisation des boxs du dashboard par besoin dans le topic sur le service Navitia (https://community.gladysassistant.com/t/module-navitia-calcul-ditineraire/4773/12?u=jacky), je me dis qu’il serait bien de prévoir une box musique qui serait la même quel que soit le service utilisé (spotify, deezer, itunes, MPD, etc).

Dois je prévoir le même système que proposé ds le topic Navitia (c’est à dire des services back différents et distincts, mais une box dashboard commune), en prenant en compte que le multiroom serait donc une option à activer car pas forcement disponible sur les autres services ?
Ou dois je faire différemment ?

Moi, dans tous les cas, je ne développerai que pour Spotify (je n’utilise que ça), mais je peux prévoir un front ready pour d’autres solutions. Par contre, il faudrait vraiment que d’autres services soient intégrés par la suite, car outre le fait que ça me fait une charge de taff supplémentaire non négligeable, ça compliquerait également l’UX et la configuration utilisateur pour rien.

3 Likes

Hello! Super pour le service Spotify!

Pour l’instant il y a un système de tache à interval mais pas de type cron, juste tu spécifie une fréquence et la fonction est appelé toutes les X secondes.

Quel est ton cas d’usage exactement?

Rafraichir un token d’accès en requestant l’api Spotify toutes les 29 minutes (en background)

Comment marche le système de tache ?

Je ne te conseillerais pas de faire comme ça si c’est juste pour rafraîchir des token d’API!

Dans ta méthode ou tu appelle Spotify, fais une fonction qui appelle Spotify avec le dernier access token connu, si Spotify te renvoie ok tant mieux, sinon rafraîchi le token et retente l’appel!

Ca risque de faire beaucoup d’appel sinon même quand l’utilisateur n’utilise pas Spotify non?

En fait, le système de tokens Spotify est assez spécifique (par mesure de sécurité).

Pour faire simple, il faut requester un token d’accès a Spotify, qui n’est valable qu’une heure, en utilisant 2 autres tokens (fixes, a durée illimitée). C’est seulement ce token d’accès qui permet d’accéder a l’api Spotify.

Le hic, c’est qu’a la génération du token d’accès, Spotify lance une page web pour demander une validation manuelle auprès de l’utilisateur (donc non automatisable en background), le seul moyen de s’affranchir de cette page, est de rafraichir le token d’accès a partir d’un token valide (donc au maximum toutes les 60 min).

Ainsi seule la première génération du token d’accès demandera une action manuelle de validation de l’utilisateur (ce qui serait acceptable, vu que ce serait a l’activation du service).

Il est donc impossible (niveau UX, pas technique) de demander une validation manuelle de l’utilisateur sur une page Spotify a chaque utilisation du module, c’est hyper lourd et pas intuitif, et incompatible (cette fois techniquement) avec des requêtes vocales, nfc, etc…

Rafraichir le token d’accès automatiquement toutes les X minutes est la solution préconisée par Spotify, et celle utilisée par tous les services requestant l’API (c’était également le cas sur le module de la V3 par exemple)

D’où mon besoin de lancer cette commande toutes les 29 minutes (je n’ai pas vu de système de retry non plus ds la v4, ça permettrait donc de requester 2 fois un nouveau token dans le temps imparti, si pour une raison ou une autre, une regénération échoue)

Source : Authorization Guide | Spotify for Developers

1 Like

J’ai suivi ton lien et ça me semble être un Oauth 2.0 des plus classiques!

J’ai peut être mal cherché sur la page, mais je ne trouve pas l’endroit où ils préconisent de rafraîchir l’access_token en permanence même quand Spotify n’est pas utilisé?

Qu’est ce que tu n’aime pas dans la solution de faire un fallback sur le get d’un access token lorsque l’access token n’est plus valide?

La génération d’un access token ouvre une page web demandant a l’utilisateur de se logguer et de valider l’utilisation d’un service tiers.

C’est impensable de demander a l’utilisateur ces actions manuelles a chaque fois qu’il veut utiliser le service depuis le dashboard (sans compter, que c’est impossible en utilisant des commandes automatisées)

On le voit bien sur le premier schéma du lien que j’ai donné, le user doit “log in, authorize access”

Bref, la question n’est pas vraiment de savoir comment utiliser l’api de spotify, mais vraiment de savoir comment faire une tache cron (ou équivalent) dans la v4.

On s’est pas compris :stuck_out_tongue:

Lorsque tu fais un flow d’Oauth, il y a effectivement une première étape où tu redirige l’utilisateur vers le tiers pour récupérer le refresh token et l’access token. Une fois suffit!

Moi je te parle juste d’au lieu de faire une requête pour récupérer un nouvel access token toutes les 30 minutes (est-ce qu’on veut vraiment appeler Spotify toutes les 30 minutes de l’année, alors que l’utilisateur n’utilise Spotify que 1% du temps?)

Juste au moment ou l’utilisateur a besoin de Spotify, là on peut utiliser le refresh token si l’access token est périmé, ou si non utiliser directement l’access token. Je ne comprend juste pas pourquoi tu veux faire un tache récurrente qui tourne tout le temps, et pas juste faire la requête à la demande de l’utilisateur?

Ok, c’est ma faute, j’avais mal comprit ^^

Effectivement, ça semble marcher de cette manière.

Merci )

Hello a tous,

Je suis actuellement sur le design et l’UX du dashboard spotify.

Entre ces 3 propositions, laquelle vous semble la plus pertinente ?

Proposition 1 :

Proposition 2 :

Proposition 3 :

PS: a noter que ces propositions ne sont pour l’instant que des bases de travail, il y a encore pas mal d’optimisations a faire sur chacun d’entre elle.

4e proposition (ma préférée, je pense partir la dessus)

A noter que les 3 icônes de gauche représentent

  1. Shuffle
  2. Repeat all
  3. Repeat one

L’icône en haut a droite représente spotify connect, et le choix du device sur lequel jouer la musique.

Je ne sais pas encore vraiment comment afficher la liste des devices pour selection (niveau UX).
Je ne suis pas très fan de faire une modale, mais ce serait peut être le plus pratique (une petite située sous l’icône, de la taille de l’affichage des devices)
Sinon un encart qui s’afficherait en dessous du player (ou au dessus de l’image), mais on peut vite avoir pas mal de devices (tous les alexa, les tv connectées, nvidia shield, téléphones, etc) chez soi, et je pense que visuellement, ça ne ressemblerait à rien… un champs input stylisé serait le moins pire, mais je suis franchement pas convaincu, surtout que l’idée est quand même de garder cet encart le moins grand possible en hauteur

Bref, si quelqu’un a une idée, je suis preneur ^^

2 Likes

Même si pour l’instant je n’utilise pas ce service, je trouve la box 4 sympa.
Pour le choix des devices, imaginons que je veux écouter de la musique dans mon salon et ma compagne autre chose dans la salle de bain, c’est possible?

Salut top !!!

Super service spotify.

Pour la question du modal tu peux très bien l’intégrer dans la vue directement de spotify du dashboard, tu transformes la page où on voit la jacket par le contenu que tu veux mette du modal

Hello @Jacky! J’aime bien la proposition 4 aussi :slight_smile:

Juste pour qu’on se coordonne, j’ai bossé l’autre jour avec @Nilkone sur le service Sonos (donc un service de music aussi)

Dans Gladys la gestion de la musique est centralisée et l’API est standard, donc à mon avis ta box peut être la box officielle générique pour gérer la musique (aussi bien Sonos que Spotify)

Les premiers pocs de développement qu’on a fait sont ici => [WIP] Add Sonos Service by Pierre-Gilles · Pull Request #516 · GladysAssistant/Gladys · GitHub

C’est très loin d’être prêt, c’était vraiment des tests en réel pour l’instant, mais ça peut te donner une idée de ce que j’ai en tête.

Une proposition un mélange des versions
Un menu pour le choix de lecture (Repeat All, Repeat Once, Lecture All)

3 Likes

Il est vrai que les boutons

  • Shuffle
  • Repeat all
  • Repeat one
    sont moins utilisés donc pas nécessaire qu’ils soient affichés en permanence.

Merci pour les retours )

Pas avec Spotify, le service n’accepte qu’un seul device a la fois.
Peut être avec Sonos, mais n’en n’ayant pas, je ne suis pas sur.

Yes, c’est ce que je proposais dans mon premier message sur ce thread.
J’ai regarde ta PR, j’aurais des modifs a faire cote back, je verrai ca une fois que les fonctionnalites et le dashboard seront faits.

Top, je pars sur cette base, et je modifierai selon les besoins

En faire une box générique peut être bien sympa oué, mais est-ce qu’on pourra utiliser Spotify et sonos en même temps ? Par exemple dire à gladys de jouer une Playlist local avec sonos dans la chambre 1 et aussi lancer une Playlist Spotify dans la cuisine.

Sinon je préfère aussi la 4 @Jacky, super job au passage :+1:

Ça devrait être possible, je ne vois pas vraiment d’obstacle technique à ce cas d’usage.

Faudra juste qu’on bosse sur la partie UX pour que ce ne soit pas trop complexe de switcher entre Sonos et Spotify

1 Like

tu fais du boulot @luke :+1: