ViewAction

interface ViewAction

Known direct subclasses

AdapterDataLoaderAction, CloseKeyboardAction, EditorAction, GeneralClickAction, GeneralSwipeAction, KeyEventActionBase, OpenLinkAction, RepeatActionUntilViewState, ReplaceTextAction, ScrollToAction, TypeTextAction

`AdapterDataLoaderAction`	Forces an AdapterView to ensure that the data matching a provided data matcher is loaded into the current view hierarchy.
`CloseKeyboardAction`	Closes soft keyboard.
`EditorAction`	Performs whatever editor (IME) action is available on a view.
`GeneralClickAction`	Enables clicking on views.
`GeneralSwipeAction`	Enables swiping across a view.
`KeyEventActionBase`	Enables pressing KeyEvents on views.
`OpenLinkAction`	Invokes onClick of a link within a TextView (made with Linkify or via another method).
`RepeatActionUntilViewState`	Enables performing a given action on a view until it reaches desired state matched by given View matcher.
`ReplaceTextAction`	Replaces view text by setting `EditText`s text property to given String.
`ScrollToAction`	Enables scrolling to the given view.
`TypeTextAction`	Enables typing text on views.

Known indirect subclasses

KeyEventAction, PressBackAction

`KeyEventAction`	Enables pressing KeyEvents on views.
`PressBackAction`	Performs an Android press back action

Responsible for performing an interaction on the given View element.

This is part of the test framework public API - developers are free to write their own ViewAction implementations when necessary. When implementing a new ViewAction, follow these rules:

Inject motion events or key events via the UiController to simulate user interactions.

Do not mutate the view directly via setter methods and other state changing methods on the view parameter.

Do not throw AssertionErrors. Assertions belong in ViewAssertion classes.

View action code will executed on the UI thread, therefore you should not block, perform sleeps, or perform other expensive computations.

The test framework will wait for the UI thread to be idle both before and after perform() is called. This means that the action is guaranteed to be synchronized with any other view operations.

Downcasting the View object to an expected subtype is allowed, so long as the object expresses the subtype matches the constraints as specified in getConstraints.

Summary

Public functions
`Matcher<View!>!`	`getConstraints()` A mechanism for ViewActions to specify what type of views they can operate on.
`String!`	`getDescription()` Returns a description of the view action.
`Unit`	`perform(uiController: UiController!, view: View!)` Performs this action on the given view.

Public functions

getConstraints

fun getConstraints(): Matcher<View!>!

A mechanism for ViewActions to specify what type of views they can operate on.

A ViewAction can demand that the view passed to perform meets certain constraints. For example it may want to ensure the view is already in the viewable physical screen of the device or is of a certain type.

Returns
`Matcher<View!>!`	a `Matcher` that will be tested prior to calling perform.

getDescription

fun getDescription(): String!

Returns a description of the view action. The description should not be overly long and should fit nicely in a sentence like: "performing %description% action on view with id ..."

perform

fun perform(uiController: UiController!, view: View!): Unit

Performs this action on the given view.

Parameters
`uiController: UiController!`	the controller to use to interact with the UI.
`view: View!`	the view to act upon. never null.