I just need help cleaning up some information that doesn't make sense to me, with use cases if possible.
WHAT I UNDERSTAND:
With fragments in android, I understand that if you plan on replacing them you need to have a container view, preferably a FrameLayout, and add the initial fragment to the container during the activities onCreate method. But there is one thing that continues to not make sense to me.
WHAT I DON'T UNDERSTAND AND NEED HELP WITH:
What rules are there regarding where/how the container view is set up, if there are any. Android Developers site makes it look like the container view needs to be it's own XML layout file, but it doesn't say that and I have seen examples on here with FrameLayouts nested inside of your typical layout files, but they are all specific uses and I need to understand the rules of setting a container up.
There are no rules. You just need any ViewGroup -- position and size it however you want. When you add the Fragment into it, it will behave just as if you'd created the Fragment's View manually, and called yourViewGroup.addView(fragmentView).
FrameLayout is typically used just because it makes a good container with no real behavior (you just give it a size and position and let the fragment fill that container).
There's absolutely no need to make the container view its own layout file. In fact, if you want the Fragment to take over the content view of the entire Activity, you could even just add the Fragment to the Activity using the ID android.R.id.content.
Related
I am working on android application and some team members suggested using one activity and one parent layout for the whole application and each time we need a new screen we just inflate a new layout in the parent layout and destroy the old one.
I on the other hand think that using fragments would be the way to go.
Do you think one way is better than the other?
I would be grateful if you can think of solid arguments to support your claim.
Thank you
UPDATE:
We are using MVC in our application. They want to create a new class for the view while i opted for using the fragment as my view. As it stands now the application has one activity and one layout. To change the view we are calling the same layout,removing its child views and inflating the new view .I dont see how that would be better then just using the fragments as views
I think most Android developers will tell you to use one or more Activities or Fragments. But why?
Basically, because one Activity which is responsible for each and every View in your app would be something like a "god object". This is considered an antipattern, I suppose because it may fast become a maintenance nightmare.
The Android pattern of one Activity and several Fragments on the other hand is following the Single Responsibility Principle, so your code is easier to maintain. All the more so because Android-specific things like saving state on configuration change are much easier to implement if you are able to use the built-in methods.
I want to make it possible to display a fragment on top of every activity (if the right action is called). It should look like a window on top of everything. This works fine so far, but I am a bit confused about how to get the layout integration working.
When I wanted to display something like a fragment on top of everything, I had to use a RelativeLayout as the root element, then nesting maybe LinearLayout (containing the activity's layout) and fragment.
Is that the only way to achieve this? Do I have to refactor now every activity layout to use RelativeLayout as the base? Or is there a more straightforward way?
I cannot comment, so will write here. Please provide some code to express what you mean, much easier to understand it than. If i understood you correct, u want to have a window on top of another window?
Cannot see why this would be voted down, and not even a comment for the reason :/.
You might achieve what you want with an overlapping fragment. I have had this side effect when making my app, i.e. that a fragment view is transparent on top of another fragment. To achieve this, just skip if(savedInstanceState != null){return;} in your onCreate() in your activity. And instead of replacing a fragment (transaction.replace) use (transaction.add)
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.
So I have an activity whose layout contains a FrameLayout. This frame layout will be replaced with one of two fragments.
Fragment A will be shown on creation of the view, and there is a switch which when checked will switch to fragment B.
I am attempting to make the app as responsive as possible, however the first time the switch occurs there is a noticeable delay, probably due to rendering of the view, where as for subsequent switches the view is already cached or whatnot.
How do i go about getting fragment B view to render and cached while being hidden at the same time. Again this is for the initial switch, not subsequent ones so things like using hiding showing fragments instead of replace won't help.
This effect can be achieved by specifying android:visibility to "invisible" in the XML layout file or in the code by View.setVisibility(VIEW.INVISIBLE);
You are doing this wrong. First you need to find out what the culprit is, then optimize or fix. Profile your fragments' onCreateView() or other methods you are doing something in and find out what makes is crawl. Also be aware that devices vary, and your problem may ie be visible only on slowest devices available.
Here is article for about profiling Android apps
I am thinking of an app in which I will be programatically able to display some fragments according to metadata I have stored somewhere. Up to know, I have been able to find out, that each fragments lies in corresponding FrameLayout, or especially, when I create activity with one FrameLayout, I am able to store there only one Fragment at a time, no matter what kind is it. Problem is, however, with situation, when my metadata declares I have to put 3 fragments into my activity, while there is only one FrameLayout.
I see two possible solutions:
1) making several FrameLayout and in final stage, some of them will be used or not
2) somehow join multiple fragments to fit into one available FrameLayout
I don't like solutuion 1) and I don't know how to achieve 2). How to you see it? Is it possible to dynamically add multiple Fragments into activity with one Frame Layout?
In your situation where you require more number of Fragments to be added to your screen avoid using the FrameLayout, you will not be able to achive it. There are several factors that define how you layout multiple Fragments
Are all the fragments of the same size?
Should the fragments be place in a particular order?
First Create an empty parent layout (Layout class is left to your choice except FrameLayout). Next define your child view for your parent layout using a seperate xml file this file must contain your fragment place holder. Using the inflator inflate your child view and assign a Fragment to the inflated layout and eventually add it to your parent layout, through this way you can active what you are looking for. Just remember as you inflate your layout do mention its layout size so that you achive the kindly of layout you want.