# Android Architecture: MV?

DevFeed: [Android Architecture: MV?](<https://devfeed.tech/articles/android-architecture-mv-26032.md>)

Original publisher: [Read original article](<http://doridori.github.io//Android-Architecture-MV/>)

Author: SystemDotRun

Published: 2015-04-01T00:00:00Z

Content type: opinion

Language: en

Sources: [SystemDotRun](<https://devfeed.tech/sources/systemdotrun.md>)

Topics: [Android](<https://devfeed.tech/topics/android.md>), [Code](<https://devfeed.tech/topics/code.md>), [mvc](<https://devfeed.tech/topics/mvc.md>), [Development](<https://devfeed.tech/topics/development.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [app-architecture](<https://devfeed.tech/tags/app-architecture.md>), [architecture](<https://devfeed.tech/tags/architecture.md>), [code](<https://devfeed.tech/tags/code.md>), [mvc](<https://devfeed.tech/tags/mvc.md>)

## AI overview

This article examines how MV* architectural approaches relate to Android development. It argues that placing most application logic in Activities and Fragments can produce code that is difficult to test, read, refactor, reuse, and maintain through configuration changes, and introduces several common Android architecture perspectives.

## Source excerpt

How do the MV* ways of thinking relate to Android? Why is this now such a popular way of thinking about Android architecture? The Problem I'm a contractor and I'm often brought on to projects have long since passed their first commit. I feel like I have had a good insight how to the average dev approaches Android app architecture from this, and also from open-source projects, android blog posts, the Android developer site and more. One thing that strikes me about most of the code I see is that there is not much of a notion of a clean, overarching application architecture. By this I mean that people seem genuinely happy to shoehorn their code into Activitys & Fragments with the occasional class named something like MyCrazyController. Why is this an issue? The problem with this is that it results in hard to test code hard to read code hard to refactor code hard to reuse code hard to handle-config changes code hard to write asynchronous code hard to not create loads of edge-case code (i.e. its buggy) hard to hand-over code Its an easy thing to fall into doing because ~99% of all Android examples are written in this way It sort of works most of the time there are framework classes (i.e. Loaders) and librarys (i.e. RoboSpice) around now to work around some of the issues that manifest from using this stock approach. While I have used these approaches in the past I find they can make a code base more complicated than it needs to be. People have got used to hearing that "Android is hard to test" or "just lock it to portrait" and "restart / reconnect to the web service call on rotation" and just think "well thats how it is" I admit, I would also include my past-self into this group, which is why I am here, attempting to atone for my coding sins and mine and others unknowingly devout following of the book of anti-patterns. How has this come to be? MV?, who's in control? I believe a big part of this is that not much thought has gone into the actual generic app architecture app