我最近一直在为我的 Android 手机编写代码,我一直在想……这个 Intent 类是否应该勾勒出一种新的编程风格?
我一直怀疑 API 设计不鼓励 MVC:意图是与所有用户相关对象(活动、服务、其他应用程序......)交互的主要方式。
我的思路对吗?是否应该坚持用业务逻辑“污染”活动?
我一直在阅读 android 开发者网站,但不鼓励使用特定的编码风格。
我最近一直在为我的 Android 手机编写代码,我一直在想……这个 Intent 类是否应该勾勒出一种新的编程风格?
我一直怀疑 API 设计不鼓励 MVC:意图是与所有用户相关对象(活动、服务、其他应用程序......)交互的主要方式。
我的思路对吗?是否应该坚持用业务逻辑“污染”活动?
我一直在阅读 android 开发者网站,但不鼓励使用特定的编码风格。
您的问题并不完全清楚,因为您似乎将编码风格与程序架构混淆了。
在我看来,Android 在编码风格方面确实没有任何改变。您的 Java 编码风格仍然可以正常工作,并且大多数 Android 应用程序看起来与其他应用程序非常相似。概括地说,有些事情你可能想在 Android 中做,而在其他语言中做不到,请参阅 Android 指南了解详细信息。 基本思路是:内存是有限的,没用就不要用。
就整个程序架构而言,是的,Android 风格高度基于消息传递(通过 Intent 对象)风格。您对 Activity中的GUI 事件做出反应的方式仍然大致相同:您使用事件处理程序来对按钮按下等事件做出反应……但该平台主要围绕使用不同组件(Activity、Services、BroadcastReceivers)设计应用程序, etc...) 和 Intents 在它们之间进行通信。虽然 Intent 提供了一种在组件之间交换数据的灵活方式,但您仍然不应该在 Intent 中传递大量数据,而应该将这些类型的东西放在 ContentProvider 或类似的东西中。
我从这本OReilly 书中获得了以下很多想法。这对我来说是最有效的。
就架构而言,它帮助我将 Android 的 UI 视为一种页面控制器模式——我发现它实际上类似于 .Net Web 表单。所以是的,它确实适合 MVC(至少是它的页面控制器风格)。Activity 是您的控制器,您通常将视图存储在 XML 中,并且您可以根据自己的喜好构建模型。
你会在 Android 中看到很多类似网络的想法。Intent 很像 HTTP,或者更普遍的 REST。Intent 有一个“名词”来说明它们所关心的内容(可以是明确的类声明,即:转到特定的 Activity,或者可以使用 Intent 过滤器更隐含),Action 很像 HTTP 动词(Get、Post等),Bundle 很像查询字符串参数或有效负载...等的列表。
与网页类似,您希望 Activity 能够自行处理。我的意思是,您不想在活动之间传递一些大的序列化对象,只需将给定记录的 id 传递给下一个活动并让该活动抓住使用数据库中的该 ID 记录(ContentProvider,其他一些持久源......)。活动也意味着松散耦合,您应该能够从各种路径导航到其中一个,这也使它们更易于重用。因此,允许 Activity 的调用者简单地提供一个 recordId 比 Activity 期望它的消费者提供一个大的序列化对象要容易得多。
底线 - 不,您不需要使用业务逻辑污染活动,将这些东西藏在应用层或网关或类似的东西中。至于持久性,ContentProvider 接口设计得非常好——我非常喜欢它。它还延续了 Android RESTful 主题,通过 URL 和动词(查询、删除、更新、插入)访问内容。
发送和接收意图很像发送和注册(类似于发布-订阅通道)命令消息(例如在分布式企业应用程序中,这是关于架构,而不是风格)。这种模式有助于设计一个松散耦合的交互应用系统。
我不记得在用于单台计算机上的组件和应用程序交互之前见过类似的架构,但它有助于使用其他应用程序设计应用程序以轻松构建功能/组件生态系统。