VolleyNetworkStack : why RequestQueue requestQueue is static ? about wasp HOT 6 CLOSED

I think it would be great to have just one service and make it as much dynamic as possible. Probably we can consider adding the trusting certificate logic using annotations. What do you think?
When do you think having more than one service can make sense apart from this certificate example you pointed out?

from wasp.

I think there is no harm to make it non-static, that's totally valid and RequestQueue is not so expensive in the terms of cost. I'm also wondering why we added static there at the first place. Need to check though, but so far seems there is no advantage of having static.

But as @AlexBalo said, we really want to stick just one interface to handle everything and make things easier. That's why we introduced annotation solutions to avoid having 2 different services. At least so far, we managed to not needing the second one.

Apart from that, with wasp, different endpoint can be added to specific request calls. If we provide a certificate for that as well, there will be no need to another service.

By looking the code, I think we also need to consider check the context and use the only applicationContext(), if the context comes from the activity, we would have a strong reference and prevent GC apparently.

And for the getting requestQueue, we should also consider synchronization.

from wasp.

Let say that i have 100 request to make, 50 on api A and 50 on api B, i should annotate 50 time the method for api B !
And for exemple for api if both api A and B need Authorization, how do you manage different RequestInterceptor per apis?
In my mind, as soon i have to connect to different apis i should have a different service.

from wasp.

@adrienleroy In the next release, we will remove the static declaration.

from wasp.

@adrienleroy yes, sure I agree with what you said. Logically makes more sense to have different services if you are connecting to different apis for example.

from wasp.

This is fixed, (v1.5)

from wasp.