[RTM] Removed dependency on setScrollableView**()#636
[RTM] Removed dependency on setScrollableView**()#636renaudcerrato wants to merge 2 commits intoumano:masterfrom renaudcerrato:remove_need_of_scrollable_view
Conversation
|
This is a bad idea. You are effectively going through the entire view hierarchy. The performance would be pretty bad for large list views. |
|
In 99% of cases, the scrollable view will be at the root. The main advantage is that the slidable content shouldn't have to be static anymore: the current implementation can't easily handle dynamic fragments as slidable contents... Using that simple trick, you can effectively swipe your content dynamically. BTW, that's how Flipboard's BottomSheet is doing. |
|
Interesting, I see your point. Though, as far as I can tell you are calling |
|
Sure, the performance will degrade if the scrollable view is deeply nested. But as I said, in 99.9% of cases the depth won't go above 1 or 2. IMO, the benefits of having dynamic contents are worth it. Now, I can use |
|
Ok, cool. Let me digest this and play around with it when I get home tonight. Thanks for the idea and the contribution! |
|
You're welcome! I'll stick with my fork until then ;) |
|
As a side note: we could add a simple switch to explicitly enable (or disable) that feature in case the user knows there will be no scrollable content. |
|
I'm still debating this. I tested it a bunch and I was really close to merging this, but then I thought about WebViews, which is where this approach doesn't work well. They could be really complex layouts with lots of children & sub children, which could lead to decreased performance. Thoughts? |
setScrollableView(View)and its matching xml attributeumanoScrollableViewmay easily be replaced by simply looping over the slidable view's childrens. This allow for a cleaner API, for example when working with scrollable fragments as slidable view.