使用后台服务开发活动的最佳实践
我的应用程序有一个用于 UI 的活动和一个用于后台轮询乐趣的服务。好像是标准票价。
AlarmManager 是否可以在不调用 Activity OnCreate 的情况下触发 Service Intent?
将 Activity & 放置有什么好处吗?服务到不同的应用程序?这会创建 2 个 apk 并使其无法作为一个应用程序放入市场吗?您能以某种方式将 2 个应用程序放入一个清单中吗?
关于两者之间的通信:
-If Activity &服务是同一应用程序的一部分 - 我不能只在应用程序范围内存储公共对象(如用户对象)以供两者共享吗?
- 看起来我什至不需要费心使用 AIDL - 两者也可以在应用程序范围内相互弱引用 - 并且它们可以通过这种方式互相调用方法?或者他们应该使用某种观察者模式或广播监听器来相互发布/订阅?
My Application has an Activity for the UI and a Service for background polling fun. Seems like standard fare.
Can AlarmManager trigger the Service Intent without Activity OnCreate being called?
Is there any benefit to putting the Activity & Service into different Applications? Would this create 2 apk's and make it impossible to put into Market as one app? Can you put 2 applications into one manifest somehow?
Regarding communication between the two:
-If Activity & Service are part of the same Application - can't I just store common objects (like User object) at the Application scope for the 2 to share?
-It seems like I don't even need to bother with AIDL - the two could just have weak references to each other at the Application scope as well - and they can call methods on each other that way? Or should they pub/sub each other with some kind of Observer Pattern or BroadcastListener thing?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
是的。
恕我直言,不。
是的。
从纯 XML 的角度来看,清单中可以容纳多个
元素。但是,据我所知,仅支持一种。对于非常快的事情,是的。但是,请记住,您的服务可能会被关闭(由 Android、用户等),之后您的进程可能会终止,并且您的
Application
对象会噗。我只会将其用于轻量缓存。Correct —— 这只是进程间服务绑定所需要的。
我在一百万年内也不会这样做。请负责任地使用该平台。活动和服务可以通过多种方式进行通信,同时保持松散耦合(或者,在本地绑定模式的情况下,以 Android 感知的方式紧密耦合)。
沿着这些思路的东西会更好。虽然活动和服务可能同时共存于同一流程中,但它们并非设计为彼此直接链接。
Yes.
IMHO, no.
Yes.
From a pure XML standpoint, there is room in the manifest for more than one
<application>
element. However, AFAIK, only one is supported.For very quick things, yes. However, bear in mind that your service may get shut down (by Android, by user, etc.), after which your process may get terminated, and your
Application
object goes poof. I'd use this for light caching only.Correct -- that is only needed for inter-process service binding.
I wouldn't do that in a million years. Please use the platform responsibly. There are plenty of ways for activities and services to communicate yet remain loosely coupled (or, in the case of the local binding pattern, tightly-coupled in an Android-aware fashion).
Something along those lines would be preferable. While the activity and the service may be co-resident in the same process at the same time, they are not designed to be directly linked to one another.