ViewTree
public final class ViewTree
Summary
Public methods |
|
|---|---|
static final ViewParent |
getParentOrViewTreeDisjointParent(@NonNull View receiver)Looks up a disjoint parent previously set by |
static final void |
setViewTreeDisjointParent(@NonNull View receiver, ViewParent parent)Assigns the disjoint parent of the given |
Public methods
getParentOrViewTreeDisjointParent
public static final ViewParent getParentOrViewTreeDisjointParent(@NonNull View receiver)
Looks up a disjoint parent previously set by setViewTreeDisjointParent.
| Returns | |
|---|---|
ViewParent |
The |
setViewTreeDisjointParent
public static final void setViewTreeDisjointParent(@NonNull View receiver, ViewParent parent)
Assigns the disjoint parent of the given view to parent.
A disjoint parent acts as an alternative to View.getParent and is used to link two disjoint view hierarchies together. ViewOverlays, popups, and dialogs are all examples of when two view hierarchies are disjoint but related. In all of these cases, there is either a new window or new root view that has no parent of its own but conceptually is owned or otherwise related to another specific view in the disjoint hierarchy.
A disjoint parent is only used when a view has no parent of its own, so it is important to set this tag only once at the root of the tree that is disconnected from its parent. AndroidX automatically sets disjoint parents for hierarchies it creates in certain use cases, like for view overlays (used in transitions).
Setting the disjoint parent allows other components to resolve information from the disjoint parent. AndroidX will use disjoint parents to resolve values stored in the view tree, like ViewModel store owners, lifecycle owners, and more. They are not used or set by the platform. Other View-based libraries should consider setting this property to allow these and similar lookups to occur between disconnected view hierarchies. Opting in is not mandatory, and therefore disjoint parents are not guaranteed to be a comprehensive source of view ownership in all situations.
To prevent a leak, a view must not outlive its disjoint parent. Additionally, you should avoid accidentally creating a cycle in the parent and disjoint parent hierarchy. A view can be re-parented to a different disjoint parent by calling this method again in the future, and can have its disjoint parent cleared by setting it to null.
| Parameters | |
|---|---|
@NonNull View receiver |
The view to set the disjoint parent of |
ViewParent parent |
The disjoint parent to set on |
| See also | |
|---|---|
getParentOrViewTreeDisjointParent |