I don't understand. Why not just supply your own CookieStore -- why
rewrite so much? http://bit.ly/cymmRg
I don't recall having used this -- when I last used HttpClient, I
didn't have any need to share cookies. So maybe I'm missing some
problem.
HttpClient is complex because HTTP is complex. I'm sure you only
handle a small subset of everything that's in the HTTP 1.1 spec.
If you have control over the server side as well as the client, or
only need a very limited set of functionality, that's fine. Simple
uses of HTTP are quite simple.
However, if you're making a reusable framework you not only need to
handle the full range of the spec -- you also need to give the user
the flexibility to configure and modify its behavior.
That's why there's stuff like setCookieStore(), and a similar stack of
configurable processors to what you'd find in a HTTP server such as
Tomcat or Jetty.
BTW, my preference would be to separate content handling from HTTP
access. Content handlers are useful in other circumstances, too. I bet
you actually made your content handling system separate, and made your
top HTTP layer use it. But you could get the same synergy with
HttpClient.
In fact, Content Handlers are so useful, that the Java library already
defines the java.net.ContentHandler interface.
So why did you drop all the way down to java.net.Socket, rather than
using java.net.HttpURLConnection, which already integrates with
content handling, handles the HTTP and HTTPS protocols, AND provides a
way to set the cookie handling? It sounds like you've pretty much
duplicated its functionality.
You can even write one-liners:
new URL("http://www.example.com/myresource";).getContent();
On Jan 28, 1:28 pm, Jason Proctor <jason.android.li...@gmail.com>
wrote:
> the main HttpClient showstopper for me was its buggy cookie
> implementation - i needed to share cookies between WebKit and
> HttpClient, and HttpClient wouldn't play nice. however, i also
> thought the API was awkward to use. last thing, i took a look at the
> code. someone really managed to turn something relatively simple into
> a gothic monstrosity.
>
> so i wrote my own (simple) HTTP implementation on top of
> java.net.Socket. it's very simple and doesn't support any fruity
> options, but it integrates with my progress reporting system, and
> automatically shares cookies with WebKit. it has a pluggable content
> handler system so you can easily get binary, JSON, strings, etc, from
> resources with one line of code.
>
> my apps now depend on it -- i use it from within AsyncTasks all the
> damn time and it's solid.
>
>
>
>
>
> >Jason,
>
> >Rolled your own? Can you share/elaborate? There seems to be other
> >issues with HttpClient. I am looking at either integrating
> >Jersey/JAX-B client side to send REST calls (my server side is all
> >Jersey/JEE6/JAXB based), but if that is too bulky for the app, then
> >I was looking at using URLConnection.. but I haven't tried using
> >that for REST calls with Basic Auth, various headers, xml/json body,
> >etc.
>
> >On Thu, Jan 28, 2010 at 1:01 PM, Jason Proctor
> ><<mailto:jason.android.li...@gmail.com>jason.android.li...@gmail.com>
> >wrote:
>
> >i hope not, because the code makes a new HttpClient instance per
> >ArtRetrievalTask. i suppose it could be trying to be clever,
> >realising that the requests are going to the same place, and
> >utilising HTTP 1.1 to bundle the requests into the same connection.
>
> >if that's really what's happening (and i suspect not, somehow), and
> >maybe only the server logs can tell for sure, then i hereby state
> >for the 67th time how happy i am that i dumped HttpClient and rolled
> >my own HTTP.
>
> >Perhaps the requests are being serialized by HttpClient? I wonder if
> >there's a way to determine the actual thread a particular
> >AsyncTask's doInBacground process runs on, like maybe a thread id?
>
> >--
> >You received this message because you are subscribed to the Google
> >Groups "Android Developers" group.
> >To post to this group, send email to
> ><mailto:android-developers@googlegroups.com>android-develop...@googlegroup
> >s.com
> >To unsubscribe from this group, send email to
> ><mailto:android-developers%2bunsubscr...@googlegroups.com>android-develope
> >rs+unsubscr...@googlegroups.com
> >For more options, visit this group at
>
> ><<http://groups.google.com/group/android-developers?hl=en>http://groups.google.com/group/android-developers?hl=en><http://groups.google.com/group/android-developers?hl=en>http://groups.google.com/group/android-developers?hl=en
>
> >--
> >jason.vp.engineering.particle
>
> >--
> >You received this message because you are subscribed to the Google
> >Groups "Android Developers" group.
> >To post to this group, send email to
> ><mailto:android-developers@googlegroups.com>android-develop...@googlegroup
> >s.com
> >To unsubscribe from this group, send email to
> ><mailto:android-developers%2bunsubscr...@googlegroups.com>android-develope
> >rs+unsubscr...@googlegroups.com
> >For more options, visit this group at
> ><http://groups.google.com/group/android-developers?hl=en>http://groups.google.com/group/android-developers?hl=en
>
> >--
> >You received this message because you are subscribed to the Google
> >Groups "Android Developers" group.
> >To post to this group, send email to android-developers@googlegroups.com
> >To unsubscribe from this group, send email to
> >android-developers+unsubscr...@googlegroups.com
> >For more options, visit this group at
> ><http://groups.google.com/group/android-developers?hl=en>http://groups.google.com/group/android-developers?hl=en
>
> --
> jason.vp.engineering.particle
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
