I'm looking for any examples or (even better) tutorials that can help me accomplish this. But I keep coming up short in my google searches, which has me worried that it's not even possible. So that's my first question: Can an expandable listview inflate a fragment when it expands and call it's onDestroy when retracted? and if so, can you please link me to any help with accomplishing this. Thanks
Here's a little visual of what I'm looking to do:
first, the general UI paradigm could be handled with an ExpandableListView. whether this gives you enough to match exactly what you need is TBD.
as for having fragments inside the list ... theoretically, in the list view's adapter's getView() method, you could do a FragmentTransaction.replace(), passing in a container ID that exists in the inflated view. i have not tried this.
that being said, i seriously doubt this will work. list views are smart about managing views. the views in the list are often destroyed and re-created as the user scrolls the list. adding fragments to a view is an expensive operation.
as an alternative, you might consider a ViewPager, which can hold fragments by design. it's not the UI you have spec'd above, but it's a common UI pattern used by many stock Google apps, so you know it's been tested.
Related
I have a mix of 10-15 custom views and fragments to be shown in a vertical list. I am not sure if RecyclerView has any advantage in scenarios where all views are dissimilar. RecyclerView seems to add lot of boiler-plate code, and I think the only advantage I would get is easier enter/exit animation.
My custom views/fragment also make web-service call on being created. We don't cache web-requests for business reasons. My understanding is that RecyclerView would trigger these web-service calls on each binding, resulting in redundant calls and visible latency. Comparatively ScrollView should load the views once, and it keeps them all in memory, avoiding multiple calls.
Is my understanding correct ? I need some help understanding performance implications with ScrollViews, in the given scenario.
ScrollView
With a ScrollView, all of its subviews will be created at once, regardless of visibility on screen. If using a ScrollView for your solution, you'll probably want to "listen" for when its subviews become visible to update their content, using placeholders initially. You could also build something that will fetch the content in a background thread. This may get more complex than you want very quickly.
RecyclerView
A RecyclerView provides the advantage of deferring creation of child views until they become visible automatically, and can re-use child views with common layouts.
By using different "item view types" for each of your children, you'll disable the "recycling" part of RecyclerView, but still get the benefit of deferring the creation of views until they are scrolled into view.
RecyclerViews do provide a fairly structured pattern for you to work with via the Adapter and ViewHolders. Though not personally familiar with it, RecyclerView also has a RecyclerView.ViewCacheExtension which is intended to give the developer control over caching of views.
Overall, the advantage of late binding (don't create and load views that might never be viewed) and the flexibility of the RecyclerView will probably yield good results for you.
First of all you have to decide what you are using View or Fragment or maybe both. Don't compare View with Fragment there is a common misconception about these two, they are not similar, actually a Fragment is close to an Activity in terms of architecture and implementation.
Second, can you reuse some of these View/Fragment, if yes, then RecycleView can help you a lot.
After you decided about the topics above:
My understanding is that RecyclerView would trigger these web-service
calls on each binding
No, this is not true, the binding method is called whenever a new item is displayed (reused or newly created), you can implement adapter to perform the web API only once on an item, this is your choice.
I always go for RecycleView/ListView whenever possible, it helps to reduce the memory footprint and can reduce the implementation. In some cases, where there is no huge memory usage on views and I can't reuse some of the implementation, then I go for ScrollView, but I think twice before implementing it.
Suppose I have RecyclerView with hundreds of items. There are a few different view types. When I click on an item it has to change its UI. As I see it there are two options:
change the item to a different view type and notify the adapter that it changed so that it can inflate a new view to display the new state.
have both views in a single xml file. only one is visible at any time. Toggle between them using the setVisibility function when the state changes.
there are a lot of articles online about heterogeneous RecyclerViews using lots of view types, but i have yet seen one about the best practices when item views dynamically change and the RecyclerView becomes more heterogeneous over time.
which method is best to change an existing view in a recycler view? what are the tradeoffs?
The tradeoffs are pretty obvious.
Both UIs in a single View: depending on your views, this might:
Make the Views heavy to inflate and layout
Slow down the binding process, since you have to bind both UIs
Eventually, lag down the scrolling process.
On the other hand, you have a fast, precise control over what Views should change appearance at a certain time. Having both UIs in the same place allows for finer animations and transitions between one state and another.
Different View types: I think your case is not why view types were created in the first place - they are meant for having different childs at the same time, in different positions of the list. This:
Might slow down the transition. You have to be extremely careful on how you tell the adapter to reload the objects. As you can read anywhere, you might want to avoid notifyDataSetChanged(), which reloads any object, and rather use notifyItemChanged() or such. This requires some work and attention.
Does not allow (not easily, at least) for visual transition between one state and another.
The answer is that, IMO, only you can know. You should ask yourself:
Are these Views complex? Do they have a deep hierarchy? Would having both of them reduce performance (e.g. in the binding part)?
Would it be easy to understand which views are changed, and call notifyItemChanged(int position) in the second case? Reloading the whole dataset has a huge impact on performance, if you have lots of items.
Do you need some visual transition between one state and another? Maybe you want both UIs to fit into a single container (like different informations in a CardView)? If this is mandatory, then option 1 is better.
Do you have more than 2 UIs? If so, I would go with view types, so as not to host too many views in a single child layout.
and similar questions.
I am creating an Android application that will mainly consists of ListViews in each activity. What I hope to achieve is a mechanism that will check to see if network connectivity is present and if so then then the data should be retrieved and supplied to the ListView. If there's no data present or the internet connection is unavailable then a seperate view should be loaded.
Which way is most efficient do to this. So far I have seen answers about using a ViewSwitcher or Viewflipper but I am not sure that's the right approach. Should I use fragments and then load a particular fragment based on the condition that was met? I just need some advice on how to accomplish this.
Have you considered just swapping the adapter? This question might be of some use to you.
I guess you might add some kind of factory method that will decide what adapter to instantiate depending on connectivity availability. Thus you will control both the data to be used and the appearance of list entries (I assume you will be using some custom extension of one of the existing adapters).
The best way is going to be to use the emptyView that's provided as part of the AdapterView base class. You just set the adapter as per usual, but if no data is retrieved (i.e. your adapter's data source is empty) you will show the empty view in place of the list. This empty view can be anything you want it to be.
As #Ivan says you should consider setting adapters in a dinamic way.
And about the fragments thing, only consider using independent fragments (or ListFragments) for this if you are going to re-use that fragments in other activities to avoid code duplication.
I am having trouble using an ExpandableListView because the type of childItems in each group varies greatly. In one section there are contacts from the phone box, another has a view with a progressBar in and the last one has a TextView in.
I have thought about using 3 individual ExpandableListViews, each with their own adapter and handlers, but this seems a bit crazy too, particularly when some of the 'lists' only have one item in and it never changes. Essentially I am using ExpandableListViews to create expandable sections in my UI, and it doesn't really feel right.
Is there a better UI element to use?
If they are completely distinct like it sounds like they are, you may want to look into using Fragments. It's a lot of new stuff you learn if you're not familiar with them, but you can then easily reproduce the collapsing mechanic using Animations coupled with hiding the Fragments. This also decouples the 3 UI elements (contacts, progress bar, text view) from each other, so you can reuse the Fragments pretty much anywhere you want.
Is there a way to call BaseAdapter.notifyDataSetChanged() on a single element in the adapter.
What I am trying to do is update the data and reflect those changes in the containing ListView. The problem is that sometimes the change is so small that it seems ridiculous that I have to refresh the whole view rather than the single item in the view that has been updated.
I am not aware of such method. If it's really important, you can always find individual item view to update. But I don't think that it worth it as Android is pretty efficient in updating list views. So it will not do much extra work (definitelly not going beyond items currently visible on the screen).