Closed T-vK closed 3 months ago
Thanks for the quick reply! That sounds great! :)
One more thing I would like to see, is support for /get-audio-analysis. The responses can be like 400kB in size though so it could easily be too much for an ESP. Do you think we could add support for ArduinoJson's filter? That combined with using the response streams instead of strings, would allow us to only use minimal amounts of memory. For example if I just need meta.timestamp
, beats
and bars
from the response, it would be awesome if I could pass a filter like:
JsonDocument filter;
filter["meta"]["timestamp"] = true;
filter["beats"] = true;
filter["bars"] = true;
String trackId = "11dFghVXANMlKmJXsNCbNl";
response data = sp.get_audio_analysis(trackId, DeserializationOption::Filter(filter));
It seems that currently the String interface is used:
DeserializationError deserializeJson(JsonDocument& doc, const String& input);
String means that we load the entire response body into memory before parsing it. Using the Stream interface would allow to parse the response while it is getting received, only storing the required properties in memory. Meaning much lower memory consumption when used with filter.
DeserializationError deserializeJson(JsonDocument& doc, Stream& input);
Will have to look into that, but sure should be possible, and sensefull, potentially for all get endpoints, will look to get the other things into version 1.1.x and this will then be in 1.2.x(probably out in 1-2 weeks) if you need it fast feel free to make a pull request and implement it as you like ill then look over it and merge it
I agree. It would probably make sense to allow a filter for all methods and pass it down to Spotify::RestApi
where it can be passed to deserializeJson
then. I'll try to implement it and keep you posted. If I succeed, I'll create a PR.
Switching from String to Stream might however require a more in-depth refactoring.
Perfect, otherwise ill try it then, one thing please keep the naming in style, so x_x etc.
Of course! :)
"Can't reuse existing HTTP server/client. WLED already has an HTTP server/client. It would make sense to be able to pass those to the SpotifyEsp32 constructor to save resources and avoid running servers on multiple ports." currently looking into that, what webserver does WLED use? the one from the WebServer.h lib i use too? As im not sure how i should handle the closing/the server.handleClient() command
WLED mostly uses ESPAsyncWebServer for receiving requests as a server. I also found references to AsyncJson which from my understanding provides a way of sending JSON responses, but I think it's probably not relevant for the integration of SpotifyEsp32.
Here's an example of how it's used and here's another one. The server is globally defined here.
I'll check with the people from WLED if there is also a standard/recommended way of how they send HTTP requests as a client.
Ok thanks, then ill leave that away for now as i use WebServer and the thing is if you save your tokens the webserver will only be used once and then not again, so its not that big big of a size issue i think.
Were you able to get anything done with filters? As i now have released version 1.1 which got some new features on how to login, so i could go on to work on that...
I have tried, but I haven't gotten far. It would probably take me another week or so to get it working. So if you have the time, go for it. I'm sure I'll find something else to contribute down the road. :)
No problem, ill try to do it, will dind out how long itll take me to do it as ive never used these features befor but will find it out:)
Hello and thanks for your great work on this library! :) I would like to use it in WLED (another open source project).
But I'm having a few issues:
http://{IP}/
is already reserved for the Web UI, so it can't be the Redirect URI. It would be nice to be able to specify a custom URL.What are your thoughts on that? :)