I am having a situation in which as a List Item I want to inflate a Fragment, but It seems like a bad approach. As Fragments are processed/managed by Activity's FragmentManager or by child FragmentManager and list item views are by ListView & ListAdapter.
Any comments and research regarding this would be highly appreciated.
Thanks
Here are my views and questions in mind on your problem.
You want to use ListView with fragments, since you already have a fragment which does that job and you dont want code to become redundant.
Though you can definitely use fragment, but i suppose its not the best practice. Fragments have their own life cycle and you are not going to use fragment life cycle methods (I suppose). Thus semantically it would not fit into this usecase.
And also your adapter will always be dependent on activity to retrieve fragments. (could there be any problems with orientation change again?)
List items and adapters are finetuned to work really well with scrolling really long lists. While the list view items get recycled when using view holder pattern, while scrolling, does any of fragment lifecycle methods come in between? would that cause performance impact. (I suppose yes. Havent tested it out yet)
You can instead have your view code in different layout file and include this layout in both fragment and also list adapter.
<include layout="#layout/YOUR_COMMON_VIEW_CODE"/>
and have utility class which takes the context and this layout container. Have all the functionality exposed inside that utility class.
You can't use fragment as list item views because the API doesn't allow you - View and Fragment aren't even related so there's no way you can use it like that. Make custom views and use adapter getViewTypeCount and getView to use different list item behavior.
Fragment are managed by Activity's FragmentManager or by other Fragments child FragmentManager; while list item views are managed by ListView & ListAdapter. You can use ListViews in Fragments, but not the other way around.
I googled and got this.
Related
I am a little bit confused on how should I approach this particular case of doing some swipes between fragments.
So yea, I asked ViewPager or RecyclerView, because these 2 are my only options, if anyone can come up with a better idea, it is really welcome.
The flow is the following, I have a Main Timeline(ListView), each item of it opens a fragment with details about it. What I would actually want to do is to swipe between these full screen fragments without going back to MTL and open another item of the list.
You would ask me what I tried, well:
RecyclerView - HORIZONTALLY oriented as a root of the fragment, and each item of this RV had the details of each event. The problem with this is that it gets really buggy because I have a huge logic inside each item(like, another RV - horizontally , a PagerView also horizontally to swipe between images (or a youtube frame that is being played if is the case. Plus a lot of other stuff in this, so the logic of parent RV inside the onBindViewHolder() is really tricky.
Would be better to use a PagerView with fragments(since I have the DetailsFragment kind of ready) ? The problem here is that I need a certain number of swipes, right ?
Go with viewpager.
Because creating fragments inside recyclerview causes recyclerview performs to slow down.Also to create fragments in onBindViewHolder() dynamically every time you need different unique id of frame layout to load which will be tough to generate.
For more information on why recycler view is bad idea to load fragments check this.
Fragment replacing in RecyclerView item
Also try to use the ViewPager with an implementation of FragmentStatePagerAdapter. The adapter will optimize the memory usage by destroying fragments that are not visible at a given moment.
Check the documentation for details and code sample.
https://developer.android.com/reference/android/support/v4/app/FragmentStatePagerAdapter.html
I'm working on an app that has like ten or more listviews across different activities, each of them uses a different adapter with a different data model and item row layout.
When you click on a row, the app shows a fragment with the details, nothing new.
My question is about the best approach to do this.
I could create ten fragments with a listview and ten fragments with a
details layout.
Or I could always use the same fragment and use a
different adapter and inflate a different details layout, depending
on a TAG, for example.
Another way for the details fragment could be
containing all the layouts in one, showing only the one I want and hiding the rest.
I also could implement a base fragment and extend it changing the layout in the children.
So my question is not about coding this, is about the cleanest and efficient way to do it.
Is it better to reuse one fragment or have multiple files?
Is it better to have a lot of files with a little code or a reusable file with a lot of code?
Thanks
I'd like to first note that this is my first ever proper android app I'm making (I've only followed tutorials so far), so please be detailed in your answers and forgive me if I'm spouting nonsense :).
I'm trying to create an app where the main activity is going to be a TabLayout, and in one of the tabs I want to have a fragment that is a list which you can scroll up and down, and also I would like each element in the list to have multiple interactive elements (like two different buttons for example).
My first instinct was to go with a ListFragment because each element of the list will be a fragment that you can program to do whatever you want. However when following tutorials I found that ListFragments seem to be rather tricky, and I'm not sure if I can make it work with a TabLayout.
I've looked for other methods, but I've only found the kinds of solutions that allow you to have a list of just plain views, not fragments.
So what should I do? Is there a way you could make a ListFragment work with a TabLayout and I'm just being silly, or is there a better way to do this?
My first instinct was to go with a ListFragment because each element of the list will be a fragment that you can program to do whatever you want
The contents of a ListFragment will not be fragments. It is possible that the contents of a ListFragment will represent model objects for which you plan on showing other fragments elsewhere in your UI.
I'm not sure if I can make it work with a TabLayout
A ListFragment can be used inside or outside of a TabLayout. I would not think that a ListFragment inside of a TabLayout would be particularly more troublesome than any other sort of fragment.
Your ListFragment problems will come from:
I would like each element in the list to have multiple interactive elements (like two different buttons for example).
ListView, which underlies ListFragment, is tricky to use with interactive elements in list rows. As your design sounds rather unusual, you might wish to consider using other UI patterns rather than multiple buttons in list rows. If you insist upon this design, you may find RecyclerView to be a bit easier in the long run, even if it is more challenging at the outset.
I've only found the kinds of solutions that allow you to have a list of just plain views, not fragments
That's the only thing you are ever going to find, in all likelihood. Again, ListFragment is a fragment that contains a ListView. ListView rows are not fragments, whether the ListView is contained in a Fragment or not. The only thing that I have ever heard of that is designed for vertical scrolling of fragments would be the various vertical ViewPager implementations floating around.
I have a quiz app with two fragments, for the two quiz modes I have, within a ViewPager. For each fragment, in addition to other things, I dynamically create a list by inflating linearlayouts from XML within a while loop iterating through all the categories. This layout which contains this list is identical in both the modes, it is the rest of the fragment that is different, hence requiring two separate pages.
The problem therefore is that I do this costly process of inflating layouts twice, once within each fragment. I would like to do this only once and use it twice.
Two solutions I've considered:
Using an adapter in the parent activity, accessing this through the
fragments and subsequently using a ExpandableListView.
Problems:
I use checkboxes to select categories. The two fragments deal with clicks differently. With my limited knowledge I have no clue how achieve this. I understand that I can inflate a custom layout but then how do I set a listener in the fragment?
Some of my categories are grouped, others are standalone items. How do I remove the arrow in these items?
.
Using an arraylist in the parent activity. Accessing this in each fragment and adding the layouts to the parent this way.
Problems:
Cannot do this as I'm adding the same view twice so I get an error as the specified child already has a parent. (IllegalStateException)
However this does mean I can easily access the CheckBoxes and iterate through settings oncheckedchangedlisteners
Thank you so much in advance :) If you require any more information or anything else just ask!
I dynamically create a list by inflating linearlayouts from XML
within a while loop iterating through all the categories.
This suggests a ListView.
Using an arraylist in the parent activity. Accessing this in each
fragment and adding the layouts to the parent this way.
This solution will not work from the start, because you have the two fragments in a ViewPager which imposes a different behavior. If the fragments weren't in the ViewPager you could build a mechanism for storing those views in a list followed by dynamically detaching//attaching them from the fragments views. But storing the views in a list(and having them in memory all the time) plus the headache of managing their status isn't worth it.
Using an adapter in the parent activity, accessing this through the
fragments and subsequently using a ExpandableListView.
Why use only one adapter and not two, one for each fragment(so they are independent)? I would also implement the adapter in the fragment itself.
I use checkboxes to select categories. The two fragments deal with
clicks differently. With my limited knowledge I have no clue how
achieve this. I understand that I can inflate a custom layout but then
how do I set a listener in the fragment?
Not quite sure, but if you're talking about accessing the CheckBoxe from a "row" layout and having different behaviors on user actions based on the two fragments, you could very easy implement a base adapter class. That base adapter class will handle the common logic, but you'll also have an abstract method called on a CheckBox action(in the OnCheckedChangeListener). The two subclases(for the two fragments) of that base adapter will each implement that abstract method with their own logic independent from each other.
Some of my categories are grouped, others are standalone items. How do
I remove the arrow in these items?
Like above, this can be done by implementing a smart adapter.
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.