Composite Views and View Controllers_问答_开发者

I'm somewhat new to Android and am in the process of designing an application with a couple fairly complex views. One of the views is intended to involve a complex view displaying information associated with model objects and segregated into several different views; the navigation of which is meant to be achieved using sliding effects (i.e. sliding one's finger across the screen to traverse from one screen to the next, etc). The view itself will be used to host multiple sets of views for varying types of model objects, but with a general structure that is reused between them all. As a rough example, the view might come up to display information about a person (the model object), displaying several details views: a view for general information, a view displaying a list of hobbies, and a view displaying a list of other individuals associated with their social network. The same 开发者_高级运维general view, when given a model object representing a particular car would give several different views: A general view with details, A view containing photo images for that vehicle, a view representing locations which it could be purchased from, and a view providing a list of related cars. (NOTE: This is not the real data involved, but is representative of the general intent for the view). The subviews will NOT cover the entire screen real-estate and other features within the view should be both visible and able to be interacted with by the user.

The idea here is that there is a general view structure that is reusable and which will manage a set of subviews dynamically generated based upon the type of model object handed to the view.

I'm trying to determine the appropriate way to leverage the Android framework in order to best achieve this without violating the integrity of the framework. Basically, I'm trying to determine how to componentize this larger view into reusable units (i.e. general view, model-specific sub-view controllers, and individual detail views). To be more specific, I'm trying to determine if this view is best designed as a composite of several custom View classes or a composite of several Activity classes. I've seen several examples of custom composite views, but they typically are used to compose simple views without complex controllers and without attention to the general Activity lifecycle (i.e. storing and retrieving data related to the model objects, as appropriate). On the other hand, the only real example I've seen regarding a view comprised of a composite of Activities is the TabActivity itself, and that isn't customizable in the fashion that would be necessary for this.

Does anyone have any suggestions as to the appropriate way to structure my view to achieve the application framework I'm looking for? Views? Activities? Something else?

Any guidance would be appreciated. Thanks in advance.

I'm trying to determine the appropriate way to leverage the Android framework in order to best achieve this without violating the integrity of the framework.

Phones have very limited RAM and very limited CPUs. Your average Android device has the power of a decade-old PC, or worse. Please do not over-engineer your application.

To be more specific, I'm trying to determine if this view is best designed as a composite of several custom View classes or a composite of several Activity classes.

I'd argue "none of the above". If you are aiming to make "custom View classes" for distribution to the Android developer community at large, that's one thing. For your circumstance, though, just build your Views -- don't subclass them. I am definitely of the "composition over inheritance" mindset when it comes to Android's View system.

IMHO, Activity is your controller (or perhaps presenter, a la MVP, is the better architectural analogy), layout XML and their constituent Views are the view layer, and your database is your model.

I'm not sure that I followed all that you were saying there, a diagram showing the flow might help, but..

You generally can only have one Activity visible at a time. That activity is responsible for rendering the entire view. The only exception to that that I have seen is a pop-up, alert style window. In my experience those tend to be a bit slow though. Typically you have a new activity every time you change pages. It sounds like in your case it might be every time the general view changes.

You can, however, easily have a few layouts that are reused in various activities. Layouts are composable, so you can, for example, have one layout for your detail layout that gets included in the main layout.