On Tue, 2014-01-28 at 11:49 +0000, sebb wrote: > On 28 January 2014 08:28, Oleg Kalnichevski <[email protected]> wrote:
... > One way is trial and error by source comparison. > It would be tedious. If Google took a formal release (rather than a > snapshot) then the process would be a lot quicker of course. > Tedious and almost useless given the net gain. ... > >> > If you are familiar with Spring, think of Spring Rest template. > >> > >> No, I'm afraid I have no experience of Spring. > >> > > > > I hope this will help you understand what I am trying to achieve and why > > it is important: > > > > http://docs.spring.io/spring-android/docs/1.0.1.RELEASE/api/org/springframework/http/client/HttpComponentsClientHttpRequestFactory.html#setHttpClient%28org.apache.http.client.HttpClient%29 > > I see. > Ah. > However, this will only work reliably if the application avoids using > any implementation classes that have been replaced in the new library. > Why? The new implementation honors the same contract by implementing the same interfaces and using the same API classes as the old version. As long as the application does not directly depend on the old DefaultHttpClient (in which case we cannot do much) but rather relies on HttpClient interface, the newer implementation can be used without any alternations. The whole is not to provide a drop-in replacement but a backward compatible alternative with fewer bugs and more features, which can be used with all those 3rd party libraries such as Spring for Android. > == > > The README talks about ensuring compatibility between Android and Java > applications by avoiding certain classes. > Maybe the original classes need to be tagged in some way in the Java > source so that people developing Java applications have advance > knowledge of which classes won't be available on Android. If the > tagging were done consistently, it could then potentially be used to > drive the "shading" process, avoiding the need to include magic > strings in the gradle script. > I really would not like to pollute the stock version of HttpClient with Android specific stuff, hence my intention to keep most of the migration logic in the script even at the price of having to employ some dark magic. This port is a stopgap solution until the next major release (which is still in some distant and uncertain future). It should eventually disappear. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
