Optional Addressables locator support (3.1.0)#25
Open
PaulNonatomic wants to merge 2 commits into
Open
Conversation
AddressableServiceKitBehaviour loads its ServiceKitLocator via Addressables (a typed ServiceKitLocatorAssetReference) instead of a direct serialized reference - the locator isn't pulled into every bundle that references it, and its handle is released on destroy. Gated behind SERVICEKIT_ADDRESSABLES (set when the Addressables package is present); compiles to nothing otherwise. Backed by a new protected virtual ServiceKitBehaviour.PrepareLocatorAsync() hook (default no-op, completes synchronously) run in Awake before registration, so a subclass can source its locator asynchronously. Normal behaviours are unaffected. Validated: default EditMode 115 / PlayMode 19; compiles cleanly with Addressables (Task path) and with Addressables + UniTask (UniTask path).
- PrepareLocatorAsync hook PlayMode test: proves registration is deferred until an async locator source completes, then the service registers and initializes. This is the mechanism AddressableServiceKitBehaviour relies on, tested deterministically without the Addressables package via a TaskCompletionSource stand-in. - Sample 12 (Addressable Locator): a runnable example of AddressableServiceKitBehaviour plus a setup README, gated behind SERVICEKIT_ADDRESSABLES. A self-contained automated test of the real Addressables load is impractical in a package harness (Addressables config is project-level and batchmode init is flaky), so the sample is the human-verifiable runtime proof.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
3.1.0 — optional Addressables locator support
Re-implements the addressable-locator idea from the old
feat/addressable-servicekitbranch, freshly built against currentmain(3.0) and without the generic base-class split that made the old branch unmergeable.Added
AddressableServiceKitBehaviour— derive from this instead ofServiceKitBehaviourto load the locator through Addressables (via a typedServiceKitLocatorAssetReference) rather than a direct serialized reference. The locator loads asynchronously before the service registers (so it isn't pulled into every bundle/scene that references it), and the Addressables handle is released on destroy.ServiceKitBehaviour.PrepareLocatorAsync()— aprotected virtualhook (default no-op, completes synchronously) run inAwakebefore registration. The addressable variant overrides it to load the locator; you can override it to source a locator from any async origin. This is the minimal, non-invasive seam that replaces the old branch'sServiceKitBehaviourBase<T>refactor.Both are additive and non-breaking: the hook's default is a synchronous no-op, so existing behaviours register exactly as before.
AddressableServiceKitBehaviouris gated behindSERVICEKIT_ADDRESSABLES(set automatically when the Addressables package is present) and compiles to nothing otherwise.Validation
Full
#ifmatrix, Unity 6000.3.16f1:Task), addressable file excluded, 3 unresolved Addressables GUID refs harmlessTaskbranch compiles against the real Addressables APIUniTask.CompletedTaskpath + addressableUniTaskbranchNot covered
No automated functional test of the addressable load path — that needs built Addressables content, which isn't practical in batchmode. The validation above is a full compile matrix; the load/register/release logic mirrors the proven prior implementation and uses only stable Addressables APIs (
AssetReferenceT,LoadAssetAsync,AsyncOperationHandle,Addressables.Release).