Maybe there was something Android specific?

i'll look for the change. the listcell packed with a Node hierarchy seems a little heavy to me. If there are 1million listcells filled with data (your add) and you followed it up with 1 million deletions, it would be nice if the onlything left where empty listcells

android Intents have the concept of pre pause and pre destroy methods

and onResume

after the pause

@ron yeah don't worry about it...i don't feel like playing with the finalize() either

meant to be able to bundle state and store that

@edvin looking forward to the ViewModel too. i think that's a big tornado selling point

@carlw Yeah, it really solves a lot of those awkward chicken/egg cases 🙂

Heck, it was fast, I did it now 🙂

@User uploaded a file: Untitled

Now all the binding is done in init. The load function is renamed to updateItem and all it does is rebind the new item to the view model.

This in combination with the new TodoItemListCell uses a lot less resources and does a lot less work when the list cell items change.

@User uploaded a file: Untitled

Gotta run, checking back in later tonight 🙂

@carlw Just want to make this clear as it seems like you still misunderstand. Even with a million items there are never a million list cells. There is never more cells than the number of cells that fit on your screen at once. That's what I demonstrated earlier 🙂

I'll try to get a better test case. I think they buffer to allow for smooth scrolling.

i was playing around with something similar a few months ago with TableView in this blog post http://bekwam.blogspot.com/2016/04/javafx-tableview-load-time-with.html

we had a large list that wasn't being reclaimed

@carlw: The VirtualFlow creates just the number of nodes needed to display on screen, then updateItem is called when a cell is to display a different item. It's that simple, unless you cache nodes externally, then you can run into trouble.

i have to step away to troubleshoot something...don't worry about the cache for now. if i have time i'll try to write some code demonstrating what I think is going on or nothing if I'm way off base

Hehe, OK :)

I'm with you on the # of ListCell's. It's capped to the viewable items plus a few extra. The problem I alluded to was the items supporting the ListView and how they may not get reclaimed right away

@carlw Yeah, that's where it's possible to shoot oneself in the foot 🙂 But the safest thing you can do is tie your scene graph to the cells. A one-to-one relationship will never have any problems 🙂

I was just running a test, adding and removing 10000 x 100k items and the memory didn't get reclaimed even after running gc

list cache out of the way...do you want me to add the ViewModel a few comments ago or do you have something that I can pull?

@carlw The memory you are talking about is for the items, not nodes, at least if you used my code above. Yeah, you can just copy that, I haven't made any other changes to it 🙂

yes...definitely the items

The cache would not solve that anyways 🙂 But if you clear the backing list it might get GC'ed earlier. Not an issue for this app in any case though 🙂

Gotta get to bed, long day tomorrow. More painting.. bah 🙂