基于Android组件的应用程序设计：我应该如何表示这个模型？
我想将我的应用程序重新设计成组件，这样它更加模块化，并且将来更容易重用，但我从未真正设计过应用程序，所以我真的不知道应该如何做到这一点。
以下是该应用程序的简要说明：
- 是允许用户创建将本地存储在设备上并通过网络发送的“事件”。
用户可以通过 2 个活动与应用程序交互：“NewEventActivity”允许他创建新事件，“LogbookActivity”允许他浏览以前创建的事件。
本地存储应由 SQLite 数据库处理
事件应以特定的二进制格式发送。
其他应用程序应该能够使用发送组件以相同的格式格式化和发送其他类型的消息。
这张图代表了我如何考虑组织组件。方框代表组件，箭头代表没有这些组件的交互。 
这是我的问题：
- 这个模型看起来还好吗？您能看到一些可以改进的地方吗？
- 我的 SQLiteHelper 应该是 ContentProvider 还是 ContentResolver？
- 我应该为每种类型的信号创建一个 BroadcastReceiver 类，还是应该创建一个大的 BroadcastReceiver 来处理我的应用程序可以处理的所有类型的信号？
谢谢你！
I would like to re-design my application into components, so it is more modular and easier to re-use in the future, but I've never really designed applications, so I don't really know how I should do this.
Here is a brief description of the application:
The purpose of the Application is to allow the User to create "Events" that are going to be stored locally on the Device and sent over the network.
The User can interact with the application through 2 Activities: A "NewEventActivity" that allows him to create the new Events and a "LogbookActivity" that allows him to browse previously created Events.
The local storage should be handled by a SQLite Database
The Event should be sent in a specific Binary format.
Other applications should be able to Use the Sending component to Format and send other type of messages in the same format.
This drawing represents how I was thinking of organizing the components. Boxes represent components, and arrows represent interactions without those components.
Here are my questions:
- Does this model look OK? Can you see something that could be improved?
- Should my SQLiteHelper be a ContentProvider or a ContentResolver?
- Should I create one BroadcastReceiver class per type of Signal, or should I create one big BroadcastReceiver that handles all the kind of Signals my application can handle?
Thank you!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
简化设计的一些建议：
如果
EventWriter和EventReader仅由于直接用户交互而与 Activity 交互，则它们不需要广播接收器。事实上，它们可能只是活动中的方法。根据您选择何时发送事件的方式，您还可以将
MessageFormatter和Sender重构为IntentService，它将定期轮询内容提供者并选择要发送的数据片段。您可以通过警报安排IntentService。它应该实现 ContentProvider（因为它提供对数据的访问）。
我倾向于每种信号类型使用一个接收器，但这实际上只是一种偏好。
A few suggestions to simplify the design:
If
EventWriterandEventReaderonly interact with the activity due to direct user interaction, they don't need to beBroadcastReceivers. In fact, they could just be methods in the activities.Depending on how you choose when to send Events, you could also refactor
MessageFormatterandSenderinto anIntentServicewhich will periodically poll the content provider and choose which pieces of data to send. You can schedule theIntentServicevia alarms.It should implement ContentProvider (since it provides access to data).
I lean towards one receiver per signal type, but that's really just a preference.