Android 架构设计 - 如何正确设计？
一个好的 Android 应用程序架构是什么样的？所有“工作/业务逻辑”是否都应该在后台服务中完成，并且活动仅与服务通信以从某处（本地/远程）查询/获取数据？
您会将 Activity 调用的“服务”实现为真正的 Android 服务吗？或者一个 POJO-Singleton 来完成这项工作（可能使用后台线程）。或者在您的活动中实例化后台线程以执行耗时的操作（查询 Web 服务）。
如何以正确的方式抽象数据访问？您会使用 ContentProvider 来访问/提取您的数据吗？应该如何/从哪里查询？活动？服务？ ..？
我试图寻找一个好的应用程序架构设计，但我只找到了Android架构的样子，而不是Android应用程序应该是什么样子。
那么你对此有何看法？ Android 应用程序的哪些组件应该相互通信以确保最佳的可扩展性/封装......？
how does a good architecture for an android app look like? Should all the "work/business logic" been done in a background service and the Activity communicates just with the service to query/fetch data from somewhere (local/distant)?
Would you implement the "service" that the Activity calls as a real Android-service? Or a POJO-Singleton that does the work (perhaps using background threads). Or instantiate background threads in your activity for time-consuming actions (query a webservice).
How do you abstract your data access the right way? Would you use a ContentProvider to access/abstract your data? How/From where should it be queried? Activity? Service? ..?
I've tried to search for a good app architecture design, but I only found how the Android architecture looks like, not how an Android app should look like.
So what's your opinion about that? What components of an Android application should communicate which each other to ensure best extensibility/encapsulation,...?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这个问题没有人回答。好的面向对象设计并不是 Android 特有的。我想说的规则是 - 如果框架为您提供了适合您的用例的高级对象（例如 Android 中的 Service），请使用它。如果您发现自己使用该框架免费获得的东西在 POJO 实现中实现，那么就使用该框架。
就关注点分离而言，这是标准的 OO 内容。不要在 Activity 类中放置任何不是 Activity 工作的内容。用活动所需的方法和属性过度填充活动但实际上并不是活动的工作是不好的 - 使您的活动的意图难以理解。
我通常将应用程序中的内容分成子包。
等。
就应用程序内的通信而言...
我总是有一个在清单中注册的自定义应用程序类。这样，当我有需要成为“单实例”的控制器和助手时，我不必做所有那些疯狂的线程安全单例的事情......我只保留一个全局副本。
RoboGuice 是一个依赖注入框架，它使这一切变得更容易完成......绝对值得研究。如果您对此感兴趣，RoboGuice 的 Google 群组很棒，并且不断充满该框架的创建者，他们基本上可以回答您需要的任何内容。
就应用程序内通信而言，我使用单实例控制器和状态类来保存状态并执行常见任务，并且我通常使用 BroadcastIntents 从服务与活动进行通信
There's no one answer to this question. Good OO design isn't Android specific. I'd say that the rule is - if the framework gives you a high level object (such as Service in the case of Android) that fits your use case, use it. If you find yourself making POJO implementations of the same things you get for free with the framework, go with the framework.
As far as separation of concerns, this is standard OO stuff. Don't put anything in your Activity classes that isn't the job of the Activity. Over-stuffing the Activity with methods and properties that the Activity needs but aren't really the job of the Activity is bad - makes the intention of your Activity hard to understand.
I usually separate stuff into sub-packages in my apps.
etc.
As far as communication within your app...
I always have a custom Application class that I register in the manifest. This way, when I have controllers and helpers that need to be a "single instance", I don't have to do all that crazy thread safe singleton stuff...I just keep one global copy of.
RoboGuice is a dependency injection framework that makes this even easier to accomplish...definitely worth looking into. If this interests you, the Google Group for RoboGuice is great and is constantly filled with the creators of the framework who can basically answer anything you need.
As far as in-app communication, I use my single instance Controller and State classes to hold state and do common tasks, and I usually use BroadcastIntents to communicate back to Activities from Services