Caching

[joeydotdev]

Has there been any discussions on introducing a caching layer internally within the library that saves the network responses of infrequently updated entities (Artist, Album, Track resources specifically)?

An example where this would be useful is when requesting a Playlist entity that contains an array of PlaylistTrack. Each PlaylistTrack only contains an ArtistSimplified entity. The only way that I can get an artist's image is by creating a full Artist API call with the simplified artist's ID which currently always dispatches a network request.

If I have an array of N playlist items that all have the same artist (and depending on how I implement it), I could be sending N network requests.

I have some logic to optimize the network calls within my own code but there isn't a strong reason on why this logic should be living with my app and not the library IMO.

[stijnvdkolk]

As far as I know, we did not have any discussions about this internally. In my opinion, this is indeed something we could look into researching. @stingalleman, your opinion?

[stingalleman]

Hi, I have given this a thought before, especially because of the high usage from StatsFM, but I've decided to keep this library stupid simple. Working with other libraries always was a pain in the ass due to useless gimmicks (not that caching is useless) or due to it being hard (or impossible) to use. I'm afraid that adding features like this will be a cause for bugs etc. Maybe you could make a separate extension to this library? We could look into that.

Thanks!