Widget Provider是一个专门的BroadcastReceiver。
假设存在一个应用程序，1-n安卓服务，1-k活动，以及可能不是小部件的额外0-n广播接收器，我想验证属于哪个并且不属于逻辑上属于广播接收器。这是一些项目..
并且假设通常首先发布的是小部件。
请评论任何项目是否属于窗口小部件内部或外部以及原因。感谢。
1）如果应用程序需要始终监听某些事件，无论它们是否显示在窗口小部件中，或者不在哪里？在小工具？如果不是什么会使广播接收器可以听取应用程序的事件？
2）小部件是否应该发出通知？或要求服务发布？即通知逻辑应该驻留在小部件本身还是服务中。
3）小部件是否应该发布广播或要求服务执行此操作？
4）小部件是否应该访问任何系统服务，如Notification Manager，PowerManager等为什么，为什么不呢？
5）小部件应该保留自己的状态吗？如果它不应该保持状态如何改变它显示的内容？喜欢不同的文字或图标？
6）小部件应该开始活动还是让服务处理这个？
7）用户可以使用传递给更新和接收器的上下文，还是应该使用ctx.getApplicationContext（）来执行context.startService之类的操作？ （也许传入的是应用程序上下文？）
答案 0 :(得分：1)
Quoting myself从您的交叉发布到android-developers Google小组：
你的整个问题都围绕着“小工具”。没有“
小工具“。从你问题的开头句子，我正在解释
“Widget”的意思是“AppWidgetProvider的一个子类来处理
处理app小部件或app小部件实例系列“。
1）如果应用程序需要始终监听某些事件 它们是否出现在小部件中或不出现在哪里？在里面 工具？
AppWidgetProvider没有理由回复其他人
广播，因为任何东西都可以更新app小部件的RemoteViews。
并且AppWidgetProvider无法注册听众（例如，
PhoneStateListener）。
因此，我会说这里的答案是“不”。
2）小部件是否应该发出通知？或要求发布服务 他们？即通知逻辑应该驻留在小部件本身还是 在服务中。
从技术上讲，AFAIK提出通知很便宜，因此很安全
要AppWidgetProvider做。
从逻辑上讲，AppWidgetProvider永远不应该有任何理由提出
通知，恕我直言。
3）小部件是否应该发布广播或要求服务执行此操作？
从技术上讲，发送广播的AFAIK价格便宜，因此很安全
要AppWidgetProvider做。
从逻辑上讲，AppWidgetProvider永远不应该有任何理由发送
广播，恕我直言。
4）小部件是否应该访问任何类似的系统服务 通知管理器，PowerManager等为什么，为什么不呢？
这不能抽象地回答。
5）小部件应该保留自己的状态吗？如果不应该保留 说明它如何改变它显示的内容？喜欢不同的文字或 图标？
可能需要。例如，假设您有一个显示的应用小部件 某个城市的天气。该配置活动 app小部件允许用户选择城市。在某个地方，你需要 存储该城市，与任何其他实例的城市不同 应用程序窗口小部件可能需要（例如，用户添加应用程序的两个副本 用于跟踪两个城市天气的小部件）。
6）小部件应该开始活动还是让服务处理 这个？
AppWidgetProvider永远不应该有理由直接“开始”
活动“，也不应该从AppWidgetProvider触发服务
有任何理由直接“开始活动”，恕我直言。
但是，非常欢迎创建PendingIntents
“开始活动”并将它们作为小部件的点击处理程序附加
在应用小部件的RemoteViews中。
7）用户可以使用传递给更新和接收器的上下文 应该使用ctx.getApplicationContext（）来做类似的事情 context.startService？ （也许传入的是应用程序 背景？ ）
大多数事情你可以使用传入的Context。有一件事
将registerReceiver()与null接收器一起使用是不行的
获取粘性广播的最后一个值，例如
ACTION_BATTERY_CHANGED - 为此，您需要使用
getApplicationContext()。