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
Related
This may sound stupid, but can I do that? I have searched a little, and this says "Re-attach a fragment ... causes its view hierarchy to be re-created, attached to the UI, and displayed.", probably meaning that the UI of the fragment is recreated losing states and other things.
The reason why I am trying to do is that I would like to achieve something like the Bottom Sheet of Google Maps. The only title part is showed at the bottom, but we can swipe it up and it becomes a Bottom Sheet. I think when only the title part is showing, it is not actually a Bottom Sheet, as it would be difficult to make exactly that part of a Bottom Sheet to be shown. I think Google Maps has put the title part separately, and is replacing it with a Bottom Sheet whose top part looks just like the title part, when swiping up begins.
So, to achieve similar effect, I thought I would create a cluster of UI as a fragment, and when the user begins swiping up, I place a Bottom Sheet with the peek size is set exactly to the height of the fragment, and move the fragment into the top of the Bottom Sheet, so that it can be swiped up.
But I want to keep everything of the fragment without recreating anything, as if I take the fragment and just move into the fragment instantly. Is that possible, or should I save the states and restore them when the fragment's UI is recreated?
Yes. Consider fragment as View and play with ObjectAnimator or any animation class as per behaviour. (Slide-up animation will do the trick)
Note: Fragment will initialize first even you display 20% of portion over main layout. State will remain same This does answers your question i guess.
Here is similar example for your work around. Reference
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.
I've got a problem that I'm having problems solving. My app has 2 types of fragments. When the app starts, a fragment with main menu is added to a FrameLayout that I use as a fragment container. This fragment takes up the entire screen. Then, when I choose one of the items in the menu, a corresponding fragment should be loaded into the container, replacing the menu. However, this fragment must only take 1/4 of the screen from the left, and the space outside is to be used by some other fragment.
I was thinking about making 3 FrameLayouts, one for the left side, one for the right and one for the entire screen, but this is going to have problems with fragment transactions, since I would have to keep tabs on which fragments are where and remove them by hand.
Basically what I need is some way to change whether my fragments are loaded into a container that takes up full screen, or a container that takes up only some part of the screen. I probably could do it with tons of trail and error and some code, but I bet there is a really easy way to do this in android that I missed.
Instead of trying to dynamically load these fragments into the various containers, I would suggest having two different Activities.
It sounds like the main menu fragment will only ever appear on its own in full screen. So, make that a full Activity (let's call it MainMenuActivity).
The second activity will have two FrameLayouts as it's contents, with one taking up 1/4 of the screen and the other taking up the remaining 3/4. Load this second activity upon choosing a main menu option and populate the fragments in onCreate() of the second activity.
Hitting the back button from the second activity will return the user to MainMenuActivity.
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.
TL;DR:
How should multi-pane apps with deep navigation similar to the Spotify iPad app look and work on Android, and how to implement this?
Long version:
I'm working on an app, where the user sees lists of items and can then delve deeper into these items. These item detail pages can again open lists of related items, that in turn have detail pages and so on. As a phone app, these would be separate Activities that might look and link to each other like this:
In the mock-ups, the user sees an initial overview and then selects "Item #2" from the first list. A new Activity opens up, showing him details for Item #2. Here, he selects to see a list of Things relating to Item #2. The newly openend Activity in the third picture shows this list, and clicking on one opens the details for this thing. He can navigate as deep into the content as he likes.
This works quite well with the usual Android Activities. I'm working on bringing the app to tablets and am thinking on how to best implement this. The plan is to create a multi-pane layout with the same concept. It is very similar to how the iPad Spotify app works (it will be interesting to see how they bring this to Android once they create tablet-specific layouts).
In the tablet layout, each click on an item or list name opens the corresponding child item as a new pane that animates in from the right. The same workflow as in the example above would look like this:
I'm unsure how to best implement this navigation pattern. Multi-pane apps with a limited navigational depth like GMail can be built with a static ViewGroup (LinearLayout would be ok) containing all fragments, and going deeper into the navigation replaces the content of the next container to the right and animates to this (see CommonWares implementation of this on SO).
This suggests that a custom ViewGroup would be the way to go. If it has to display a subpage (i.e. "List of Things"), then it creates a new child in the ViewGroup that is half as wide the screen with the fragment and then scrolls the visible area so that the pane that was just interacted with and the new child are visible. To link this correctly to a FragmentTransaction, so that the back stack works correctly, I'd guess it would be something like this:
View newPane = container.addChild();
FragmentTransaction ft = getSupportFragmentManager().beginTransaction();
ft.add(newPane, new ListOfThingsFragment(2));
ft.remove(paneOnRight, fragmentOnRight);
ft.commit();
container.animateToRight();
I don't see a way to do the animation within the FragmentTransaction.
Feedback welcome. My employer is generally favorable with respect to open sourcing frameworks we develop, so if this is something that is of broader interest and if I can come up with a reusable solution, I'd be glad to share it.
I had some research time and came up with a solution to this question (a question that I've wanted to see the solution for LONG time, even before you asked it).
I can't really show the whole code as there's some IP boundaries, but I'll put it here the main parts for this animation to works.
There're two key tools: setCustomAnimations and LayoutTransition
Yes, as far as I've been able to do it, you need to separate set animations to make it work.
So let's get to some code, you'll define your XML with a horizontal LinearLayout and make sure to include the following line on it.
android:animateLayoutChanges="true"
this will auto-generate a standard LayoutTransition which does translate the fragment/view that is staying in the layout and alpha (in or out) the fragment/view that is being included or removed from the layout. Give it a try.
So after this layout is inflated we gonna capture this LayoutTransition and trick it out to our needs:
LayoutTransition lt = myLinearLayout.getLayoutTransition();
lt.setAnimator(LayoutTransition.APPEARING, null);
lt.setAnimator(LayoutTransition.DISAPPEARING, null);
lt.setStartDelay(LayoutTransition.CHANGE_APPEARING, 0);
lt.setStartDelay(LayoutTransition.CHANGE_DISAPPEARING, 0);
with that code, we're removing the alpha animations and removing any delay from the transition (because we want all the translations to fire together).
And now it's just a few simple fragment transactions to make it work, during initialisation we inflate that layout and put a few fragments on it:
setContentView(R.layout.main); // the layout with that Linear Layout
FragmentTransaction ft = getSupportFragmentManager().beginTransaction();
ft.add(R.id.main, frag1, FRAG_1_TAG); // it's good to have tags so you can find them later
ft.add(R.id.main, frag2, FRAG_2_TAG);
ft.add(R.id.main, frag3, FRAG_3_TAG);
ft.hide(frag3);
ft.commit();
now on the transaction it's a simple:
FragmentTransaction ft = getSupportFragmentManager().beginTransaction();
ft.setCustomAnimations(R.anim.push_left_in, R.anim.push_left_out, R.anim.push_right_in, R.anim.push_right_out);
Fragment left = getFragmentManager().findFragmentByTag(FRAG_1_TAG);
Fragment right = getFragmentManager().findFragmentByTag(FRAG_3_TAG);
ft.hide(left);
ft.show(right);
ft.addToBackStack(null);
ft.commit();
final notes:
to make deeper navigation it's just a matter of firing FragmentTransactions to add fragments to the LinearLayout and hide or detach the left side fragment.
Also to make the fragments work on the linear layout is important to set their LinearLayout.LayoutParams.weight during runtime, something similar to the following code applied to the fragment view
((LinearLayout.LayoutParams) view.getLayoutParams()).weight = 1;
to make it work on phones as well it's just a matter of applying the common multiple screen support patterns.
last note, be careful on proper managing the layout status during device rotation because it's not all automagically handled by the system.
Happy coding!
We ran into the same problem with our app. The constraints we gave ourselves:
Dynamic numbers of panes
Each pane can be differently sized
Fragments inside of panes must be correctly retained on orientation changes.
In light of those constraints, we built a new layout we call PanesLayout. You can check it out here:
https://github.com/cricklet/Android-PanesLibrary
It basically allows you to easily add any number of dynamically sized panes and attach fragments to those panes. Hope you find it useful! :)
Partial answer to the animation part:
You can do animations with the FragmentTransaction:
ft.setCustomAnimations(android.R.anim.slide_in_left,
android.R.anim.slide_out_right);
Update: see this answer from Reto Meier himself about fragment animation: https://stackoverflow.com/a/4819665/1007169