Web-API Async Implementation about spotifyapi-net HOT 14 CLOSED

I thought of it a while ago, but couldn't figure out a nice and clean way of implementing it without writing every method twice. I'm open for implementation-ideas! 😃

from spotifyapi-net.

😄

I doubt there is a way with only one method.

I believe there will be 2 ways of going into it.

• Extend the IClient with async methods and double each method in the SpotifyWebAPI.cs and SpotifyWebClient.cs and make them async.
• Make IClient SpotifyWebAPI.cs SpotifyWebClient.cs > IClientAsync SpotifyWebAPIAsync.cs SpotifyWebClientAsync.cs

The first way is probably the best approach, so there can always be chosen to use a normal or a async method in the same instance.

It will be a bit of work of coarse, but i think if this is added to the library - this could be the best spotify library out 🌟

from spotifyapi-net.

@JimmyAppelt
First method looks good, some expansions:

I will add another internal class (something like SpotifyWebAPIBuilder), which will build the URLs and check all the Inputs. Something like this:

public SearchItem SearchItems(String q, SearchType type, int limit = 20, int offset = 0, String market = "")
{
    return DownloadData<SearchItem>(_builder.SearchItems(q, type, limit, offset, market));
}
public async Task<SearchItem> SearchItemsAsync(String q, SearchType type, int limit = 20, int offset = 0, String market = "")
{
    return await DownloadDataAsync<SearchItem>(_builder.SearchItems(q, type, limit, offset, market));
}

Thoughts @JimmyAppelt ?

from spotifyapi-net.

Our bible is to make code as much maintainable as possible and avoid duplication of code.

So yes that would be the best approach. It will make the code for some peeps more complex.

Could there be a problem with only providing async methods ? This will be the easiest, less work, and easiest to maintain.

from spotifyapi-net.

@JimmyAppelt
Mh, no, two reasons:

1. I still want to support both types. Some developers like async, some not. And personally, I prefer the Sync-way.
2. I don't want to release another big breaking change that quickly. That would require all developers to adjust their projects again.

It will make the code for some peeps more complex.

What do you mean with that exactly? There won't be any change for API-Users, just for the API-Developers.

from spotifyapi-net.

@JohnnyCrazy

It will make the code for some peeps more complex.

For the API-Devs as you say 😉

Duplicating every method with a _builder is the most effective thing to do, because you are right. otherwise it will break currently running apps using the API.

from spotifyapi-net.

Implemented async-structure in 0dd94ea (web-async-branch)
Now, we/me just need to convert all methods. Maybe I will have some free time in the next days.

I'm open for PRs 😄

And BTW, with this approach we also get a new Feature! People can now easily build API-URLs themselves.

from spotifyapi-net.

Ah great @JohnnyCrazy I'l PR the async methods - then you can work on the stringbuilder if thats fine for you.

from spotifyapi-net.

So this is how you would like it @JohnnyCrazy 0dd94ea ?

from spotifyapi-net.

@JohnnyCrazy i'm not sure if the _builder is always implemented as you would like (as i said makes it more complicated.

from spotifyapi-net.

@JimmyAppelt Uhm yea, but SearchItems needs to be replaced with the specific method-name like GetAlbumTracks. Maybe I have time to make/push the builder methods later this day

from spotifyapi-net.

@JohnnyCrazy ah yes that would make sence

from spotifyapi-net.

@JohnnyCrazy this should be better 9bb25a8 👍

from spotifyapi-net.

Merged webapi-async, Release should be out soon

from spotifyapi-net.