Our great sponsors
-
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)
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
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).
-
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.
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
- 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)?
- Are Fragments in Android going to be deprecated in favor of Jetpack Compose?