We're currently trying to get some UI Tests up and running with our solution, and the Xamarin documentation states that we should be able to attach the StyleId
attribute which will then be passed through to the AccessibilityIdentifier
in iOS.
Looking in the auto-generated AppDelegate
class, we can see the code that supports this bridge:
Forms.ViewInitialized += (object sender, ViewInitializedEventArgs e) => {
if (null != e.View.StyleId) {
e.NativeView.AccessibilityIdentifier = e.View.StyleId;
}
};
Using StyleId
on a standard element (e.g. Entry contained in a ContentPage) works fine, but we are unfortunately not seeing StyleIds passed through to a ToolbarItem
when expressed in XAML or in code. The page structure here is standard - a NavigationPage
containing a ContentPage
with it's ToolbarItems
collection populated.
<ContentPage.ToolbarItems>
<ToolbarItem StyleId="AddSubscriptionButton" Icon="plus.png" />
</ContentPage.ToolbarItems>
or
this.ToolbarItems.Add (new ToolbarItem () { Icon = "plus.png", StyleId = "AddSubscriptionButton" });
After stepping through, it's clear to see that a breakpoint set on the event hook in the AppDelegate does not get fired. Evaluating the tree shows that instead of the native AccessibilityIdentifier
being set to the StyleId
, it appears to be set to the icon path - e.g. "plus.png" in the above scenario.
In practice you could locate these buttons in a UITest by accepting that the identifier is always set to the icon path, but this is far from ideal.
I spared some time to investigating use of a custom NavigationRenderer
to try to hook into where these toolbar buttons are added to the TopViewController, with the view of setting the AccessibilityIdentifier
to the StyleId
at this point, but limited renderer access appears to squash this plan.
The closest clues I found are this post which interacts with native toolbar buttons but has no way to retrieve the StyleId from the Xamarin.Forms.ToolbarItem
s, ( @anton.5994 ) and this post where someone is attempting to add buttons to the bottom toolbar on iOS instead of the top ( @SvenKuntz ).
After some more research, it appears that this issue has not only manifested in ToolbarItems, but other components also. ( @SKall )
On a slightly broader level, can anyone offer insight as to why the Forms.ViewInitialized
event is the driving force for setting StyleId
s, when this doesn't appear to get fired for some native view elements?
In my view, setting the AccessibilityIdentifier
to the StyleId
on the correct element (important!) should be a responsibility of each Renderer
as this is the only area holding enough understanding for both the native elements and the underlying XF view implementation to determine when and to which element to set the identifier.