Repository navigation
Conversation
Signed-off-by: Tyler Nijmeh <tyler@Tylers-MacBook-Pro.local>
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Automations to automatically generate PRs for you. |
ErikUggeldahl
left a comment
ErikUggeldahl
left a comment
There was a problem hiding this comment.
I think we can revise this to make a stronger example for users, since this is an important topic and we want to make sure they understand the ramification of when, why, and how to do this. Let me know if you have any questions based on the comments.
| } | ||
| ``` | ||
|
|
||
| Creating a worker is not a free operation. It is recommended to hoist the worker higher up in the Compose tree so that it can serve multiple Rive instances. |
There was a problem hiding this comment.
"not a free operation": I think this is a good opportunity to educate users and expand on what those costs are, which include starting a thread and initializing the graphics context (OpenGL or Vulkan).
There was a problem hiding this comment.
Also, it's not universally true that we want to hoist the worker. It's more so that if they have multiple Rive instances and want to share assets/graphics initialization costs, then we recommend hoisting.
There was a problem hiding this comment.
Another reason would be to avoid recreation the worker and reloading Rive files between navigation.
Generally the advice is to hoist to the level that makes sense for caching.
|
|
||
| Creating a worker is not a free operation. It is recommended to hoist the worker higher up in the Compose tree so that it can serve multiple Rive instances. | ||
|
|
||
| In some cases, it may be desirable to hoist the worker outside of the Composable context entirely. You will be responsible for managing the lifecycle of the worker and file. |
There was a problem hiding this comment.
"In some cases": I think this also deserves expansion. Which cases? And hoist where? We'll want to be specific about the activity or view model as suitable places.
I think it's worth documenting here that there's nothing Compose specific about a worker, and that it can be freely created outside of Compose contexts, but then used within it.
"and file": This is only true if the file is also hoisted outside of Compose. It's perfectly possible to only hoist the worker and still use rememberRiveFile in Compose, in which case this advice wouldn't apply.
There was a problem hiding this comment.
View models also might need special documentation as they're not lifecycle owners, so withLifecycle won't work.
There was a problem hiding this comment.
Might also be worth explaining that the user is also responsible for polling, and we can have a brief explanation for why.
| var cachedFile: RiveFile? = null | ||
|
|
||
| lifecycleScope.launch { | ||
| cachedFile = RiveFile.load( | ||
| RiveFileSource.RawRes(R.raw.my_rive_file, resources), | ||
| worker, | ||
| ) | ||
| } |
There was a problem hiding this comment.
I think this should be moved into the following section, "Loading a Rive File".
Either that or we should consider a fully new section for this advice. Here we're adding it to "Getting Started", but this is really more advanced advice and might just confuse a first time reader. I'd almost suggest a new page just to cover this concept.
| var cachedFile: RiveFile? = null | ||
|
|
||
| lifecycleScope.launch { | ||
| cachedFile = RiveFile.load( |
There was a problem hiding this comment.
We might want to encourage error handling here, since this can throw. A bare call like this could crash the app.
| } | ||
|
|
||
| // Later, create the composable | ||
| Rive(cachedFile) |
There was a problem hiding this comment.
Note that as written, this won't work, since you've written it as a nullable, and this doesn't take a nullable.
There was a problem hiding this comment.
We're also mixing Compose code and imperative code here, which might be a bit confusing to a reader. I think it makes sense to make those separations explicit.
Signed-off-by: Tyler Nijmeh <tyler@rive.app>
There was a problem hiding this comment.
Copilot review overview
🟢 Approval recommended
Only minor grammatical corrections remain; the documentation and navigation changes are otherwise coherent.
Review effort: Balanced
Findings: 1
Open (1)
What changed in this PR
Adds Android guidance for hoisting Rive workers to reduce repeated initialization costs.
Changes:
- Documents worker hoisting and lifecycle considerations.
- Adds an Activity-based manual polling example.
- Adds the page to Android navigation.
| File | Description |
|---|---|
runtimes/android/hoisting-the-worker.mdx |
Adds worker-hoisting guidance and example. |
docs.json |
Registers the page in Android navigation. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| description: 'Considerations when creating workers.' | ||
| --- | ||
|
|
||
| Creating a worker starts a new thread and initializes the graphics pipeline; is not a free operation. |
Add documentation for Android worker creation: