Develop Reference

ScrollView vs RecyclerView for dissimilar children on Android

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.

reset Android FrameLayout object to "clean" state

I am trying to implement my own Android view recycling. My question is, is there a simple way to "reset" an Android View object (more specifically, a FrameLayout) to the state in which it would come out of a constructor. In other words, it knows about its context, but it's forgotten about things like calls to SetWillNotDraw, touch handlers, visibility, or anything else I may have set on it.
The alternative would be to write my own "reset" method. I'm concerned that if I go that route, I will end up with bugs relating to failing to reset some portion of the state.

No, there isn't. If you weren't trying to do recycling I'd suggest just creating a new one is the easiest way to ensure it. Its also not a very efficient thing to do in general- there's a lot of pieces of state that can be changed, if you try to set all of them you'll end up wasting a lot of cycles. Generally you have the code that sets these things have a reset method of some sort called when you unbind a view from its model, and it will clear the subset of things it changed.

When to use ViewStub vs Inflate?

The article http://android-developers.blogspot.in/2009/03/android-layout-tricks-3-optimize-with.html talks well about when to use View.
But I did not find a use case where I should replace the Inflate with ViewStub.
I didnot see any performance improvements when I replaced inflate with ViewStub.

Essentially ViewStubs just offer another way of doing things, or "achieving your goal". I find that you'll learn to use them when you are stuck and looking for help or another option. Otherwise if your code is doing what you want correctly without ViewStubs, then just forget about them for the time being.
There is no point forcing yourself to use extra options when you don't need them.
ViewStubs, in my own words, are "use once", temporary type of view holder. Use them when you want something to become visible on the screen only for that Activity's current life cycle.
There are other way you can accomplish that, but ViewStubs are very lightweights and simply offer a slightly different set of pros and cons compared to normal View objects.

Reuse inflated views

I am building a complex view based on dynamic data. Depending on the number of data elements in collections I am adding more views. Each of these subviews are complex and get inflated in the loop through the data collection.
This is of course inefficient and I would like to figure out a way to inflate the subview only once and then reusing them instead. Is this possible somehow?
PS: I do not want to build up the subviews in code (I know I could) because that would make things even messier due to the complexities and number of subviews, but if the performance would increase considerably I might take a look at that.
PPS: There is no visible performance problem but traceview that most of the time is spent inflating and if I can make it faster I would love to ;-)

you can check out the Google IO Session entitled 'The world of ListView'.
It explains very nicely how to prevent inflating the same view again and again, and how to reuse a particular view if it has been already inflated earlier.
Here is the link.
http://www.google.com/events/io/2010/sessions/world-of-listview-android.html
You can either download the .pdf file or view the video.
Hope it helps.
Regards,
Mahendra Liya.

Do root views of an Activity in Android have any prior knowledge of the child views that will be loaded into them?

Is there any way to query a root view of an activity for all of its child views even before the root view or its children have been inflated? I guess what I'm looking for is whether a view knows ahead of time what children it will have before it gets inflated, and can I get that list in some way. Bizarre I realize, but I think it will help me with some unconventional automation testing I'm working on. I haven't found anything in the API like this, so I'm hoping the community knows something spiff that will help.
Thanks!

I doubt it.
An Activity doesn't have any knowledge of its view (it just has its root window) until you call setContentView() in the onCreate() method.
There is a construct called ViewStub which allows you to delay inflating certain parts of the UI until you need them, but even then you wouldn't actually know anything about the child views until you inflate it.
Something else that may be of interest is the ViewTreeObserver and its subclasses. That allows you to receive notifications when a view hieararchy is changing.
Your test automation certainly does sound unconventional. Intriguing :)