Repository navigation
Replace the in-house HTTP client with a famous external library #209
Description
The Runtime provides code for handling HTTP requests but the scenarios covered are very simple ones. The more apps are written, the more problems arise - for example issues #195 & #194. Instead of investing in writing our own code (a.k.a "inventing the wheel"), we may reuse some well-tested and adopted third-party library such as OKHttp.
Activity
atanasovg commentedon Oct 1, 2015
There is a simple workaround for #194 & #195. We will postpone the integration of the library for now.
alexrainman commentedon Oct 12, 2015
I was wondering and this thread seems to confirm that you are planning to use OkHttp and that's awesome. OkHttp is way faster and it's the counterpart of NSUrlSession.
alexrainman commentedon Sep 29, 2016
I know the OkHttp plugin already exists but, any news when the library will be integrated in the core?
slavchev commentedon Oct 11, 2016
This is issue is not relevant anymore because the previous HTTP implementation is moved from the runtime to the project template.
@alexrainman The were indeed plans to provide JavaScript/TypeScript wrapper around OkHttp but so far I cannot confirm if it will be executed. To give you more context - we had plans to provide a plugin for OkHttp and it seemed like a good addition to our core modules. Implementing this functionality in the runtime doesn't seem right. Before closing this issue I would like to hear more about your scenarios. Also we can continue the conversation in NativeScript/issues if you prefer.
alexrainman commentedon Oct 11, 2016
@slavchev im going to do some testing to confirm your http module for android is compatible with MobileIron vpn tunneling. Also okhttp is faster. Thanks
slavchev commentedon Oct 11, 2016
@alexrainman If I may save you time I am sure you will definitely find OkHttp much faster and functionality rich. The current http implementation was provided to bootstrap our core modules so people can handle simple request/response scenarios. I think OkHttp is the way to go especially if you have more complex scenarios.
alexrainman commentedon Oct 11, 2016
@slavchev yes but then i will have platform specific http related code because okhttp doesnt override your android implementation when you install the plugin. That could be the solution. Once you install okhttp plugin, make it the default http message handler. Can that be done? Thanks
slavchev commentedon Oct 11, 2016
I agree.
AFAIK this is not supported at the moment. However we can think how to make our modules more extendable starting with the
httpmodule. If we go this way we have to think how we are going the provide the same functionality for iOS because the core modules are platform agnostic. Providing Android specific OkHttp plugin is also an option as it will solve real problems. With that in mind I would suggest to create a new issue in core modules where it will have better visibility.Plamen5kov commentedon Dec 7, 2016
Close because: "This is issue is not relevant anymore because the previous HTTP implementation is moved from the runtime to the project template."