Is it possible to achieve interaction between fragments described in this image:
So, if one touches (or preferably swipes vertically) on fragment B, it shows (or is replaced by) fragment C and changes size to accommodate the larger fragment. Fragment C will contain a viewPager with additional fragments that are revealed on horizontal swipe (this part is done).
Fragment B will display the crucial contents of fragment C, which is why I want a separate fragment to do this. Fragment A takes user input and should always be interact-able.
I need help wrapping my head around how this should be implemented.
Related
I've been trying to write code which will allow me to swipe back and forth between 3 DialogFragment views which overlay the main Activity.
To be more specific, each view should be swipeable from left to right and vice versa across the entire UI, in much the same way as fragments are in a ViewPager (with limits set at the bounds like so | 1 <--> 2 <--> 3 |) . Like fragments in ViewPager, each DialogFragment should come to rest in a natural position at the centre of the screen after swiping, and the transition animation should be similar.
Ideally, the layout and functionality would be similar to the respective defaults of a DialogFragment overlaying an activity.
Initially, I attempted this with a ViewPager but ran into trouble as the fragments didn't display with the intended layout. The main problem I had here was that the ViewPager stretched the layout of the DialogFragment across the entire UI. Furthermore, the only option I found for resizing the layout of the fragment was to limit the boundaries of the ViewPager, but of course this meant that the transitions occurred in an area smaller than the UI rather than across the entire UI. Mike's provided a brief explanation why this happens in the comments below.
I've also attempted a different approach of creating a child DialogFragment within blank ViewPager fragments. However, so far I've been unsuccessful as the ViewPager functionalilty isn't operational while the child DialogFragment is visible.
In the case of a 'work around' solution things that I want to mimic from the DialogFragment view include:
The shadowed / darkened background outside of the DialogFragment view.
The ability to tap outside of DialogFragment view to close the DialogFragment view (and by extension the ViewPager) and return to the main activity.
Right now I've Fragments A with Recyclerview - where I've categories (Image+text).
I want to make Fragment B with Recyclerview - where I've types (Image+text). Same layout, same everything except text/image.
Like this:
https://img.exs.lv/e/z/ezeliitis/frags.png
For instance, I click on Fragments A - first picture (Cars) and it opens Fragments B - in same layout as fragment A, which contains (AUDI, BMW, OPEL ect...). Should I just make copies of fragment A (adapters/viewholders ect.) changing db names/pictures or is there some way to "DRY" the code? Also, isn't it bad having two recyclerviews (performance) ?
Also, movement from one fragment to another is called fragments "..."(what exactly?)
Same layout, same everything except text/image
You must need to replace the RecyclerView adapter, then. No need to start another Fragment, but you're more than welcome to.
isn't it bad having two recyclerviews (performance) ?
Not that I know of. You'd only have one at a time, from what I understand anyways.
movement from one fragment to another is called fragments "..."(what exactly?)
If you do need to switch Fragments, then you want the FragmentTransaction class of the host Activity. That's how you switch. Documentation is pretty good with its example.
https://developer.android.com/training/basics/fragments/communicating.html
I am trying to read RSS feed and show the content of it in card view which is inside ViewPager with tab layout. It shows fragment with data initially, but when swiped back from another tab, the whole card layout with data,disappears.
I had to handle the same situation. I had TabLayout in ViewPager.
I have used FragmentPagerAdapter with off screen page limit set to (NO_OF_TABS - 1). This is to hold all the fragments in memory and they wont be destroyed and recreated as you swipe back and forth. As my fragments are small in size meaning not many views every fragment has so it was okay for me. But this way fragments always holds the latest data. Say, if user had entered text in EditText and swipe to end and come back, then fragment will still have the text that user had entered.
In your case, if you have not set the page limit the default is 1 so the fragment gets destroyed when you swipe away so you lose the data.
IN ADDITION TO ABOVE:
If you can not keep all fragments in memory, you may consider using FragmentStatePagerAdapter. This adapter saves the states of fragments that are being destroyed and it will use the same state to represent in fragment when user swipe back to this fragment. But there are issues around StaePagerAdapter while it destroys adn recreate the fragments, there are indexing issues so you will easily get IndexOutOfBoundException if you swipe. This is with page screen limit set to less than the total fragments.
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.
in my Activity, I have a layout containing 3 FrameLayouts, one at the top, one at the left and one at the "center".
Now, I sometimes only want to display one or two of them. Atm I am doing it this way:
FrameLayout frame = (FrameLayout) findViewById(R.id.framelayout_menu_left);
frame.setVisibility(...);
frame = (FrameLayout) findViewById(R.id.framelayout_content);
frame.setVisibility(...);
frame = (FrameLayout) findViewById(R.id.framelayout_menu_top);
frame.setVisibility(...);
However this can get really ugly results, e.g. when I switch the "content" Fragment and hide the top and/or left FrameLayout. It all starts flickering as the "content" Fragment jumps to the top and/or left and only afterwards is replaced.
Also, I can obviously not navigate back to another setup, so is there any other way to do this?
Kind regards,
jellyfish
Edit:
Maybe a little drawing makes my question clearer...
A shows a Layout of 3 FrameLayouts containing 3 different Fragments. Each color represents one distinct Fragment.
Now what I want to do is to switch from A to D.
I am doing this by replacing the blue Fragment with the yellow Fragment via a FragmentTransaction.
However, this still keeps the other Frames visible, so I hide them via the code above.
Now, Frame.setVisibility() is called way before commit(), so in B and C the blue Fragment "jumps" to the left and the top and only afterwards (in D) is replaced with the yellow Fragment. This produces a nasty flickering.
As a workaround, I now hide all three FrameLayouts before the transaction and re-show the ones I need once the transaction has finished. But there still is the problem that I can't go back via the back button as this isn't a real transaction.
I would have two suggestions. Firstly, if you both add a fragment transition effect and do the visibility changes after the transaction, that would probably substantially reduce much of your flicker effect
ft.setTransition(FragmentTransaction.TRANSIT_FRAGMENT_FADE);
Secondly, I've simply given up on having the system manage the fragment stack for me -- it seems that this only works well with simple transactions. Override onBackPressed and do your own logic there.
--randy