mirror-github-minimalbible/MinimalBible.github.io
1
0
Fork 0
mirror of https://github.com/MinimalBible/MinimalBible.github.io synced 2024-12-21 06:08:19 -05:00
Code Issues Releases Wiki Activity

Change ordering and slight content modification

Browse Source
This commit is contained in:
Bradlee Speice 2014-05-24 00:58:23 -04:00
parent 0f9db8d550
commit 956de461b6
1 changed files with 5 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
_posts/2014-05-23-more-than-you-ever-wanted-to-know-about-listview-caching.md → _posts/2014-05-23-zmore-than-you-ever-wanted-to-know-about-listview-caching.md
View File

@ -10,8 +10,6 @@ image:
comments:
share:
---
More than you ever wanted to know about ListView caching
========================================================
Unless you wanted to know a *lot*
---------------------------------
@ -20,7 +18,7 @@ So, I ran into some interesting issues with `ListView` caching in trying to get
Why does HolderView work anyway?
--------------------------------
One of the first questions I had about HolderView was why it actually worked. I mean, if classes are not static any more, they're being garbage collected when they go out of scope. And if they're being garbage collected, I'll have to keep on re-creating them, and I'm back to having the issues the [ViewHolder and HolderView]{% post_url 2014-05-23-viewholder-vs-holderview %} were designed to solve in the first place.
One of the first questions I had about HolderView was why it actually worked. I mean, if classes are not static any more, they're being garbage collected when they go out of scope. And if they're being garbage collected, I'll have to keep on re-creating them, and I'm back to having the issues the [ViewHolder and HolderView]({% post_url 2014-05-23-viewholder-vs-holderview %}) were designed to solve in the first place.
Well, to understand why `HolderView` works you need to know a bit about how the `ListView` operates in the backend. Long story short, when you scroll through elements, the `ListView` recycles things from the top of the screen down to the bottom. Think of it like a [climbing wall treadmill](http://www.hammacher.com/Product/Default.aspx?sku=12219). This way, you don't have to store every single element of the list, and you don't have to create them either.
@ -43,7 +41,7 @@ if (convertView == null || convertView.getTag() == null)
{% endhighlight %}
View recycling leaves views partially initialized
-------------------------------------------------
-------------------------------------------------
Now, this last piece is a very nasty issue I had seen [ever since adding](https://github.com/MinimalBible/MinimalBible/commit/b04d6c67ae0324cfaa12c3d17b2815fe08936658) the initial `ProgressWheel` (took 3 days to get it fixed). What was happening was that when I showed the `ProgressWheel`, individual rows in the `ListView` would have the wheel displayed when I had never clicked them!
@ -51,4 +49,7 @@ Well, there wasn't ever really an a-HA! moment in trying to fix this, but by the
What happens is that the views get re-cycled when you scroll down, but the bind method never *explicitly* set the state, or inflated the layout. Thus, the view that was given already had the `ProgressWheel` showing even if the item hadn't actually clicked on it. After the fix above, everything started working again.
Conclusion
----------
I hope that answers any questions you may have about the `ListView`. I think the component is challenging to use, and if you don't really understand the optimizations it does, things get very strange and confusing very quickly. But now you know enough of how everything is laid out in memory to be efficient yourself! Go forward and write great code!