You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
View scanning is performed on the main thread by Radiography.scan. However, finding view roots, via ScanScope.findRoots(), is performed on the calling thread. Some view roots need to run on the main thread or a view-specific thread.
findRoots should get documentation calling out that it can be called on any thread, and the current code should be guarded to make sure it's running on the correct thread. One tricky bit about this is that view scanning is done lazily, via sequences, so scopes that perform operations on sequences need to make sure that's running on the appropriate threads. This could get complicated since sequence items don't include any information about which view they're processing or which thread needs to be used to access that view. Is this laziness really necessary? Would be a lot simpler to do things eagerly, so we don't have to plumb all the information about threading through the system.
I think this might be causing test flakes, so I changed the UI tests to run scan() on the main thread in 03f09c9 for #120. However, this is still a potential issue in production, so we should solve it for real.
The text was updated successfully, but these errors were encountered:
View scanning is performed on the main thread by
Radiography.scan
. However, finding view roots, viaScanScope.findRoots()
, is performed on the calling thread. Some view roots need to run on the main thread or a view-specific thread.findRoots
should get documentation calling out that it can be called on any thread, and the current code should be guarded to make sure it's running on the correct thread. One tricky bit about this is that view scanning is done lazily, via sequences, so scopes that perform operations on sequences need to make sure that's running on the appropriate threads. This could get complicated since sequence items don't include any information about which view they're processing or which thread needs to be used to access that view. Is this laziness really necessary? Would be a lot simpler to do things eagerly, so we don't have to plumb all the information about threading through the system.I think this might be causing test flakes, so I changed the UI tests to run
scan()
on the main thread in 03f09c9 for #120. However, this is still a potential issue in production, so we should solve it for real.The text was updated successfully, but these errors were encountered: