Geek asks and answers

What is the preferred way to call Android activity from a service thread

I am currently developing an Android application that has the following needs:

The workflow is running on the service. This thread does some processing and needs to be called from the main action and provides some asynchronous responses to the same activity.

Calling a service from an Activity is easy (IBinder stuff)

Now I ask a question about the correct implementation of a service callback.

I was originally going to add android.os.Handler to Activity and handle the streaming responders in MyActivity.handleMessage (Message), but this requires me to pass this link to the handler for this service. So what happens when the Android OS decides to destroy / recreate my activity due to a change in orientation, for example? Is my activity active because it refers (indirectly) to a service? If the activity is destroyed / restored in any case, what will happen with the link to the Handler link in the service?

I think that I am not using the correct method to call Activity from the service thread, so I wanted to know if anyone could tell me the correct way.

TIA

+5
source share
4 answers

LocalBroadcastManager

Activity:

BroadcastReceiver localBroadcastReceiver = new BroadcastReceiver()
{
    @Override
    public void onReceive(Context context, Intent intent)
    {
        Log.d("BroadcastReceiver", "Message received " + intent.getAction());
        Log.d("BroadcaseReceiver", "Received data " + intent.getStringExtra("com.my.package.intent.EXTRA_DATA"));
    }
};

@Override
protected void onStart()
{
    super.onStart();
    final LocalBroadcastManager localBroadcastManager =
        LocalBroadcastManager.getInstance(this);
    final IntentFilter localFilter = new IntentFilter();
    localFilter.addAction("com.my.package.intent.ACTION_NAME_HERE");
    localBroadcastManager.registerReceiver(localBroadcastReceiver, localFilter);
}

@Override
protected void onStop()
{
    super.onStop();
    final LocalBroadcastManager localBroadcastManager =
        LocalBroadcastManager.getInstance(this);
    // Make sure to unregister!!
    localBroadcastManager.unregisterReceiver(localBroadcastReceiver);
}

(, ):

final LocalBroadcastManager localBroadcastManager =
    LocalBroadcastManager.getInstance(context);
final Intent intent = new Intent("com.my.package.intent.ACTION_NAME_HERE")
intent.putExtra("com.my.package.intent.EXTRA_DATA", yourBackgroundData);
localBroadcastManager.sendBroadcast(intent);

, , intent.putExtra - .

+4

Application. Application, , . Activity Service .

, , / . Application , . Application , , . , Application, , , - .

, Service . , Handler , Service. BroadcastReceiver , , .

+3

, , MyActivity.handleMessage(Message). , ( ), , , ( "onBind" ). , . , , Messenger .

, onStop , Messenger " ", Messenger. onStart , Messenger.

, , - , , Messenger . , Messenger, , Activity , , , onStart.

, (10 ?), , , , , , .

0

, .

, .

, , , , . / .

Therefore, if the callback needs to process something in the main / user interface thread, it just uses

(new Handler(Looper.getMainLooper()).post()

which has the advantage that it finds the dynamic flow of the main / UI at the point in time when the code is executed. On the other hand, this is not even necessary because the main / UI stream does not change, so finding it using the View link or anything else you can have on hand in the callback will also work.

0
source

More articles:


All Articles