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.
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.findRootsshould 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.