There are a number of issues with Java's HttpUrlConnection that make it a less than ideal option compared to HttpClient. For example, HttpUrlConnection has no way to set default connection/socket timeouts - you have to call http://developer.android.com/reference/java/net/URLConnection.html#setConnectTimeout%28int%29 and http://developer.android.com/reference/java/net/URLConnection.html#setReadTimeout%28int%29 for every connection. This particular issue is a killer for me - and I only just started evaluating switching my apps to HttpUrlConnection.
There is precedent for Android "breaking" apps with upgrades - for example, https://code.google.com/p/android/issues/detail?id=15022 broke quite a few apps and annoyed more than a couple developers. In any case, I don't want to hijack this thread into a request for Android to upgrade HttpClient - I really just want to use HttpClient (and HttpClient-Cache) on Android. Since the org.apache.httpclient namespace is (probably) permanently taken with an outdated implementation, what can be done to allow Android developers to use HttpClient? Could there be releases, concurrent with the "normal" releases, of the org.apache.httpclient.* projects renamed to an alternative namespace? Of course, that means that non-httpclient projects would be broken, as they wouldn't change to use that alternative namespace, so developers wouldn't simply be able to drop in dependencies originally developed for non-Android targets. And if they did, they'd be in for a surprise when the dependency doesn't work due to VerifyError's or simply encountering runtime bugs that they "know" were fixed as they included a newer HttpClient dependency, but it's not actually used. IMHO, it seems that the Android decision to never change their bundled httpclient torpedos httpclient on Android forever - at least until Apache releases HttpClient 5 that uses a new namespace. Are there any other ideas on what can be done to remedy this situation? Thanks, ~Craig Jesse Wilson-4 wrote: > > Apache HTTP folks, > >> I have no problem with making httpclient-cache compatible with Android >> but at the same time I think users we should be encouraging Android >> users to migrate to the latest release of HttpClient nonetheless. > > I'm the > maintainer<http://android-developers.blogspot.com/2011/09/androids-http-clients.html>of > Android's HTTP clients. Android's non-adoption of new versions of > Apache > HTTP client is my decision, but it hasn't been an easy one. > > We made a mistake early on by exposing the full Apache HTTP client > API—including > impl<http://developer.android.com/reference/org/apache/http/impl/cookie/package-summary.html>packages > —in Android's API. This makes upgrading Apache HTTP client risky as I have > to avoid breaking applications. It also adds a burden on application > developers who would need to test their applications against multiple > releases of Apache HTTP client to support multiple releases of Android. > The > rich API means there's many moving parts to test. > > If I could put the genie back in the bottle I would not have exposed > Apache > HTTP as a public API in Android. It's a great API, but our including it > the > platform locks everyone into an old build that we grabbed back in 2008. > It's much simpler for developers to pick a single release, test it, and > bundle it. For this reason I recommend that developers looking for new > Apache HTTP features follow Oleg's advice and repackage Apache HTTP in > their application. > > Or use HttpURLConnection, which I've spent a lot of time on lately. > There's > even an HTTP response cache in Ice Cream Sandwich. > > Thanks Oleg & Apache HTTP client contributors. It's powerful software that > gets lots of exercise on Android. > > Thanks, > Jesse > > -- View this message in context: http://old.nabble.com/HttpClient-Cache-release-that-works-against-HttpClient-4.0--tp32775131p32805637.html Sent from the HttpClient-User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
