StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>I tried using both the <a href="https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller" rel="noreferrer">model–view–controller</a> (MVC) and <a href="https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter" rel="noreferrer">model–view–presenter</a> design patterns for doing android development. My findings are model–view–controller works fine, but there are a couple of "issues". It all comes down to how you perceive the Android <code>Activity</code> class. Is it a controller, or is it a view?</p> <p>The actual <code>Activity</code> class doesn't extend Android's <code>View</code> class, but it does, however, handle displaying a window to the user and also handle the events of that window (onCreate, onPause, etc.).</p> <p>This means, that when you are using an MVC pattern, your controller will actually be a pseudo view–controller. Since it is handling displaying a window to the user, with the additional view components you have added to it with setContentView, and also handling events for at least the various activity life cycle events.</p> <p>In MVC, the controller is supposed to be the main entry point. Which is a bit debatable if this is the case when applying it to Android development, since the activity is the natural entry point of most applications.</p> <p>Because of this, I personally find that the <strong>model–view–presenter</strong> pattern is a perfect fit for Android development. Since the view's role in this pattern is:</p> <ul> <li>Serving as a entry point</li> <li>Rendering components</li> <li>Routing user events to the presenter</li> </ul> <p>This allows you to implement your model like so:</p> <p><strong>View</strong> - this contains your UI components, and handles events for them.</p> <p><strong>Presenter</strong> - this will handle communication between your model and your view, look at it as a gateway to your model. Meaning, if you have a complex domain model representing, God know what, and your view only needs a very small subset of this model, the presenters job is to query the model and then update the view. For example, if you have a model containing a paragraph of text, a headline and a word-count. But in a given view, you only need to display the headline in the view. Then the presenter will read the data needed from the model, and update the view accordingly.</p> <p><strong>Model</strong> - this should basically be your full domain model. Hopefully it will help making your domain model more "tight" as well, since you won't need special methods to deal with cases as mentioned above.</p> <p>By decoupling the model from the view all together (through use of the presenter), it also becomes much more intuitive to test your model. You can have unit tests for your domain model, and unit tests for your presenters.</p> <p>Try it out. I personally find it a great fit for Android development.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload