Separately instantiable (in case used by dependencies)

[amitshekhariitbhu]

Separately instantiable (in case used by dependencies)

[paulpv]

FYI, this is another example of how singletons can be evil [most of the time?].
A singleton backed by a separately instantiable class is not necessarily evil and may make for a great design choice and is implicitly ready to handle the use case of multiple instances should the need arise.
A singleton backed by a non-separately instantiable class has limited use and could be very difficult to refactor if needed to support conflicting configurations/state.

[amitshekhariitbhu]

@paulpv : Thanks for sharing your knowledge and pointing out the bug. It is indeed insightful. I got your point and logic that you explained above. So I have planned it to refactor it as soon as possible.

Thank You
Amit Shekhar

[amitshekhariitbhu]

We will correct and push it in upcoming release.

[paulpv]

FWIW, a better OO model in my libraries on my side allows me to define the OkHttpClient and any other configuration in my main app and pass it in to AndroidNetworking.initialize(...), but I would still be at the mercy of any other libraries that may use AN playing nicely and accepting the same parameter and either not malfunctioning w/ my configuration or them not overwriting my configuration.
Such tangled webs all of these dependencies can weave!
Thanks for looking in to this!