Fragments seems to be overkill? No MVC architecture possible?

Question

i started with fragments a few days ago, but it seems wired for me. I dont see the justified advantage for the heavy increase of complexity. I dont know, if i should implement the functionality in my Activity or in my Fragment. First, i tried to put it in the fragments but that often seems to be not possible.

For example: I have a dialog as user input, after button click. So i transfered the button click via listener from fragment to activity and in the activity i opened the dialog. In the dialog I started new functions (so implementation in Activity). Android dev gives the hint to add a alert dialog in a fragment:

http://developer.android.com/resources/samples/ApiDemos/src/com/example/android/apis/app/FragmentAlertDialog.html

But this fragment still is implemented and heavy coupled with the activty (button action of the dialog is in the activity).

So Model and View are heavy mixed up. I dont see a additional value in such an hard to maintain, static code?!

Whats your opinion and advice about fragments?

Answer 1

When using Fragments, you can think of them as being the View and the Activity as being the Controller. In my personal opinion, Fragments was Google's knee jerk reaction to support tablets, and now we are stuck with them :(

I use fragments everyday, and I certainly feel your pain. When I first read about them I thought to myself, "this is really cool", but after using them, they fall short in so so many ways, but mainly because I would use them incorrectly :(

Here are some of pitfalls that I encountered...

1. Don't use onclick in your fragment layout, since it's the Activity and NOT the Fragment that will handle the click. If you use the attribute, and later you use the fragment in another Activity, then you'll have to remember to add the onclick method to that Activity as well. So, use a findViewById and then manually attach the click handler in the fragment's onCreateView.

2. When communicating with other Fragments, use the Activity as the controller to direct the message. (Lots of examples of how do this using interfaces). The key here is that if you are running multiple fragments on a device where one fragment will communicate directly with another fragment, then you run into some odd, but predictable behavior. For example if Fragment A directly updated a View in Fragment B, but Fragment B is not visible (because you've replaced it -- consider a phone), then when Fragment B is visible, then the View may not be updated, since the View is recreated. So, if you update a Fragment be sure to update the data in a fragment then update the View portions in the onCreateView which is called when the fragment becomes visible again (ie, you've popped the current fragment, you are now showing the previous one)

3. Don't build a complete application using only fragments. Instead build apps like you would normally, using Activities and then treat the Fragment has a glorified view (which it is). ie, design the App such that you have multiple fragments and multiple Activities, and some Activities may use more than 1 fragment.

My first thought with fragments was a one where I thought it would great to just build a complete app using fragments and one activity... I eventually finished the App, but I ran into so many issues using that approach. My next approach was to use multiple fragments and multiple activities and it went much better.

Bottom line is that Fragments are great if you use them as a View, but if you start trying to use them like Activities, then you are going to run into problems :( Think of the Activiy -> Fragment as the being the Controller -> View.

I also recommend that you read and understand the Fragment Lifecycle in addition to the Activity Lifecycle (Pro Android 4 has a great picture to represent it) and you'll save yourself hours of pain :)

Answer 2

Fragments provide the view logic so they are portable to other Activities. For the most part Activities are moving more into the role of a true Controller. In prior Android architectures the view logic and controller logic was mushed together because no one subclassed View to implement most of their app. They essentially did layout in the XML layout files, then pulled out the View objects directly in the Activity. So that meant the Activity was registering click listeners, key listeners, drag logic, etc. which is normally what you'd do in another subclass of View in other toolkits. Because they did this it meant that really cool dragging multi-touch gesture ListView you just coded was stuck in that one Activity. Now you want to use that again in another Activity. Well you're S.O.L. With Fragments you can more easily move that logic from the Activity into a Fragment. Now technically you could move it into a custom component View, but Fragments provide yet another advantage which is Fragments enable you to write applications that can run on tablets and smaller devices all the while varying the layout for each. It's tricky to understand how it works, but a single Activity can contain several Fragments with differing layout for each form factor. Something that a custom component can't accomplish nearly as easily. Plus custom components can't use layout files. You have to go full Java code something you don't have give up with Fragments.

I think the example you provided is a quick and dirty approach to designing Fragments. You could just as easily extract out the back reference (nest scope of this) by extracting an interface that the Fragment delegates to.