Android application architecture - MVVM or MVC?

Question

I got an android project I\'m beginning to work on, and I want its structure to be as robust as possible.

I\'m coming from a WPF MVVM background and I\'ve been reading a

Answer 1

First of all, Android doesn't force you to use any architecture. Not only that but it also makes it somewhat difficult to try to follow to any. This will require you to be a smart developer in order to avoid creating a spaghetti codebase :)

You can try to fit in any pattern you know and you like. I find that the best approach will in some way get into your guts as you develop more and more applications (sorry about that but as always, you'll have to make lots of mistakes until you start doing it right).

About the patterns you know, let me do something wrong: I'll mix three different patterns so you get the feeling of what does what in android. I believe the Presenter/ModelView should be somewhere in the Fragment or Activity. Adapters might sometimes do this job as they take care of inputs in lists. Probably Activities should work like Controllers too. Models should be regular java files whereas the View should lay in layout resources and some custom components you might have to implement.

---

I can give you some tips. This is a community wiki answer so hopefully other people might include other suggestions.

File Organization

I think there are mainly two sensible possibilities:

• organize everything by type - create a folder for all activities, another folder for all adapters, another folder for all fragments, etc
• organize everything by domain (maybe not the best word). This would mean everything related to "ViewPost" would be inside the same folder - the activity, the fragment, the adapters, etc. Everything related to "ViewPost" would be in another folder. Same for "EditPost", etc. I guess activities would mandate the folders you'd create and then there would be a few more generic ones for base classes for example.

Personally, I have only been involved in projects using the first approach but I really would like to try the later as I believe it could make things more organized. I see no advantage in having a folder with 30 unrelated files but that's what I get with the first approach.

Naming

• When creating layouts and styles, always name (or identify them) using a prefix for the activity (/fragment) where they are used.

So, all strings, styles, ids used in the context of "ViewPost" should start be "@id/view_post_heading" (for a textview for example), "@style/view_post_heading_style", "@string/view_post_greeting".

This will optimize autocomplete, organization, avoid name colision, etc.

Base Classes

I think you'll want to use base classes for pretty much everything you do: Adapters, Activities, Fragments, Services, etc. These might be useful at least for debugging purposes so you know which events are happening in all your activity.

General

• I never use anonymous classes - these are ugly and will drive your attention away when you are trying to read the code
• Sometimes I prefer to use inner classes (compared to create a dedicated class) - if a class is not going to be used anywhere else (and it's small) I think this is very handy.
• Think about your logging system from the beginning - you can use android's logging system but make a good use of it!