0

I got main Activity that on button press starts other class named Getter and that Getter class creates 1-60 000 threads (which do network stuff), so it takes some time until they all are completed. My problem is that when I rotate my device while those threads are running, my program stops working correctly. In my main Activity I have handler that every 2 seconds gets an array from Getter class and then puts those values into local array list.

I tried this solution:

Background task, progress dialog, orientation change - is there any 100% working solution?

but found it very complicated. So now I am wondering if there is any other solution to my problem. For instance can my threads continue running in background even if my orientation changes? If that is not possible can I programatically lock orientation to the one it was just before button was pressed, then wait until threads have completed then again make orientation to go with sensor?

Community
  • 1
  • 1
Rohit Malish
  • 3,209
  • 12
  • 49
  • 67
  • Now, when you say "I tried this solution" and subsequently say "but I found it very complicated" does that mean you _really tried it_? Or did you start and stop because it seemed like overkill? From the sounds of the steps, it makes sense why it should work and why you should implement it one of those two ways. (aka: to decouple the tasks from the activity) – TheZ Aug 15 '12 at 19:24
  • I mean the steps werent clear enough for me, so there was A LOT of searching on the internet for every step, until I realised it wont work that way. I need tutorial that is more beginner friendly. – Rohit Malish Aug 15 '12 at 19:29

2 Answers2

0

You can Lock Orientation 

setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_NOSENSOR);

setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_SENSOR);

Refer https://stackoverflow.com/a/3611554/1008278

Community
  • 1
  • 1
VenomVendor
  • 15,064
  • 13
  • 65
  • 96
0

Our way of handling this is to start the async task from a sticky app.Service and allow the async task to communicate with the parent Service which in turn communicates with anyone listening to it's broadcast events via the BroadcastReceiver framework. I have gone someway to describe this mechanism here.

On orientation change, your app.Activity will be destroyed but the background Service won't be (it can be onLowMemory & a myriad of other circumstances but it probably won't). On recreating the activity you can check to see if your service is still running via the solution I posted here. Based on that result you can decide what to do with the UI, redisplay/re-add the progress dialogue or whatever and re-register your receiver to listen for events coming out of the Service.

The responsibilities between these layers works like this;

  1. AsyncTask
    • Does the work.
    • Reports back what it's up to and when it's done by firing events (Intents)
    • That's it
  2. Service
    • Hosts an orientation unaware container for the AsyncTask
    • Registers listeners for events emanating from the AsyncTask in #onCreate
    • Executes the AsyncTask in #onStartCommand
    • Stops itself (see stopSelf()) when it receives the "I have finished" event from the AsyncTask
    • Fires events describing progress to anyone listening
  3. Activity
    • Starts the Service which in turn starts the AsyncTask.
    • Registers listeners for events emanating from the Service in #onCreate
    • Checks whether a Service is running already during onCreate to make a decision as to whether work is ongoing or needs starting.

3 elements with discrete unconfused roles. That's the way we like it. The only nuance with this approach is the use of the BroadcastReceivers. If you are comfortable with those then you are golden.

Community
  • 1
  • 1
BrantApps
  • 6,362
  • 2
  • 27
  • 60
  • can I use AsyncTask to handle everything that my Threads are handling? eg. can I replace my thread class with AsyncTask? – Rohit Malish Aug 15 '12 at 21:00
  • I had to refer to the JavaDoc to answer this so instead of Chinese whispers, have a read of the 2nd paragraph here- http://developer.android.com/reference/android/os/AsyncTask.html – BrantApps Aug 15 '12 at 21:14
  • So, IMHO it sounds like you still need to keep your implementation of spawning threads (your tasks sound like they take a while thus Android's implementation of AsyncTask may not suit) but you can still re-use the above pattern. This area of Android I think is necessarily convoluted since you have to think and plan what you want to do to avoid destroying the user experience and/or compromising other activities with over-zealous resource heavy threading. Let me know if you need any more assistance/improvements you may have thought of with the approach I outlined – BrantApps Aug 20 '12 at 11:20