Skip to content

Move non-ui Android RenderWorkflow concerns to workflow-runtime-android #1352

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: sedwards/move-render-android
Choose a base branch
from

Conversation

steve-the-edwards
Copy link
Contributor

Now that we have a workflow-runtime-android module (and published artifact), it is the place that makes sense to hold the Android versions of renderWorkflowIn, as they are beyond solely UI concerns, so do not need to be in workflow-ui.

Yes, I recognize that we could distribute this as an Android library from the workflow-runtime KMP module with a particular sourceset as well as particular publishing.

I think that would be a good thing to do, but I don't want to figure out how to set that up right now. I think our balance of jvm, ios, and js artifacts from the KMP modules right now makes sense. I do not think we lose anything from this Android library being a standalone module (after all, it was before when it was in workflow-ui).

@@ -42,7 +42,7 @@ class PoetryActivity : AppCompatActivity() {

class PoetryModel(savedState: SavedStateHandle) : ViewModel() {
val renderings: Flow<Screen> by lazy {
renderWorkflowIn(
com.squareup.workflow1.android.renderWorkflowIn(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: You're already statically importing this, I think the FQN is just an IDE bug? Search-and-replace to fix?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants