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 little about android applications architecture, but I just couldn’t find a straight clear answer about which architecture I should use.

Some people suggested using MVVM – http://vladnevzorov.com/2011/04/30/android-application-architecture-part-ii-architectural-styles-and-patterns/

and others suggested using MVC, but didn’t specify how exactly it should be implemented.

As I said I’m coming from a WPF-MVVM background, and therefore I know it heavily relies on bindings which as far as I understand, are not supported by default in Android.

It seems like there is a 3rd party solution – http://code.google.com/p/android-binding/
But I don’t know if I’d like to rely on that. What if its development would stop and it will not be supported by future APIs and etc..

Basically what I’m looking for is a thorough tutorial that will teach me the best practices for building the application’s structure. Folders and classes structure and etc. I just couldn’t find any thorough tutorial, and I would have expected that Google would supply such a tutorial for its developers. I just don’t think that this kind of documentation handles the technical aspect good enough – http://developer.android.com/guide/topics/fundamentals.html

I hope I’ve been clear enough and that I’m not asking for too much, I just want to be sure about my application’s structure, before my code will turn into a spaghetti monster.

Thanks!

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!