API reference
Instance Class
When creating your own Context instances, there are two main patterns you can use: an Editor-centric pattern and a code-centric pattern. For an Editor-centric pattern, simply attach a Context to a GameObject and "wire it up" to Editor-exposed fields as you would with any other Unity Component. The accessibility and lifespan, in Editor or in Code, of a Context created this way adheres to typical Unity patterns. This usage is most appropriate small-scope uses for example, if an individual prefab needs a Context specific to its own usage to faciliate operations local to the context of each prefab instance.
By contrast, the Instance class is intended to help with a code-centric pattern. In this pattern, the Context in question is lazily created at runtime (rather than saved as part of the scene) and thus cannot be "wired up" to dependencies in the Editor. While the Context within an Instance can be retrieved using Component accessors at runtime, it should typically be accessed through the Instance proper, which will lazily initialize the Context instance as needed. This pattern is most appropriate for large and/or long-lived usage scopes, particularly for Contexts which should not be destroyed before app teardown. Destroying Instance Contexts, as well as accessing them during app teardown, involves special considerations explored more deeply in the remarks on GetInstance.
Member Functions
Instance
( string name )
Basic constructor.
This sets the name which will be given to the lazily-created GameObject which will host the underlying Context.
Parameters
name
The name which will be given to the lazily-created GameObject
Context GetInstance ( )
Retrieves the Context which underlies this Instance; if a valid one does not currently exist, a new one is lazily created.
Note that destroying the GameObject and/or Context created by an Instanceis supported and will successfully tear down the Context; however, if GetInstance is subsequently queried, it will simply lazily create a new Context. This has particular implications on the use of Instance Contexts during app teardown, where order of destruction is not guaranteed and attempts to access an existing InstanceContext may result in the creation of a new Context instead if the prior Context happens to have been destroyed first. For this reason, if access to a specific Context is needed in teardown logic (or to a lesser degree any other logic), you should locally cache a reference to the underlying Context and only invoke GetInstance if the old instance is destroyed and you specifically need a reference to the new one.
Did you find this page helpful?
Virtual reality / Meta Horizon
Support and legal
Virtual reality / Meta Horizon
Support and legal
Virtual reality / Meta Horizon
Support and legal
English (US)
© 2025 Meta