Support for Artwork

[andersonaddo]

Heya!

Thanks for this great package. I was looking though, and I noticed that it doesn't have any support for artwork at the moment.

I was looking into this, and I noticed that the Android SDK and iOS SDK handle artwork pretty differently (is this why you didn't bother implementing it? understandable, if so).

For Android, it's a simple field, and it is available for only tracks.

For iOS, it is also only available for tracks. You have to use a getter that accepts an interface that only tracks seem to implement. Example.

I'm just wondering if you still plan on working on this eventually. It's no biggie if you aren't, since people can just revert to using something like this package.

The way I imagined this is making it a promise that resolves immediately for Android bur is actually async for ios (since it actually has to do fetching).

[cjam]

hey @andersonaddo sorry for the delay.

Yea, I didn't get around to implementing this as there were differences between iOS and Android and I figured I'd wait til enough people wanted the feature to add it.

It was pretty straightforward using artwork via URL's instead of artwork exposed by these underlying libraries. But I believe to do this, you need to also use the web api (which is also fairly straightforward to do once you have the token acquired via this library).

But yea, haven't put in the effort to add the native support provided by the underlying spotify libs.

[andersonaddo]

That's fair. Yeah, I took the same approach: I just took the node port of the Spotify API, directly fed it the access token gotten from this package, and queried that port for the image urls.

Overall it was pretty straightforward like you mentioned, but I just wanted to open up this discussion anyways :)

[cjam]

Yea, I think it would be awesome for offline type environments. However, there are quite issues with the underlying SDK that I think would prevent success in an offline scenario at the moment. But yea, good to open the discussion about it.