FocusNode class

An object that can be used by a stateful widget to obtain the keyboard focus and to handle keyboard events.

Please see the Focus and FocusScope widgets, which are utility widgets that manage their own FocusNodes and FocusScopeNodes, respectively. If they aren't appropriate, FocusNodes can be managed directly, but doing this is rare.

FocusNodes are persistent objects that form a focus tree that is a representation of the widgets in the hierarchy that are interested in focus. A focus node might need to be created if it is passed in from an ancestor of a Focus widget to control the focus of the children from the ancestor, or a widget might need to host one if the widget subsystem is not being used, or if the Focus and FocusScope widgets provide insufficient control.

FocusNodes are organized into scopes (see FocusScopeNode), which form sub-trees of nodes that restrict traversal to a group of nodes. Within a scope, the most recent nodes to have focus are remembered, and if a node is focused and then unfocused, the previous node receives focus again.

The focus node hierarchy can be traversed using the parent, children, ancestors and descendants accessors.

FocusNodes are ChangeNotifiers, so a listener can be registered to receive a notification when the focus changes. Listeners will also be notified when skipTraversal, canRequestFocus, descendantsAreFocusable, and descendantsAreTraversable properties are updated. If the Focus and FocusScope widgets are being used to manage the nodes, consider establishing an InheritedWidget dependency on them by calling Focus.of or FocusScope.of instead. FocusNode.hasFocus can also be used to establish a similar dependency, especially if all that is needed is to determine whether or not the widget is focused at build time.

To see the focus tree in the debug console, call debugDumpFocusTree. To get the focus tree as a string, call debugDescribeFocusTree.

Lifecycle

There are several actors involved in the lifecycle of a FocusNode/FocusScopeNode. They are created and disposed by their owner, attached, detached, and re-parented using a FocusAttachment by their host (which must be owned by the State of a StatefulWidget), and they are managed by the FocusManager. Different parts of the FocusNode API are intended for these different actors.

FocusNodes (and hence FocusScopeNodes) are persistent objects that form part of a focus tree that is a sparse representation of the widgets in the hierarchy that are interested in receiving keyboard events. They must be managed like other persistent state, which is typically done by a StatefulWidget that owns the node. A stateful widget that owns a focus scope node must call dispose from its State.dispose method.

Once created, a FocusNode must be attached to the widget tree via a FocusAttachment object. This attachment is created by calling attach, usually from the State.initState method. If the hosting widget is updated to have a different focus node, then the updated node needs to be attached in State.didUpdateWidget, after calling FocusAttachment.detach on the previous FocusAttachment.

Because FocusNodes form a sparse representation of the widget tree, they must be updated whenever the widget tree is rebuilt. This is done by calling FocusAttachment.reparent, usually from the State.build or State.didChangeDependencies methods of the widget that represents the focused region, so that the BuildContext assigned to the FocusScopeNode can be tracked (the context is used to obtain the RenderObject, from which the geometry of focused regions can be determined).

Creating a FocusNode each time State.build is invoked will cause the focus to be lost each time the widget is built, which is usually not desired behavior (call unfocus if losing focus is desired).

If, as is common, the hosting StatefulWidget is also the owner of the focus node, then it will also call dispose from its State.dispose (in which case the FocusAttachment.detach may be skipped, since dispose will automatically detach). If another object owns the focus node, then it must call dispose when the node is done being used.

Key Event Propagation

The FocusManager receives key events from HardwareKeyboard and will pass them to the focused nodes. It starts with the node with the primary focus, and will call the onKeyEvent callback for that node. If the callback returns KeyEventResult.ignored, indicating that it did not handle the event, the FocusManager will move to the parent of that node and call its onKeyEvent. If that onKeyEvent returns KeyEventResult.handled, then it will stop propagating the event. If it reaches the root FocusScopeNode, FocusManager.rootScope, the event is discarded.

Focus Traversal

The term traversal, sometimes called tab traversal, refers to moving the focus from one widget to the next in a particular order (also sometimes referred to as the tab order, since the TAB key is often bound to the action to move to the next widget).

To give focus to the logical next or previous widget in the UI, call the nextFocus or previousFocus methods. To give the focus to a widget in a particular direction, call the focusInDirection method.

The policy for what the next or previous widget is, or the widget in a particular direction, is determined by the FocusTraversalPolicy in force.

The ambient policy is determined by looking up the widget hierarchy for a FocusTraversalGroup widget, and obtaining the focus traversal policy from it. Different focus nodes can inherit difference policies, so part of the app can go in a predefined order (using OrderedTraversalPolicy), and part can go in reading order (using ReadingOrderTraversalPolicy), depending upon the use case.

Predefined policies include WidgetOrderTraversalPolicy, ReadingOrderTraversalPolicy, OrderedTraversalPolicy, and DirectionalFocusTraversalPolicyMixin, but custom policies can be built based upon these policies. See FocusTraversalPolicy for more information.

See also:

• Focus, a widget that manages a FocusNode and provides access to focus information and actions to its descendant widgets.
• FocusTraversalGroup, a widget used to group together and configure the focus traversal policy for a widget subtree.
• FocusManager, a singleton that manages the primary focus and distributes key events to focused nodes.
• FocusTraversalPolicy, a class used to determine how to move the focus to other nodes.