从广播接收器更新应用程序状态(全局变量)

发布于 2024-11-12 02:09:21 字数 969 浏览 2 评论 0原文

我一直在搜索和阅读,但不喜欢适合我需要的简洁答案,所以希望你们能为我指出正确的方向。

我有一个简单的应用程序,需要定期检查网络的结果。环顾四周,似乎使用 AlarmManager 是安排事件发生的最合适方法,而不是后台服务。

主要活动显示 Web 查询的最新结果、查询发生的时间以及下次重新查询的时间。

我遇到的问题是我没有意识到 BroadcastReceiver 在单独的进程中运行...当接收器更新应用程序的上次查询结果、上次检查时间和下次检查时间时,它显然没有在应用程序使用的对象;-)所以当我打开应用程序时它看起来已经过时了...

我尝试过从广播接收器和主活动设置的 StateManager 类上的静态变量,我尝试将 StateManager 指定为应用程序子类和指定作为清单中的 android:name...两者似乎最终都有不同的副本,因此从广播接收器更新的状态不是应用程序看到的状态。

现在我开始了解发生了什么......我正在努力了解解决它的最佳方法。

使用 SQLLite DB 来持久化状态会太麻烦,因为我想存储一个对象图,但似乎你还不能做到这一点(即使 SQLLite 存储 blob,android 界面还没有涵盖它?) 。我显然也不想花几个小时在 OR 映射上。

当网络查询突出显示需求时,我“确实”当前会通过通知管理器发出通知,这允许我将意图和额外内容传递给应用程序..以便该部分对我有用...但是,当网络查询返回时不需要生成通知的结果,我没有返回应用程序的“路径”来给它下一次检查时间,并且我不想仅仅为了有一种方法将额外信息传递给它。

我想问题的关键是我想要, 从广播接收器,将对象保留在我的应用程序可以在实时时检索的地方 或者 让广播接收器在应用程序进程中执行工作(无需将应用程序带到前台),以便对活动使用的实例进行任何静态变量更改。

如果最好的方法是将其编写为服务,那么就这样吧(如果是这种情况,在我开始编码之前......该服务是否与应用程序在同一进程中运行,或者我会得到类似的“它没有做什么”单例应该解决我在广播接收器中遇到的问题!)

I've been searching and reading and not fond a concise answer that fits what I need so hopefully you guys can point me in the right direction.

I have a simple app which needs to periodically check the web for results. Reading around, it seemed using an AlarmManager was the most appropriate way to schedule an event to happen as opposed to a background service.

The main activity shows the most recent result of the web query, when that query took place, and the next time it's due to re-query.

THe problem I'm having is that I didn't realise the BroadcastReceiver ran in a separate process...when the receiver updates the applications last query result, last check time and next check time, it's obviously not doing it in the copy of the object the app uses ;-) so it looks stale when I open the app...

I've tried Static variables on a StateManager class that are set from the broadcastrecevier and main activity, i've tried specifying the StateManager to be an Application subclass and specifying that as the android:name in the manifest...both seem to end up with distinct copies so the state updated from the broadcastreceiver isn't the state that the app sees.

NOw I'm beginning to understand what's happening...I'm struggling to understand the best way to resolve it.

Using a SQLLite DB to persist state is going to be too mcuh trouble because I want to store an object graph and it appears you can't do that yet (even if SQLLite stores blobs, the android interface doesn't cover it yet ?). I obviously don't want to spend hours on O-R mapping either.

I 'Do' currently raise a notification through the notificationmanager when the web query highlights a need, and that allows me to pass the intent and extras through to the app..so that part works for me...however, when the webquery returns a result that doesn't need notifications generated, I have no 'path' back to the application to give it the next check time, and I dont' want to bring the app forward just for the sake of having a way to pass extras to it.

I guess the crux of the problem is that I want,
from a broadcastrecevier, to persist an object somewhere that my app can retrieve when it's live
or
have a broadcastreceiver perform work within the app process (without bringing the app to the foreground) so that any static variable changes are made to instances that the activity use.

if the best way is to write this as a service, then so be it (if that's the case, before I start coding..does the service run in the same process as the application or will I get similar 'it's not doing what a singleton was supposed to do' problems that I've been having with the broadcastreceiever!)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

泛泛之交 2024-11-19 02:09:21

似乎我在应用程序清单的接收器部分指定了 android:process=":remote" 。删除它会使警报在应用程序线程中运行,从而解决了问题。

Seems I'd specified android:process=":remote" in the receiver section of the app manifest. Removing that makes the Alarm run int he apps thread which resolved the issue.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文