blocks|key|101038|text|这两种方法都适用于使用LiveData，因为LiveData的目的是将它放在另一个线程上，并在发生更改时仍然通知用户。看起来它肯定会取代LocalBroadcastManager.getInstance(this).sendBroadcast(in);，你的IntentService将会postValue。只要让你的活动或任何需要注意变化的东西成为观察者就行了。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|101039|entityMap^0|1W|1M|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

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 <code>LocalBroadcastManager.getInstance(this).sendBroadcast(in);</code> and your IntentService would postValue. Just have your activity or anything that needs to be aware of the changes become an observer.

blocks|key|2848884|text|我认为LiveData不会帮助您从Service向其他组件发送任何数据。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2848885|从任何Service到其他组件的通信的问题是，您通常不会获得对Service的直接引用，因此您不能直接“订阅”通知。|2848886|理论上，如果Service运行在同一个进程中，可以绑定它，获取对Service对象的引用，然后直接进行订阅。然而，这通常是一种过度的杀伤力，我认为这种模式并没有得到广泛的应用。|2848887|在您的示例中，有两种通信机制：|2848888|2848889|服务静态地访问应用程序对象并设置一些数据。这是通过全局状态的通信，通常被认为是通过LocalBroadcastManager|ordered-list-item|2848890|的anti-pattern.|2848891|Communication|unordered-list-item|2848892|2848893|从以上两种机制中，我会不惜一切代价只使用#2和避免#1。|2848894|回到LiveData。|2848895|为了能够从Service获取LiveData对象，您需要拥有对该Service的引用。这通常是不可能的，除非你在相同的进程中绑定Service，或者使用一些涉及全局状态的丑陋的黑客攻击。|2848896|因此，LiveData在此上下文中的用处非常有限。|2848897|顺便说一句，虽然LocalBroadcastManager还不错，但我发现这个机制太复杂了，而且受到了限制。因此，如果Service在同一进程中运行，我更喜欢使用EventBus以便从Service与其他组件通信(反之亦然)。|2848898|你可以在我几天前写的SQLite+benchmarking+application中看到这样一个通信的例子。在此应用程序中，TestService将状态更改和测试结果作为粘性事件发布到EventBus，TestActivity订阅这些事件。|2848899|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/techyourchance/android_sqlite_benchmark/blob/master/app/src/main/java/com/techyourchance/sqlitebenchmark/test/TestService.java^0|3|8|H|7|0|3|7|V|7|0|6|7|W|7|0|0|0|0|0|0|0|0|2|8|0|5|7|E|8|W|7|1S|7|0|3|8|0|1N|7|29|8|2K|7|0|1Q|B|2K|8|2T|C|A|V|0|0^^$0|@$1|2|3|4|5|6|7|1F|8|@$9|1G|A|1H|B|C]|$9|1I|A|1J|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1K|8|@$9|1L|A|1M|B|C]|$9|1N|A|1O|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1P|8|@$9|1Q|A|1R|B|C]|$9|1S|A|1T|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|1U|8|@]|D|@]|E|$]]|$1|L|3|-4|5|6|7|1V|8|@]|D|@]|E|$]]|$1|M|3|N|5|O|7|1W|8|@]|D|@]|E|$]]|$1|P|3|Q|5|6|7|1X|8|@]|D|@]|E|$]]|$1|R|3|S|5|T|7|1Y|8|@]|D|@]|E|$]]|$1|U|3|-4|5|6|7|1Z|8|@]|D|@]|E|$]]|$1|V|3|W|5|6|7|20|8|@]|D|@]|E|$]]|$1|X|3|Y|5|6|7|21|8|@$9|22|A|23|B|C]]|D|@]|E|$]]|$1|Z|3|10|5|6|7|24|8|@$9|25|A|26|B|C]|$9|27|A|28|B|C]|$9|29|A|2A|B|C]|$9|2B|A|2C|B|C]]|D|@]|E|$]]|$1|11|3|12|5|6|7|2D|8|@$9|2E|A|2F|B|C]]|D|@]|E|$]]|$1|13|3|14|5|6|7|2G|8|@$9|2H|A|2I|B|C]|$9|2J|A|2K|B|C]|$9|2L|A|2M|B|C]]|D|@]|E|$]]|$1|15|3|16|5|6|7|2N|8|@$9|2O|A|2P|B|C]|$9|2Q|A|2R|B|C]|$9|2S|A|2T|B|C]]|D|@$9|2U|A|2V|1|2W]]|E|$]]|$1|17|3|-4|5|6|7|2X|8|@]|D|@]|E|$]]]|18|$19|$5|1A|1B|1C|E|$1D|1E]]]]

I think that <code>LiveData</code> will not help you in sending any data from <code>Service</code> to other components.

The problem with communication from any <code>Service</code> to other components is that you don't usually obtain a direct reference to the <code>Service</code>, therefore you can't directly "subscribe" to notifications.

Theoretically, if the <code>Service</code> runs in the same process, you can bind it, obtain a reference to <code>Service</code> 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:

<ol>
<li>Service reaches statically to Application object and sets some data. This is a communication through global state, and is generally considered an anti-pattern.</li>
<li>Communication through LocalBroadcastManager</li>
</ol>

From the above two mechanisms, I would use only #2 and avoid #1 at all costs.

Back to <code>LiveData</code>.

In order to be able to get <code>LiveData</code> object from the <code>Service</code> you will need to have a reference to that <code>Service</code>. This is usually impossible unless you bind <code>Service</code> in the same process, or use some ugly hack that involves global state.

Therefore, usefulness of <code>LiveData</code> in this context is very limited.

By the way, while LocalBroadcastManager is alright, I find this mechanism too complicated and restricting. Therefore, if the <code>Service</code> runs in the same process, I prefer to use <code>EventBus</code> in order to communicate from <code>Service</code> to other components (or vice-versa).

An example of such a communication you can see in <a href="https://github.com/techyourchance/android_sqlite_benchmark/blob/master/app/src/main/java/com/techyourchance/sqlitebenchmark/test/TestService.java" rel="noreferrer">SQLite benchmarking application</a> that I wrote several days ago. In this app, <code>TestService</code> posts status changes and test results to <code>EventBus</code> as sticky events, and <code>TestActivity</code> subscribes to those events.

I have old Android/java code, that contains two derives from <code>IntentService</code>,
and these services not run in separate processes.

The question is about the way to return result from these <code>IntentService</code>.

One service return result by using <code>Handler</code> + <code>Runnable</code>, to run code in main loop:

<pre><code>new Handler(Looper.getMainLooper()).post(new Runnable() {
 @Override
 public void run() {
 MyApplication.get().setFoo(someThing);
 }
});
</code></pre>

the other one is uses <code>LocalBroadcastManager.getInstance(this).sendBroadcast(in);</code> to send message to <code>Activity</code>, and <code>Activity</code> subscribe via <code>BroadcastReceiver</code> on message in <code>onResume</code>, and unsubscribe in <code>onPause</code>.

Am I right, and in both case it is possible to use <code>LiveData</code> to simplify things?

<code>IntentService</code> should create <code>LiveData</code> and who want result should <code>observe</code> it,
and when new data arrives <code>IntentService</code> should call <code>postValue</code>,
or may be there are some reefs to prevent usage of <code>LiveData</code> here?

LiveData vs Handler and LocalBroadcast

Android

我有旧的Android/java代码，其中包含两个从IntentService派生的代码，并且这些服务而不是在单独的进程中运行。问题是如何从这些IntentService返回结果。使用Handler + Runnable返回一个服务结果，在主循环中运行代码：new Handler(Looper.getMainLoope...

问LiveData vs处理程序和LocalBroadcast
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问LiveData vs处理程序和LocalBroadcastEN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问LiveData vs处理程序和LocalBroadcast
EN