【问题标题】:Android components-based application design: How should I represent this model?Android 基于组件的应用程序设计:我应该如何表示这个模型?
【发布时间】:2011-05-12 17:25:54
【问题描述】:

我想将我的应用程序重新设计成组件,这样它会更加模块化并且将来更容易重用,但是我从来没有真正设计过应用程序,所以我真的不知道我应该怎么做这个。

以下是应用程序的简要说明:

  • 应用程序的目的是允许用户创建将存储在设备本地并通过网络发送的“事件”。

  • 用户可以通过 2 个活动与应用程序交互:一个“NewEventActivity”允许他创建新的事件,一个“LogbookActivity”允许他浏览以前创建的事件。

  • 本地存储应由 SQLite 数据库处理

  • 事件应该以特定的二进制格式发送。

  • 其他应用程序应该能够使用发送组件来格式化并以相同格式发送其他类型的消息。

这张图代表了我对组织组件的想法。方框代表组件,箭头代表没有这些组件的交互。

这是我的问题:

  • 这个模型看起来好吗?你觉得有什么可以改进的吗?
  • 我的 SQLiteHelper 应该是 ContentProvider 还是 ContentResolver?
  • 我应该为每种类型的信号创建一个 BroadcastReceiver 类,还是应该创建一个大的 BroadcastReceiver 来处理我的应用程序可以处理的所有类型的信号?

谢谢!

【问题讨论】:

    标签: android components


    【解决方案1】:

    一些简化设计的建议:

    • 如果EventWriterEventReader由于用户直接交互而仅与活动交互,则它们不需要是BroadcastReceivers。实际上,它们可能只是活动中的方法。

    • 根据您选择何时发送事件的方式,您还可以将MessageFormatterSender 重构为IntentService,它将定期轮询内容提供者并选择要发送哪些数据。您可以通过闹钟安排IntentService

    我的 SQLiteHelper 应该是 ContentProvider 还是 ContentResolver?

    它应该实现 ContentProvider(因为它提供了对数据的访问)。

    我应该创建一个 BroadcastReceiver 每个信号类型的类,或者我应该 创建一个大的广播接收器 处理我的所有类型的信号 应用可以处理吗?

    我倾向于每种信号类型使用一个接收器,但这实际上只是一种偏好。

    【讨论】:

    • 感谢您的回答。 EventWriter 和 EventReader 目前是活动的方法,我想将它们分离,因为我的应用程序实际上更复杂,并且我有几个活动使用它。 (也许将来这应该可以从其他应用程序中获得)。事件必须实时发送,所以我不能使用 IntentService。
    猜你喜欢
    • 1970-01-01
    • 2011-09-30
    • 2013-04-15
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多