Home/ Questions/Q 4539156
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-21T14:54:28+00:00

For instance, we are in SomeActivity and the activity has a button that invokes

  • 0

For instance, we are in SomeActivity and the activity has a button that invokes moving files from one dir to another (let’s call it job).

On BlackBerry I would:

  1. push a non-cancellable popup (Dialog screen) saying “Please wait…”
  2. start a thread that fulfills the job
  3. on thread completion close the popup

This approach 99.99% can guarantee that we stay on the same screen after the task is over, user just sees the popup and waits for job completion. Device rotation or whatever does not break the desired workflow.

On Android things change. I know there’s the AsyncTask that is probably provided to solve my case. There’s even a good example of how it should be used. But since there’s no guarantee of how long an Activity instance will live the AsyncTask should be cancelled on onSaveInstanceState (and restarted on onRestoreInstanceState). This means using AsyncTask there’s no guarantee we are able to fully fulfill the job once started. In some cases as sending an http post request for creating a user I would not want to get in “user already exists for this login” trouble on reruning the AsyncTask. This is possible since the AsyncTask can be interrupted while the request is already sent (and the server actually is doing its job – creating a new user), but the AsyncTask is canceled before we got the response.

Is there any solution on Android to get the BB-like behaviour stated above?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    In May 2010 Google issued a new IO session called Developing Android REST client applications which explains how to achieve exactly what I asked for.

    It turned out the question is rather complicated, so there is no easy and quick solution. The solution requires deep knowledge of Android platform/API. This is the price caused by the flexibility of the app process/Activity lifecycles.

    I feel some oddity on why this info was not presented from the very first version of Android. Looks like Google knew how to write 100% bugless apps and for some marketing reason did not share the approach. Just imagine how many buggy apps was written by May 2010.

    Anyway I’m glad now I have smth we call best practice approach.

    • 0