I was recently reading Fragments( haven't used this in my app though) and learnt that it can be used in phones app development.
I am thinking about using Fragments to implement MVC(model-view-controller) design pattern. Many argue that android development complies with MVC by default . But i do see Activities much like Views and there's definite lack of a controller when another activity is being/due to be launched. So i am thinking of using "Fragments" as "Views" with a single "Activity" as"Controller" and swap/add/remove the fragments as and when needed.
So my basic approach is like this.
1) The user interacts with the user interface (Fragments).
2) The controller (Activity) handles the event from the Fragments and passes it to a model(Backendthread / Service).
3) Model(Backendthread / Service) notifies the controller of models state change.
4) The controller (Activity) notifes the UserInterface(Fragments) which inturn notifies the User.
does my approach is rite or an unnecessary overhead or my perception about fragments is wrong?
IMHO, fragments are the controller. The fragment's basket of widgets represents the view. Activities are an orchestration layer, determining what fragments (and their widgets) are needed in a given circumstance (e.g., one on a phone, two on a tablet) but otherwise having limited business logic.
That being said, Android and patterns like MVC don't necessarily go together. I don't think that Google's intention was to create a pure MVC framework.