Timing out an AsyncTask?

by HippoMan » Sat, 10 Apr 2010 01:50:49 GMT


Sponsored Links
 I know how to use AsyncTask in a standard manner to manage operations
that are in the background in relation to a UI thread.

However, I want to run a task in the background which might run for a
very long time under certain circumstances. In these cases, I would
like to force the background task to fail if it runs for an excessive
amount of time.

I know that I can invoke the "get(long timeout, TimeUnit unit)" method
of AsyncTask in my UI thread in order to terminate my background task
if it runs too long. However, in that case, my UI will block while
this "get()" command is waiting.

There are probably other drawbacks to directly calling "get()" in this
manner, not the least of which being an evil interaction with the
"done()" method of AsyncTask's contained FutureTask object, which
itself is calling "get()" -- at least this is what I see when I look
at the source code for AsyncTask.

So what is the canonical, Android-approved method for timing out an
overly-long-running AsyncTask?

Thanks in advance.




--



Timing out an AsyncTask?

by Romain Guy » Sat, 10 Apr 2010 01:58:07 GMT


 AsyncTask was not designed for long running operations and should
definitely not be used in the way you describe here. To cancel a task,
just invoke cancel().



>


Sponsored Links


Timing out an AsyncTask?

by HippoMan » Sat, 10 Apr 2010 02:16:38 GMT


 Of course I know about cancel(). When I mentioned the use of "get(long
timeout, TimeUnit unit)", I thought it would be obvious that I would
then invoke cancel() to terminate my overly-long-running task. But
then, my UI thread would block while I'm waiting, as I stated above,
which is not desirable. Nor is the fact that the done() method of
AsyncTask's contained FutureTask object also calls get().

I asked what is the Android-approved, canonical method for doing what
I want to do. Given that AsyncTask is not the intended mechanism for
invoking and optionally timing out a long-running task, what *is* the
recommended method for doing so in Android?

Thanks again, in advance.


--



Timing out an AsyncTask?

by Romain Guy » Sat, 10 Apr 2010 02:30:05 GMT


 You would be better off just creating your own thread and handling the
timeout inside it.



>



Timing out an AsyncTask?

by Frank Weiss » Sat, 10 Apr 2010 02:58:40 GMT


 Of the top of my head, set an alarm in the UI Activity to call cancel on the
AsyncTask.

--



Timing out an AsyncTask?

by HippoMan » Sat, 10 Apr 2010 02:59:16 GMT


 OK. Thank you.

So how do I interface to my UI from the new thread that I start? Once
the long-running task completes (assuming it finishes before my time-
out period), I want to notify my UI thread so it can take appropriate
action. If this was a short-running task, I could have easily used the
onPostExecute() method of AsyncTask for that purpose.

But when running my own thread, what is the recommended way in Android
to properly communicate the results of the task to the UI thread? I
can can think of several ways to do this, but I'm sure there is a
procedure for this which is consistent with Android "best practices".

Thanks again.

--



Timing out an AsyncTask?

by social hub » Sat, 10 Apr 2010 03:11:11 GMT


 There is something called Handler through which you can communicate with
your UI thread
 http://www.developer.com/java/j2me/article.php/10934_3762056_3/Handling-Lengthy-Operations-in-Googles-Android.htm 

hope this helps




>



Timing out an AsyncTask?

by HippoMan » Sat, 10 Apr 2010 03:15:14 GMT


 OK. I'm going to make a wild guess as to how I might do this. Could
someone comment on the reasonableness of this approach under
Android? ...

1. As part of my Activity class, define a message type called, for
example, MESSAGE_LONG_RUNNING_TASK_RESULT.
2. As part of my Activity class, define a message handler which
responds to MESSAGE_LONG_RUNNING_TASK_RESULT.
3. Start a new thread. For the purpose of this discussion, call it
"ControllerThread".
4. Inside the run() method of ControllerThread, create a FutureTask
which invokes my long-running process.
5. Instantiate and invoke my FutureTask within ControllerThread and
then wait for its results via "get(long timeout, TimeUnit unit)".
6. If the FutureTask times out, do nothing.
7. If the FutureTask completes properly, send its result back to the
Activity class via a MESSAGE_LONG_RUNNING_TASK_RESULT message.

Does this make sense?

Thanks again.

--



Timing out an AsyncTask?

by HippoMan » Sat, 10 Apr 2010 03:17:49 GMT


 Thank you, social hub. Our messages crossed. I think that the message
handler I describe in my previous post is the same one that you are
referring to.

--



Timing out an AsyncTask?

by Sam » Wed, 21 Apr 2010 05:05:25 GMT


 Some things to consider with respect to your proposed approach:

- If the Activity is destroyed while your background threads are
running, what should happen?
    - Should the Activity's onDestroy() cancel the threads somehow?
    - If the threads be allowed to finish their work, what should
happens then?  The original Activity is now dead, so sending a message
to it makes no sense.
- If your ControllerThread (or its Runnable) is a non-static inner
class (which includes anonymous inner classes) of the Activity, it
will hold an implicit reference to the Activity, even after it is
destroyed.  This can be a big memory leak if your thread lasts a long
time.  The same consideration applies to your FutureTask subclass.  In
short, make sure all classes are static or top-level classes.




--



Other Threads

1. Android apps + Dependency Injection => try out Yasdic!

Hello developers,

I have been using the Android SDK for a few months now, and one thing
I was missing was a dependency injection container.
Dependency injection is a good practice to lower the coupling between
the components of your application.

I thought about using Spring, or PicoContainer but they use the
reflection API to provide dependency injection. And the reflection API
may not be the best speed partner for your Android apps.
I couldn't find any real small dependency injection container, that
would provide dependency injection without reflection.

Here comes Yasdic, "Yet Another Small Dependency Injection Container",
no more then 6.7KB.

The definitions are written programmatically and stored by String ids,
the beans are lazily created, and Yasdic also deals with singleton and
prototype scopes, cyclic dependency, and container hierarchy.

Please feel free to try it out : http://code.google.com/p/yasdic

I already use it in my Android apps, and I find my code to be much
more maintainable (thought this is a quite subjective point of
view ;-) ).

Any feedback on this project will be appreciated, even code
criticism :-) .

Regards and thanks !

Piwa

--~--~---------~--~----~------------~-------~--~----~

2. Problem with Crypto APIs between Android and SUN Java

Hi,

I am writing an application that uses Digest MD5 to authenticate a
client (android phone) to a server (running on SUN Java 1.6.0_02). The
authentication, which works fine, if I run the client from a normal
computer (not the Dev phone), does not succeed when the client is
running on the phone.

I started digging deep into the client and server authentication code
and I figured out that the following code yields different results,
when executed on the Dev Phone and on the SUN JVM:

1  Mac hmac = Mac.getInstance("HmacSHA256");
2  SecretKeyFactory kf = SecretKeyFactory.getInstance("DES");
3  Key k = kf.generateSecret(ks);
4  hmac.init(k);
5  finalKey = hmac.doFinal(s);

The fact is that the key 'k' contains different byte values (De{*filter*}--
The reason is, that on the phone, the SecretKeyFactory kf which
generate k in line 3 returns a different results.
On the phone the implementation of the factory kf, which is returned
in line 2 is provided by the Bouncy Castle Provider. On the SUN JVM it
is the SUN implementation.
Obviously, both implementations - though using the same algorithm
(DES) - calculate different results.

Did anyone experience this before? Is that a known issue that might be
solved by a newer Java version?
Maybe it is a bug.

Oh one more thing: when you compare the values of the byte-array of
the Key k, which was generated by the SUN provider and the Bouncy
Castle one, you can see that the values are almost identical. They
only deviate by +1, 0, and -1 in an unregular pattern.

E.g. if
     k_phone = 54, 51, 54, 57, 54, 53, 53, 52
then
     k_sun    = 55, 50, 55, 56, 55, 52, 52, 52

so that is:      +1, -1, +1, -1, +1,  -1,  -1,   0

I wonder whether this has anything to do with parity bits or
something. I am not a crypto guy.

Any help is greatly appreciated.

Thanks.
--~--~---------~--~----~------------~-------~--~----~

3. How to set WebView zoom manually?

4. Where is the SIM Application Toolkit (STK) menu?

5. How to recover stopped activities

6. ListView including a TextView and Checkbox - Both need to handle clicks!

7. How to hang an outgoing call? (Revisited, Partly solved here)