all valid points.
on the cookie issue i found that when i added WebKit cookies to the
Apache cookie store, they sometimes took effect immediately,
sometimes after a delay, and sometimes not at all. i don't know
offhand whether it's a problem with the CookieStore as such, or
whether the HttpCl
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
it belongs to my employer, so i can't. i would rewrite it at home and
share it, but really i'd rather work on music at home.
just take a day and do it yourself. it's not so bad. and you'll thank
yourself every day like i do :-)
Awesome.. share the code. :)
On Thu, Jan 28, 2010 at 1:28 PM
Hmm.. that would be good to know.
On Thu, Jan 28, 2010 at 1:41 PM, Biosopher wrote:
> Got an update here. The AsyncTask code above appears to run in
> parallel on a device. Maybe there's something non-parallel in the
> Emulator's version of AsyncTask?
>
> --
> You received this message because
Got an update here. The AsyncTask code above appears to run in
parallel on a device. Maybe there's something non-parallel in the
Emulator's version of AsyncTask?
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send
Awesome.. share the code. :)
On Thu, Jan 28, 2010 at 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. howeve
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 some
btw, i know this isn't directly connected to the issue at hand, but
i'd recommend closing the FileInputStream in a finally block so you
don't leak file descriptors.
Here's the code:
public class ProcessFiles extends AsyncTask {
protected Void doInBackground(Void unused) {
HttpClient doesn't serializing the requests from what I can tell.
Before switching to AsyncTask, I was using Threads and the http
requests were running in parallel. It's only since I switched to
AsyncTask that everything started running in parallel.
--
You received this message because you are s
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 URLConne
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
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
Here's the code:
public class ProcessFiles extends AsyncTask {
protected Void doInBackground(Void unused) {
File sdcard = new File("/sdcard");
for (int i = 0; i < sdcard.list().length; i++) {
File file = new File(sdcard,sdcard.list(
can you post the real code then? :-)
Hi Jason. Thanks for requesting the clarification. My code is
actually calling AsycnTask.execute(). I should have made that clearer
in my pseudo-code.
The description above shows all threaded portions of the app. I
stripped down to a basic test implemen
Hi Jason. Thanks for requesting the clarification. My code is
actually calling AsycnTask.execute(). I should have made that clearer
in my pseudo-code.
The description above shows all threaded portions of the app. I
stripped down to a basic test implementation to isolate the
multithreading for
call execute() to allow AsyncTask to properly schedule a call to your
doInBackground() in an appropriate thread.
calling doInBackground() yourself will just invoke the code you
intended to be run in the background thread all right, but it will do
it synchronously in your current thread.
or p
Thanks Streets. That appears to be the issue, however it's odd that
I'm hitting AsyncTask's thread pool limit so quickly with just 3 tasks
running. Looking at AsyncTask's code, I see these values:
private static final int CORE_POOL_SIZE = 1;
private static final int MAXIMUM_POOL_SIZE = 10;
Whil
AsyncTask is based upon the java.util.concurrent package's
ExecutorService and FutureTask classes.
When you create and execute an AsyncTask a thread is obtained from a
pool of threads (i don't know what the size of this pool is for
AsyncTasks) and your background process is executed on this thread
18 matches
Mail list logo
