从前台服务在 android 中发出警报
我正在开发一个应用程序，用户可以在其中创建例程并为这些例程设置警报和提醒。我设置的当前工作流程是：
- 在应用程序中，使用警报管理器安排精确的警报。
- 这会将待处理的意图发送到广播接收器。
- 广播接收器接收广播，验证闹钟确实应该响起并启动前台服务
- 前台服务显示通知，响起一些曲调并振动手机
我的确切问题是：这是否太过分了？
A发送通知时使用类似的工作流程。广播接收器启动前台服务，然后创建持久通知。当服务运行时虽然时间很短以至于不明显，但它会显示自己的通知，当服务停止时该通知会被删除。
我使用 ForegroundService 是否使事情变得过于复杂？所有这些工作都应该在广播接收器中完成吗？
感谢您的帮助。 马蒂奇
I'm developing an app where users can create routines and set alarms and reminders for these routines. The current workflow that I have set up is:
- In app an EXACT alarm is scheduled using the alarm manager.
- This sends a pending intent to a broadcast receiver.
- The broadcast receiver receives the broadcast, verifies that the alarm should indeed ring and starts a foreground service
- The foreground service displays a notification, rings some tune and vibrates the phone
My exact question is: Is this overkill?
A similar workflow is used when sending notifications. The broadcast receiver starts a foreground service that then creates a persistent notification. While the service is running although so briefly that it's not noticable it is displaying its own notification which gets removed when the service stops.
Did I overcomplicate things with the ForegroundService? Should all this work be done in the broadcast receiver?
Thanks for your help.
Matic
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您需要实际使用自己的媒体播放器/振动器并控制它们的行为，而不是依赖系统通知通道提供的那些（系统通知通道具有一些限制，例如在创建后无法进行有用的更改、声音等），那么这并不是一个过大的杀伤力。被其他通知取消、用户意外更改等）。
尝试在后台从广播接收器运行媒体播放器/振动器将遇到后台任务限制并导致各种不可预测的问题。
我真的希望 Android 能够为开发者提供更加灵活的通知通道 API。他们根本不必牺牲用户控制来实现这一目标。
This isn't an overkill if you need to actually use your own media player/vibrator and control their behavior instead of relying on those provided by the system notification channels (which come with limitations such as the inability to make useful changes after creation, sounds being cancelled by other notifications, users making accidental changes, etc).
Attempting to run media players/vibrators from the broadcast receiver in the background will run into background task limitations and result in all kinds of unpredictable issues.
I really wish Android made the notification channel APIs more flexible for developers. They don't have to sacrifice user control to achieve this at all.