Frequently Asked Questions
Find answers to frequently asked questions about Jetpack Compose!
Last updated: 2021-01-23
What's the current status of Jetpack Compose?
Jetpack Compose is currently in Alpha. The API surface is still evolving but there are many people who are experimenting with it and providing feedback. If you'd like to play in role in shaping Jetpack Compose, I would encourage you to join the #compose channel in the Kotlin Lang Slack Channel. If you'd like to learn more about Jetpack Compose, I maintain this repo that will help you get started!
Can I start using Jetpack Compose in production apps
The general recommendation is that if you care about the users of your app, you should wait until a more stable release of Jetpack Compose is available. If its for an internal app, side project or prototypes, you can probably start experimenting with Jetpack Compose.
When should I expect a 1.0 release of Compose?
An 1.0 release for Compose is expected in 2021 as per the last official announcement.
Will Fragments be deprecated once Compose is released?
Compose didn't start with the goal replacing fragments per se but it’s a fantastic side effect. In most use cases, you shouldn’t need fragments at all if you are starting a pure compose screen/app. Moreover, since there are millions of apps that still use Fragments, there will most likely be ways to use it with that, although definitely not a requirement.
Why was a complete rewrite of the UI toolkit necessary?
Compose was built to solve some pain points that the Android developers had been facing since many years. Let's look at what some of those were:
UI is tied to the Operating System
The first reason is that the current UI toolkit is tied to the Android Operating System. What this means is that if we the Android team made some new improvements in the View system or as an example the View.java file, we will have to wait for an Android API release to get these improvements. It's not a simple library that I can just bump up to get these latest improvements & changes. Unbundling the view system from the OS would make it easier to quickly fix bugs and bring improvements in a backward compatible way.
State Management is tricky
The way we managed UI state has always been this complicated dance that we have to do as views store own their own state. And we need to make sure that the state that we store in our view models and presenters is in sync with the state inside of the views. For example, if my business logic requires me to hide a view, that logic is stored in some view model or presenter and then as a reaction to that requirement, I need to get hold of the view I need to hide and explicitly change it's visibility by calling the setVisibility method on the view, which in turn changes the internal state of the view. Now this is really error prone and majority of the bugs in our apps stem from state management. So there has to be a better way.
Lots of Context Switching
Let's talk about the average workflow of an Android developer. We typically create views in xml, then create our screens which have lifecycles in them using Kotlin/Java. We then reference the views that we originally created in xml using id's/tags and then update its state. When we need to reference styles & dimensions, we again store them in xml. This constant context switching definitely has some impact or our productivity and we've come to accept this unfortunately. Now some folks might say that isn't it good that all the UI is in xml files and all business logic in Kotlin files. Decoupling is supposed to be good after all. Well, it's true that decoupling is a good engineering practice but this is not really decoupling because you are still referencing these xml files in your Kotlin code and making modification to it. So even though you might think that xml is decoupled and your UI code is decoupled, in reality it's just an illusion.
Simple things still require a lot of code
We are used to writing a lot of code for even doing simple things. We just spoke about the normal workflow where we are making changes across so many files. Even outside of that, we have so many moving pieces that we need to take care of for writing UI code. Want to make a simple list, you create an adapter first, make sure that it extends the right class, override the relevant methods, If your list supports types of views items, then you override an additional method to pass the relevant layout xml file. So there's a lot of boilerplate code that we have to write for even doing simple things. The most effective way to reduce the number of bugs is to reduce the amount of code that we write.
Where can I see examples to learn about Jetpack Compose? (Edits by Brett Best)
If you haven't already noticed, here is another shameless 🔌- Learn Jetpack Compose By Example
Another project that is worth checking out is Compose Academy
You should also check out the official samples that are a great way to learn more about Compose.
Lastly, consider going through the Jetpack Compose Pathway.
How do I learn about the equivalent API for common Android tasks in Jetpack Compose?
How can I get started with Compose?
How do I get my apps ready for Compose?
If you apps are using uni-directional data flow, they will stand to benefit as the migration to Compose would be much smoother. I had spoken about a very relevant topic at Droidcon SF 2019. Towards the second half of the talk, I replace my entire UI with Compose with very little effort.
How would you describe a Composable?
@Composable is the secret sauce for Jetpack Compose and it is the most fundamental building block. Annotating a function with @Composable allows that function to describe UI in Compose. This annotation is needed because Compose uses a custom kotlin compiler to function. This custom compiler does some post-processing to each @Composable function and changes its definition at compile time
What kind of tooling is available with Compose?
Android Studio lets you preview your composable functions within the IDE itself, instead of needing to download the app to an Android device or emulator. This is a fantastic feature as you can preview all your custom components(read composable functions) from the comforts of the IDE.
The main restriction is, the composable function must not take any parameters. If your composable function requires a parameter, you can simply wrap your component inside another composable function that doesn't take any parameters and call your composable function with the appropriate params. Also, don't forget to annotate it with @Preview & @Composable annotations.
In addition, you can also deploy a composable function directly to your device for quickly testing it as you are developing it.Lastly, Android Studio even lets you interact with the components right from Android Studio.
How will I use view models and live data with Compose?
How will Dagger/Hilt fit in with Compose? Can I inject a Composable function? (Contributed by Zach Klippenstein)
For apps that are fully Compose top-to-bottom, you could just consider providing your dependencies directly via function parameters, lambdas/lexical scope, or using Ambients directly when necessary.
One of the best practices for Compose apps is that UI should be defined in terms of pure data and event callbacks and not have many heavy external dependencies in the first place, so it would maybe be concerning that if UI has a very complex dependency graph it probably isn't separated from business and other non-UI logic as cleanly as it should be.
Using dependency injection can potentially be useful in a mixed codebase that is being migrated to compose, but even then it would probably be cleaner to provide dependencies to the UI in a more Compose-idiomatic way at the boundary between legacy code and compose code
How does one handle orientation changes in Compose? (Contributed by Zach Klippenstein)
One of the advantages of declarative programming is that you can model these changes through control flow. In order to change UI based on the size of the screen or the orientation, you can simply us an if condition to handle these changes.
Does Compose work with WearOS?
Presently, it doesn't work with WearOS just yet but we are hopeful that it will be supported in the future.
Is there any relation between Flutter & Compose? Which one should I use?
Flutter and Jetpack Compose are independent projects and aren't necessarily trying to compete with each other. Fluter is a framework for building cross platform native apps. Compose is a new way of writing UI code in native Android. Each have their own merits and use. Since Compose came later on, it definitely did benefit from the learnings of the Flutter team. Both of them are declarative frameworks so they do share some similarities in that regard, however the way they are implemented is different.
I really liked using ConstraintLayouts with the layout editor. Can I still us ConstraintLayouts in Compose?
Can I use the existing Android Views in Jetpack Compose?
Can I use Jetpack Compose in the existing screens of my app?
Yes, you can use Compose in existing screens. Compose has an extension function that allows you to add a @Composable function to any view group (like FrameLayout, LinearLayout, etc). Here is an example.
What is the testing story for Compose?
Are material design widgets already available for use?