[ASTableView, ASCollectionView] Directly creating the *view variants may create a cycle with *node.

[singno]

[appleguy]

@singno Thanks for the report! I could debug this very quickly if you have a runnable example app. I have tested memory in the many apps in examples/, and am not aware of any current issues.

Could you post your sample app somewhere for me to try, or simply put it in a .zip file and email it to me at asyncdisplaykit@gmail.com ? That would be awesome!

[singno]

@appleguy Thx for a quick reply. The example app has email to you.

[appleguy]

@singno I believe I understand the problem now. Your test app was helpful and allowed me to do detailed memory debugging quickly.

This is a recent issue I caused as I am trying to get as much of the logic out of ASTableView and ASCollectionView as possible, and move it into ASTableNode and ASCollectionNode. The reason is that these two classes will then share a common superclass (something like ASRangeScrollingNode), a big step forward for the cleanliness and flexibility of this important architecture.

Unfortunately it looks like there is, internally, a strong pointer to the view from the node - even though I had taken measures to avoid this, they were insufficient - and if users create ASTableView directly, then it must have a strong pointer to the underlying ASTableNode that it creates (or it will be deallocated immediately).

The quickest fix that I recommend, and should be safe to always depend on, is to use ASTableNode and ASCollectionNode instead of the *View versions. This is also by far the best practice for being able to embed collections and tables inside one another. To do this, all you need to do is access the TableNode's .view property and add that as a subview of a view controller, or you could even put in -loadView something like "self.view = tableNode.view". You can also use [view addSubnode:tableNode], which accesses the .view property for you.

Let me know if you have any trouble with this. Thanks for emailing me.

[singno]

OK， I will try that later.

[appleguy]

This is fixed in 1.9.5.