I have a question about whether to use View or Fragment with ViewPager.
Background: I have an Activity A that contains a ListView. Each ListView item opens Activity
A Fragment
is a useful approach, I think, when you want to tie some UI business logic to a particular View
(or group of). As you know, that individual Fragment
has its own lifecycle callbacks and so forth, just as an Activity
would.
Rather than having a single Activity
host many ListView
s through a single PagerAdapter
, it may be cleaner to use the Fragment
approach because the Fragment
only needs to deal with the logic behind driving a single ListView
.
This is a very similar situation to one I've just been facing. I'm showing various vertically scrolling forms (consisting of lots of input fields) within a ViewPager
. In my case I have gone for the Fragment
approach because in my case, it's possible that the ViewPager
will actually need to display a completely different kind of view on certain pages. For example, on the first few pages, user input forms might be displayed. But on the final page, a graph will be displayed. A whole separate set of logic is required to drive that graph. To drive those input forms and one graph from a single Activity
would get a bit messy, and I would probably need to contain the business logic in several delegate classes or something. So for me, Fragment
s were the obvious choice in the end. I have my InputFormFragment
and a GraphFragment
, and they each contain only the applicable logic for the View
s that they supply.
Another thing to consider is that in the near future you too may want to display a different kind of View
in your ViewPager
. Or, you might want to have another UI layout altogether, perhaps one that doesn't use the ViewPager
but displays them all side-to-side (e.g. a layout used on a large tablet in landscape mode). With Fragment
s, things are just far more modular and you could factor the code to do this quicker. If on the other hand you achieved your objective by using a single Activity
that contains a simple PagerAdapter
and all the logic for the ListView
s within, you might find it takes more work in the future to support new kinds of View
s or special tablet layouts.
One thing I will say is having implemented Fragment
s in a ViewPager
myself through FragmentPagerAdapter
and FragmentStatePagerAdapter
, things can get a bit awkward if you have any special requirements; managing Fragment
s can be tricky sometimes. For example, for my UI I needed to be able to programmatically add and remove the ViewPager
containing the Fragment
s. I also needed to ensure that the adapter in use didn't destroy Fragment
s once they had been shown, because I needed to collect data from all Fragment
s simultaneously at a certain point. Furthermore, I had to extend and modify FragmentPagerAdatper
to make sure that the Fragment
s go through their onDestroy()
properly and are removed from the FragmentManager
when the ViewPager
was removed.
Fragment
s enable a very modular way of constructing UIs for various screen sizes and orientations, and are excellent in how they allow you to encapsulate business logic and lifecycles for individual UI elements. However if your scenario really is just as simple as several ListView
s in a ViewPager
and you know that you will never need the modularity, then the overhead of Fragment
s could be an overkill.