I want to implement two fragments, splitting the screen. But one of the fragments should have the ability to grow to full screen by pressing a button (and from full screen resize back to its original size).
All related posts are very old and point to deprecated android features.
Also, it is not clear to me if I need to resize the fragment container and the fragment itself, or just the fragment container.
Any insight will be appreciated.
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.
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.
I am trying to create a layout in an activity that will look different in landscape and portrait, however it will contain the same sections, just in different places on the screen.
Most examples I find on fragments is always the list and detail, which is not what I'm looking at.
In my example I have, amongst others,
a scrolling image section (carousel)
a page title with some brief details
a carousel of thumbnails
two buttons
full details of the page
Now in the landscape layout, the image section will always be on the left side with down the right side, the page title, carousel of thumbs, two buttons and full details.
In the Portrait the title will appear at top, with image carousel beneath, then thumbs, then buttons etc.
The way it works in my head, is that each section should be a fragment, and then depending on the layout file in the respective res/layout folder corresponding to land/port, the fragments are arranged accordingly. But I'm also thinking is each section a whole fragment? Or could it be a separate view that get's loaded in, but just in a different order depending on the screen orientation.
I hope that made sense?
Does anyone have any good tutorials that explain exactly when you should and shouldn't use fragments. All the usual suspects just list the list/detail example, which is not applicable in my case.
tl;dr Can I use fragments as modules/blocks in various layouts or should I just create other layouts and display them inside the main layouts.
Fragments can be used to have split screen and to store previous state unlike views. It is difficult to manage back button with views
If you just want to change how the screen is laid out, the answer is neither. You can define orientation-specific resources (either a separate layout file for each orientation or different dimensions/constraints for each orientation) and the system will just provide you with the correct resource set for the current orientation.
That said, it sounds like you may be describing a modified version of master/detail flow. If this is the case, fragments are a good way to go since the landscape view is actually several separate screens in the portrait version of the app, so each section needs it's own state and lifecycle, which fragments provide.
Now, I know you said you wanted an example beyond a list and detail view, so here's some more details on when to use fragments:
Fragment, like activities, have state and lifecycle. Custom views do not have lifecycle and are completely dependent on the activity or fragment containing them.
You might use a custom view when you have a widget on screen that is used in multiple places and is just like any other view – bound to the activity when the layout is inflated and controlled from there. It's a way to either reduce duplicating combinations of views in your layout or to draw a custom view that doesn't exist yet.
Fragments are good when you need some state or lifecycle for a section of the app that might get used in multiple places or shouldn't be logically connected to the activity it is contained in. If you use the new Navigation Component, you actually just define one activity and then each screen in the navigation tree is a fragment that gets swapped out as the user navigates around the app. Here each child component on the screen (each "screen" that the user navigates to) has it's own lifecycle, business logic, etc, so mixing the code for all of that in the activity wouldn't make sense.
So the question comes down to what you are trying to build, and this may be a case where the best way to learn the difference is to try each option out as bit. The differences become more clear with practice using them. As a general rule of thumb, personally, I only really use custom views when I am trying to make a new view that doesn't exist elsewhere. If what I'm trying to do is simply a matter of laying out existing views in a new way, the answer is probably some trick in the layout file or layout code inside the activity. If I'm trying to make a stand-alone piece of the app that does stuff, especially if it also appears in multiple places in the app, I'll probably be building a fragment.
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.
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