I have old Android/java code, that contains two derives from IntentService
,
and these services not run in separate processes.
The question is about the way to return result from these IntentService
.
One service return result by using Handler
+ Runnable
, to run code in main loop:
new Handler(Looper.getMainLooper()).post(new Runnable() {
@Override
public void run() {
MyApplication.get().setFoo(someThing);
}
});
the other one is uses LocalBroadcastManager.getInstance(this).sendBroadcast(in);
to send message to Activity
, and Activity
subscribe via BroadcastReceiver
on message in onResume
, and unsubscribe in onPause
.
Am I right, and in both case it is possible to use LiveData
to simplify things?
IntentService
should create LiveData
and who want result should observe
it,
and when new data arrives IntentService
should call postValue
,
or may be there are some reefs to prevent usage of LiveData
here?
localbroadcastmanager has been fully deprecated. There will be no further releases of this library. Developers should replace usages of LocalBroadcastManager with other implementations of the observable pattern. Depending on the use case, suitable options may be LiveData or reactive streams.
If you want some kind of broadcasting in your application then you should use the concept of LocalBroadcastManager and we should avoid using the Global Broadcast because for using Global Broadcast you have to ensure that there are no security holes that can leak your data to other applications.
LiveData notifies Observer objects when underlying data changes. You can consolidate your code to update the UI in these Observer objects. That way, you don't need to update the UI every time the app data changes because the observer does it for you. No memory leaks.
I think that LiveData
will not help you in sending any data from Service
to other components.
The problem with communication from any Service
to other components is that you don't usually obtain a direct reference to the Service
, therefore you can't directly "subscribe" to notifications.
Theoretically, if the Service
runs in the same process, you can bind it, obtain a reference to Service
object and then directly perform subscription. However, this is often an overkill and I don't see this pattern being used widely.
In your examples, there are two communication mechanisms:
From the above two mechanisms, I would use only #2 and avoid #1 at all costs.
Back to LiveData
.
In order to be able to get LiveData
object from the Service
you will need to have a reference to that Service
. This is usually impossible unless you bind Service
in the same process, or use some ugly hack that involves global state.
Therefore, usefulness of LiveData
in this context is very limited.
By the way, while LocalBroadcastManager is alright, I find this mechanism too complicated and restricting. Therefore, if the Service
runs in the same process, I prefer to use EventBus
in order to communicate from Service
to other components (or vice-versa).
An example of such a communication you can see in SQLite benchmarking application that I wrote several days ago. In this app, TestService
posts status changes and test results to EventBus
as sticky events, and TestActivity
subscribes to those events.
Both methods work with using LiveData since the purpose of LiveData is to have it on another thread and still notify users when something has changed. Seems like it would definitely replace LocalBroadcastManager.getInstance(this).sendBroadcast(in);
and your IntentService would postValue. Just have your activity or anything that needs to be aware of the changes become an observer.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With