I have run into an issue I'm having difficulty to resolve, and am looking for some ideas:
Solo.clickOnView is implemented as:
waiter.waitForView(view, SMALLTIMEOUT);
clicker.clickOnScreen(view);
The problem I have is that waiter.waitForView does not ever "see" the PhoneWindow$DecorView that I have just retrieved as the active window. Consequently, the waiter loops for the full 10 second timeout period and then proceeds to click the view successfully.
I see 2 problems:
1) I'd like to be able to use the Clicker directly if at all possible, and/or
2) Shouldn't ViewFetcher.getAllViews() return the top-level DecorViews and non-DecorViews Views? Currently it only returns the child Views of these top-level Views.
I have seen this same problem on an Emulated Android 2.3.3 AVD, and on a real device running Android 4.0.x.
In ViewFetcher.getAllViews we proceed to retrieve all WindowDecorViews, we separate out all nonDecorViews, and then we proceed to recursively addChildren of all these Views, but we don't actually add these top-level views themselves to the ArrayList of allViews.
So waitForView never matches the View (DecorView) I passed in.
However, if I modify getAllViews, then I get what I believe is "all" views (normal behavior?):
if (views != null && views.length > 0) {
View view;
for(int i = 0; i < nonDecorViews.length; i++){
view = nonDecorViews[i];
try {
addChildren(allViews, (ViewGroup)view, onlySufficientlyVisible);
} catch (Exception ignored) {
}
add ==> if(view != null) allViews.add(view);
}
view = getRecentDecorView(views);
try {
addChildren(allViews, (ViewGroup)view, onlySufficientlyVisible);
} catch (Exception ignored) {
}
add ==> if(view != null) allViews.add(view);
}
return allViews;
So, my question becomes: Is there a reason that getAllViews does not actually store the top-level DecorViews and nonDecorViews as valid Views to be returned in its array?
Carl Nagle
SAS Planning, Operations and Strategy
Software Quality Tools and Infrastructure
Carl....@sas.com