-
Conductor
A small, yet full-featured framework that allows building View-based Android applications (by bluelinelabs)
-
workflow
A Swift and Kotlin library for making composable state machines, and UIs driven by those state machines. (by square)
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
compose-destinations
Annotation processing library for type-safe Jetpack Compose navigation with no boilerplate.
-
Decompose
Kotlin Multiplatform lifecycle-aware business logic components (aka BLoCs) with routing (navigation) and pluggable UI (Jetpack Compose, SwiftUI, JS React, etc.)
-
simple-stack
[ACTIVE] Simple Stack, a backstack library / navigation framework for simpler navigation and state management (for fragments, views, or whatevers).
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
I don't have much experience with conductor, so I'm curious what your concerns about lifecycle is lacking compared to fragments? But if your team already knows that framework I might just stick with views over fragments. I see there is a compose integration if you do ever plan on picking that up with conductor. Otherwise compose makes fragments obsolete and your team already knows conductor. I do agree the navigation story in compose is not mature especially after jetpack compose navigation. But there are other 3rd party libraries like compose destinations or decompose, but would be nice to see something better 1st party.
Otherwise there's solutions like Squares Workflow that afaik support both View and Compose
I don't have much experience with conductor, so I'm curious what your concerns about lifecycle is lacking compared to fragments? But if your team already knows that framework I might just stick with views over fragments. I see there is a compose integration if you do ever plan on picking that up with conductor. Otherwise compose makes fragments obsolete and your team already knows conductor. I do agree the navigation story in compose is not mature especially after jetpack compose navigation. But there are other 3rd party libraries like compose destinations or decompose, but would be nice to see something better 1st party.
I don't have much experience with conductor, so I'm curious what your concerns about lifecycle is lacking compared to fragments? But if your team already knows that framework I might just stick with views over fragments. I see there is a compose integration if you do ever plan on picking that up with conductor. Otherwise compose makes fragments obsolete and your team already knows conductor. I do agree the navigation story in compose is not mature especially after jetpack compose navigation. But there are other 3rd party libraries like compose destinations or decompose, but would be nice to see something better 1st party.
I have been using Fragments instead of compound viewgroups lately with simple-stack as the navigator for the single-activity, although I need to figure out how to switch to use onBackPressed+onBackInvokedCallback and not just onBackPressed.
Related posts
-
simple-stack VS compose-navigation-reimagined - a user suggested alternative
2 projects | 4 Feb 2022 -
Kotlin Routing - routing everything
-
Why so many people are quitting Android development
-
Passing context to a UseCase class inside the domain module
-
Does anyone know hows Fragment lifecycle work in NavHostFragment (Bottom Navigation Views Activity)?