0

How do I run a parallel action (process) to the main app in Android?

I know that, there are a lot of ways to do it: Threads, Tasks, Handlers and etc'... This is the way I chose. But I think it takes a lot of memory and doesn't closes in the interrupt call.

checkReceiver = new BroadcastReceiver() {

    @Override
    public void onReceive(Context context, Intent intent) {
            // TODO: Check is this a good way to handle threads
            Thread t = new Thread() {
                @Override
                public void run() {
                    internetConnectionManager.TryConnect();
                    this.interrupt();
                }
            };
            t.start();                  
        }               
    }
};
Hamad
  • 5,096
  • 13
  • 37
  • 65
Alex K
  • 5,092
  • 15
  • 50
  • 77

2 Answers2

1

Two things wrong with your arroach:

  • You should not start a thread in onRecieve method. The reason is explained here :

This has important repercussions to what you can do in an onReceive(Context, Intent) implementation: anything that requires asynchronous operation is not available, because you will need to return from the function to handle the asynchronous operation, but at that point the BroadcastReceiver is no longer active and thus the system is free to kill its process before the asynchronous operation completes

  • Second, calling Thread.currentThread().interrupt() does not make any sense in your example since your thread is already done by that line and will finish, and also because you don not check interrupted flag anyway.

The better way, in my opinion, would be to start a simple IntentService from your onReceive code. Here is a simple tutorial.

Important edit based on FunkTheMonk's comment:
If the broadcast comes from an alarm or external event, it is possible that your device will go to sleep shortly after onReceive returns (even if you create a service). If that is the case, instead of using regular BroadCastReceiver you should extend WakefulBroadcastReceiver from support library.

kiruwka
  • 9,250
  • 4
  • 30
  • 41
  • Also worth noting that if the broadcast comes from an alarm or external event, it is possible that your device will go to sleep shortly after onReceive returns (even if you create a thread or service) - a helper class is available in the support library: http://developer.android.com/reference/android/support/v4/content/WakefulBroadcastReceiver.html – FunkTheMonk Jan 02 '14 at 14:07
  • My broadcast does come from alarm(manager). So what should I do? – Alex K Jan 02 '14 at 14:14
  • @FunkTheMonk I inlined your comment in my answer almost verbatim, hope you don't mind. Thanks for pointing this out, I never thought of it myself before. – kiruwka Jan 02 '14 at 14:23
  • In my alarm I use RTC_WAKEUP, In this case I also need WakefulBroadcastReceiver? – Alex K Jan 02 '14 at 14:27
  • @AlexKapustian: Yes, for `_WAKEUP`-style alarms, you nee to use `WakefulBroadcastReceiver` or my `WakefulIntentService`: https://github.com/commonsguy/cwac-wakeful – CommonsWare Jan 02 '14 at 14:30
  • I have a problem...I can't pass and object to intetservice... It's too complicated to serialize it and too many objects to make them parcable...any other options? – Alex K Jan 02 '14 at 15:23
  • 1
    @Alex It is straightforward to make your class implement **parcelable**, see [this](http://stackoverflow.com/a/7181792/2358786) Then you can put your object into intent and extract it in your service, this is the normal way. Alternatively if your object logically represents globally accessed state, or could be made a singleton, you could make it globally accessible to all your components. – kiruwka Jan 02 '14 at 17:33
  • what if I have a nested object inside my object, does it also needs to be parcelable? – Alex K Jan 02 '14 at 17:47
  • @Alex Yes, normally it should be parcelable as well. I guess you had figured that out already since you accepted the answer – kiruwka Jan 02 '14 at 19:08
0

Use handler

if you want to stop handler then fire an intent with some value eg.("quit handler")to receiver and call remove call back and inside handler you can handle the rest using ACTION switch you can also use intentservice

Amit
  • 391
  • 3
  • 15
  • Handlers aren't asynchronous unless you have have multiple handlers tied to loopers created for different threads.. Messages posted to a single Handler are handled one at a time, if one blocks, the rest will have to wait – FunkTheMonk Jan 02 '14 at 14:04