Develop Reference

How to use an activity component in different fragments with viewpager

I have an activity with 5 fragments. i'm using different functionalities on the same component's onClick inside different fragments. because of viewpager's fragment preloading, functionality of next fragment is executed instead of current fragment. what should i do?

There is no way to avoid it because of view pager has minimim offset is 1.
So I would suggest to you using another way to archive your result:
Idea 1: If you are using FragmentStatePagerAdapter second parameter as FragmentStatePagerAdapter.BEHAVIOR_RESUME_ONLY_CURRENT_FRAGMENT, it means only one fragment inside your view pager will be in onResume state. Therefore you could start all of your networking/side effects job in onResume method.
Idea 2: Why do you using view pager, when you do not need swipe left/right effect? Probably you are in the wrong way. You could use for example just frame layout, then with your fragment manager attach and detach fragment when a user interacts how you expected. I would advise you to look better at FragmentTransaction. Here is a link.
Feel free to ask me about one of these approaches.

Android: one fragment turning into two fragments on one page

I have an activity that has within it one fragment that takes up the whole screen. At some point in the app flow, the user can go to another screen in the same activity that is composed of two seperate fragments. So you can imagine it as:
Fragment A (100% of the screen) -> Fragment B (50%) + Fragment C (50%)
I can think of two ways of doing this and neither one of them is particularly good. The first is to set a layout for the activity that has in it one container that will hold Fragment A, and then have Fragment A open subfragments B and C inside it. I'm trying to avoid using subfragments because it leads to unusual lifecycle bugs and it also isn't supported by all version of the api.
The second way is to have two layouts for the activity - one layout having a single container, and the second one having two containers and then switch between them at the appropriate moment with setcontentview. I have to admit that I'm not too happy about that solution either, since it means the user will see the screen redraw white instead of a nice transition effect.
Does anyone have any suggestions on how to do this most efficiently? Note that I do want everything to remain under one activity - logically it should be this way. There's no logical point in having two seperate activities for this UI movement.

solved by having two containers and setting the top one to wrap_content height, visibility=invisible and not populating it at all. When I need to move to the two pane setup I populate the invisibile container and set it's visibility to visible which causes it to remeasure. When moving back from the two pane to the single pane call remove on the fragment that populates the top pane.

Multiple fragments or nested fragments

I am writing an android app that will have a number of different screens that I would like to swipe between, each screen will be a full page except for action bar header. On each screen there is the ability to open up another screen which will also be multiple screens that I would like swipeable. What is the best way to handle this. Do I have one fragment manager that holds all the screens and handle the onPageScrollStateChanged to only allow swipes between the current accessable screens or would I be best off nesting the fragments. I hope the above makes sense.
Thanks in advance

Sounds like you want to use a ViewPager to to swipe between views (Fragment extends View)
You could either:
In a single activity use a FragmentManager that switches between the parent and child Fragments, each with their own ViewPager and nested Fragments
Start a new activity to hold each ViewPager
Both are valid, if the Fragments need to communicate with each other or the Activity option one might suit the project needs better.

For the swiping between views you indeed need a ViewPager
For the nested fragments I would use a wrapper. I struggled a lot with fragments and found that this is the best way. A wrapper is very simple. This is just a fragment that holds other fragments. In the onCreate() of this fragment you get the childFragmentManager and add the fragment you originionally wanted to add. If you want to go to a new fragment you simply get the childFragmentManager again and replace the current item. This way you have nested fragment. You can add this to the backstack in order to get back navigation, but you need to override onBackPressed() inside your activity and call the method popBackStack() from the fragmentManager in order to get the first fragment back.
If you have any questions, comment below.

Fragment stack: push/pop Fragments from top fragment

Support4Demos feature Fragment stacks... but conveniently place the pop/push CountingFragment controls outside of the stack (all takes place in one layout, but the push/pop buttons are below, still in the Fragment that holds the whole layout.
How can the controls be made to work from the top fragment?
[EDIT]
Another way to look at it:
I want to make Fragments on a stack behave like Activities, each can pop itself, or launch another.
How would you alter the "FragmentStack" example from Support4Demos so that the "Go home"/"Add new"/"Pop top" buttons are in the CountingFragments, rather than in FragmentStackSupport which holds the FragmentManager?
A reasonable design - consider "CountingFragments" containing clickable ListViews?
How to do that? Ideally, each stack Fragment would hold a reference to the "stack holder' Fragment, or its (Child)FragmentManager. Those, however, are not Parcelable, and Fragment constructors must not be used (though everything else works great when I do it). Holding a reference to that is also bad, since the "stack holder' Fragment, too, can be destroyed and recreated.
[EDIT2]
All right, here are some ideas I came up with.
For "go home" and "pop top", I suppose I could add those (invisible) buttons to the hosting Fragment, and then access them in the hosted Fragments via getWindow().getDecorView().findViewById or somesuch.
That's ugly enough. But pushing new ones? Only related thing I can think of is adding a custom View class into the hosting layout, that holds a reference to the FragmentManager, to be grabbed by the hosted Fragments.
holding references to the FragmentManager(s) in a static map somewhere
register a BroadcastReceiver in the hosting Fragment, send broadcasts with data from the hosted ones, telling it what to do. But the host Fragment shouldn't have to babysit its children.
Have each stacked Fragment itself be host to either its true content, or the next stacked Fragment. That way, there is always a FragmentManager at hand (except for popping), but 2 fragments are needed per page, not to mention the weirdness of it all.
Please tell me there is a cleaner way.

Use View or Fragment in ViewPager

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 B. Activity B shows different content depending on which ListView item is tapped in Activity A.
Activity B's content is shown inside a ListView.
Question:
Now, instead of going back and forth between Activity A and B to switch contents, I have a requirement to implement horizontal view swiping to switch contents all within Activity B.
One solution I found (tried it and it works) is to create many instances of Activity B's ListView and use it with ViewPager + PagerAdapter.
Another potential solution found on the doc (haven't tried it) is to bring that ListView into a Fragment, create many instances of the fragment and use it with ViewPager + FragmentPagerAdapter or FragmentStatePagerAdapter.
My question is, what's the benefit of using each approach? Should I go through all the trouble of bringing the ListView into Fragment or just simply use ListView with ViewPager?
Thanks

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 ListViews 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, Fragments were the obvious choice in the end. I have my InputFormFragment and a GraphFragment, and they each contain only the applicable logic for the Views 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 Fragments, 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 ListViews within, you might find it takes more work in the future to support new kinds of Views or special tablet layouts.
One thing I will say is having implemented Fragments in a ViewPager myself through FragmentPagerAdapter and FragmentStatePagerAdapter, things can get a bit awkward if you have any special requirements; managing Fragments can be tricky sometimes. For example, for my UI I needed to be able to programmatically add and remove the ViewPager containing the Fragments. I also needed to ensure that the adapter in use didn't destroy Fragments once they had been shown, because I needed to collect data from all Fragments simultaneously at a certain point. Furthermore, I had to extend and modify FragmentPagerAdatper to make sure that the Fragments go through their onDestroy() properly and are removed from the FragmentManager when the ViewPager was removed.
Fragments 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 ListViews in a ViewPager and you know that you will never need the modularity, then the overhead of Fragments could be an overkill.