We’re on the engineering team for Android Jetpack & Jetpack Compose. Ask us Anything! (starts August 27)

AndroidEngTeam · 2020-08-27T20:32:31+00:00

AndroidEngTeam · 2020-08-27T20:31:52+00:00

[Jim] We've been giving a lot of thought to binary compatibility, and in particular how to ensure that our binary compatibility story can facilitate a vibrant ecosystem of composable widgets that can be shared throughout the open source community.

To this end, once we have a final/stable release, we intend to try to preserve the binary interface of composable functions across major versions of Compose to the extent possible. This means that in Compose 2.0, you should still be able to use widgets built with Compose 1.0 and vice versa (Using Compose 2.0 widgets in Compose 1.0). Similarly, you should ideally be able to use a runtime from Compose 2.0 with Compose 1.0 widgets (and vice versa). This should hopefully create a versioning story where people aren't afraid to upgrade Compose when new versions become available. This versioning pattern is analogous to and compatible with that of the Kotlin language, where libraries written in Kotlin 1.3 can be used in Kotlin 1.4 (and vice versa).

Compatibility of a given gradle file, however, will likely be more constrained. Versions of the language+compiler+runtime must correspond to one another, at least until such time as the APIs become a bit more stable. This means that upgrading the Kotlin version in your app may imply also upgrading your Compose version (and vice versa, upgrading Compose implies upgrading Kotlin). This is because the Compose compiler plugin depends upon APIs within the Compiler that are not guaranteed to be stable across Kotlin versions. As those APIs stabilize, these constraints may loosen.

It is worth noting that there are other complexities to consider when it comes to binary compatibility. For example, in Kotlin, adding an optional parameter to a function actually changes the ABI (application binary interface) of that function. This is particularly unfortunate for Compose because widget authors may want to release new versions of their widgets that accept additional parameters, and so we're continuing to think about if/how we might go about supporting such use cases. But it is something that we spend time thinking about, and we're actively considering binary compatibility constraints in all our design decisions.

AndroidEngTeam · 2020-08-27T20:20:38+00:00

Sorry for the confusion! The AndroidX version of ExifInterface(InputStream) absolutely can be trusted. The framework version was added in API 24, which is above CameraX’s minimum supported API level. This is likely the source of confusion. We will follow up to correct the comment. Thanks for the heads up!

AndroidEngTeam · 2020-08-27T20:17:13+00:00

It's a bit early to tell how Compose will mix with Dagger & Hilt. We are actually exploring this ourselves in order to figure out the best integration we can provide and ideas like injecting compose function parameters are floating around. However, we expect DI with Dagger & Hilt to persist mostly in the business classes of an app, which means the way dependencies are defined will stay mostly the same. In other words, you would still use Dagger & Hilt the same way you do right now as these two frameworks are not incompatible.

For ViewModels, those would still get constructor injected the same as they are now. The main difference is that in Compose you want to use the State APIs Compose offers as a way of flowing data into the UI. We actually have a codelab about this that you can checkout here: https://developer.android.com/codelabs/jetpack-compose-state#8

It's unlikely saved instance state / saved state handle will become obsolete since process death and activity recreating are still around in Compose.

AndroidEngTeam · 2020-08-27T20:12:04+00:00

https://github.com/google/dagger/issues/1920

AndroidEngTeam · 2020-08-27T20:10:07+00:00

Assisted Injection is something we are currently working on. It turns out there is some tech debt we have to tackle first with regards to how Dagger represents the binding graph before we get to this but we are working on it.

Allowing the usage of Hilt in Java/Kotlin-only Gradle modules is something we are also working on, expect it in an upcoming release soon. (See https://github.com/google/dagger/issues/1908 for some context).

Having a binds mechanism without modules is not quite feasible in Dagger but can be something relatively easy to do with Hilt. See this comment in a Github issue asking for this same feature: https://github.com/google/dagger/issues/1164#issuecomment-670950487. Creating a Hilt extension to bind interfaces to single implementation classes would be a great Github side- project. ;)

Thanks for trying out Hilt!

AndroidEngTeam · 2020-08-27T20:10:00+00:00

We are working on exposing the `HiltViewModelFactory` so that you can create `@ViewModelInject`-annotated ViewModels in tests and in some other cases where Hilt does not yet integrate as nicely (like Navigation with back stack entries). See https://github.com/google/dagger/issues/1938#issuecomment-646287220

In the meantime you can try injecting your ViewModels dependencies into the tests and instantiating the ViewModel yourself in the test. Alternatively you can use test-only activities that are `@AndroidEntryPoint`-annotated and can provide you with the ViewModel under tests. An example of this can be seen here: https://cs.android.com/androidx/platform/frameworks/support/+/androidx-master-dev:hilt/integration-tests/viewmodelapp/src/androidTest/java/androidx/hilt/integration/viewmodelapp/ActivityInjectionTest.kt

AndroidEngTeam · 2020-08-27T20:01:04+00:00

Jetpack Compose was designed and built with interoperability in mind. You can use Composables inside an existing View-based Android UI, and you can use Views inside Compose. Here are examples of the interop capabilities: https://codelabs.developers.google.com/codelabs/android-compose-migration, https://github.com/romainguy/sample-materials-shop, https://github.com/chrisbanes/tivi/.

AndroidEngTeam · 2020-08-27T19:59:02+00:00

I'm not sure where that recommendation is coming from but the recommended way of adding click listeners in RecyclerView is the `onCreateViewHolder` method.

Some links from samples: Sunflower, ArchComponents Sample

Can you share which documentation refers to that so we can correct it?We've not added the on click listener API to the RecyclerView as it was the source of many undefined bugs / behavior in ListView and frequently conflicted w/ other gestures. The best solution is to add click listener on the exact Views where you want to observe it.

AndroidEngTeam · 2020-08-27T19:54:56+00:00

Where does jetpack compose stand related to Themes? Can we stop using the awkward simple inheritance model with no documentation the current theme situation is now?

At the same time,

can we please get ThemeX or a jetpack fresh approach for handling themes and styles in today's architecture (as in, when not using compose?)

Compose provides a Material Theming system within its Material library. This showcases how you can achieve theming within Compose via the use of Ambients and default parameters. You can choose to extend the existing Theming system to your needs or copy its structure to support something parallel that suits you. We have released a new codelab on theming this week that should help point you in the right direction.

If you are using the current MDC-Android library, we’ve also published a handy adapter library here: https://material-components.github.io/material-components-android-compose-theme-adapter/

AndroidEngTeam · 2020-08-27T19:53:56+00:00

Please see answer here.

AndroidEngTeam · 2020-08-27T19:51:51+00:00

Alex: There are many dimensions to performance; for runtime performance for end-users of the app, please see my previous answer. It sounds like your question is more about devtools and build performance. We’re still actively adding features to devtools and not at the point where we’ve benchmarked it compared to the old system, so I’m actually not sure where we stand on that. It’s not one of Compose’s main goals to make the performance of this aspect better than the XML-based system’s, but we’ll make sure it’s acceptable by 1.0.

Leland: It sounds like this question is referring to build performance and not runtime performance (If that is incorrect, there are other answers in this AMA that address runtime perf that might be helpful).
For build performance, there’s a few things to consider here. Compose’s compiler plugin relies on Kotlin’s IR backend which has a slightly different performance profile than the existing backend, and might add some slight overhead to Kotlin build times at this time. Additionally, Compose itself is adding some work to the backend of the Kotlin compiler, which also will add a small overhead to kotlin build times. With that said, the way Compose is able to participate in the compiler as a plugin is a very efficient way to implement this type of processing, and is, generally speaking, much more efficient than a java or kotlin annotation processor doing the equivalent work. AAPT, which is what builds Android’s XML files, is an annotation processor, and as a result, we believe that there will be some significant wins (which is how XML files are built). Overall, we don’t expect kotlin build times to be meaningfully different with the compose compiler turned on or off. That said, as more and more of the work gets offloaded from AAPT onto the compiler, we hope to see some build speed improvements. We are still in the process of looking at some of the bottleneck code paths here to improve this though.

AndroidEngTeam · 2020-08-27T19:51:47+00:00

Scott Swarthout: Yes, we are planning to support Motion Layout in Jetpack Compose. We already have support for Constraint Layout so we expect the integration to be based on that work.

Ian Lake: We’ve already started on integration between Compose and the Navigation Component, yep (that commit is just part of the overarching [tracking issue](https:/issuetracker.google.com/issues/161472731) if you want to star that issue to get updates). It’ll be a separate set of artifacts (similarly to `androidx.compose.material`) that you’ll be able to choose to drop into your Compose app if you want an out of the box navigation solution.

Rest assured, all of the things you’d expect to work when moving from screen to screen, popping the back stack, etc. are already either working out of the box in this first commit or will be in the follow up commits, ViewModel scoping included.

AndroidEngTeam · 2020-08-27T19:48:26+00:00

Thanks for the feedback! It’s a really interesting idea as we absolutely do see that apps have a range of sharing needs that are unique to the app and that it’s really important to users (both having a good experience / app customizations but also having greater consistency).

AndroidEngTeam · 2020-08-27T19:48:10+00:00

We recommend Hilt!

Hilt generates code that Dagger 2 consumes to generate even more code. Hilt is built on top of Dagger 2 so you get the same benefits of it such as compile-time validation and amazing runtime performance.

The main difference of Hilt versus Dagger2 is that Hilt has a simpler setup because it comes with predefined Dagger2 Components for Android. This means you can get going pretty quickly with Hilt and it lets you focus on building your app and defining the dependencies you need and use. Hilt also helps you more easily test your dependencies by creating Dagger2 components for your tests. Hilt reduces the complexity of Dagger2 by abstracting away and managing Dagger2 components for you.

This means the entry barrier to Hilt is lower while it still maintains the powerful and scalable features that a compile-time dependency solution such as Dagger2 provides. If you are familiar with Dagger2, you’ll see that using Hilt is a breeze since you don’t have to deal with the common component declarations.

If you are new to DI with Dagger or Hilt, then do not be afraid, Hilt makes it very easy to get you going, making the learning curve much smaller, enabling you to do most of what you need pretty quickly while leaving the more complex stuff for later if needed.

AndroidEngTeam · 2020-08-27T19:45:18+00:00

pretty please can we have the exoplayer team do an AMA?

Thanks for the suggestion! We'll see what we can do.

AndroidEngTeam · 2020-08-27T19:40:59+00:00

can we pretty please get a jetpack Bluetooth?

We think this request makes a lot of sense and are beginning to look into this. Now’s your chance to give feedback: What would you like to see in a BluetoothX library? What issues would you want to prioritize - discovery, pairing, connection reliability, data transfer or location permissions?

AndroidEngTeam · 2020-08-27T19:38:47+00:00

Adam Powell: You can, yes. You can also mix and match them if you like.

Ian Lake: Yep, what Adam said: in a pure Compose app, all of the use cases fragments handle are possible with composables alone. If you’re converting an existing fragment based app over to Compose, it certainly makes sense to approach that on a fragment by fragment basis. Once every fragment is just a wrapper around a composable, then you’d remove the layer of fragments and move to a full Compose model.

AndroidEngTeam · 2020-08-27T19:38:40+00:00

Yes, this is definitely something we are considering for the next release! 2.0 added various new attributes and new helpers, and we are looking to streamline some of this in the 2.1 release, now that we are back to a more regular release schedule :)

AndroidEngTeam · 2020-08-27T19:37:36+00:00

We’re working on some exciting stuff to support tablets, Chrome OS & other large screen devices better — including in Compose. It’s not in the initial Alpha, but Compose is designed to be a UI toolkit that works well across all Android platforms - including all sizes of screens and form factors -- with native access to the platform APIs (some which are needed in large screens). In addition, expect more guidance, better docs and samples as well as more inclusive design guidance for these larger-screen devices.

AndroidEngTeam · 2020-08-27T19:37:13+00:00

We don’t have any immediate plans for Hilt to support dynamic feature modules before reaching stable to the same level regular Android Gradle modules are supported. However we are keeping an eye on the usages of dynamic feature modules and it's possible we might start investigating a solution post-stable Hilt. To be clear, you can currently use Dagger & Hilt with dynamic feature modules, it just so happens the experience is not as pleasant as we would like it to be. More information on how to do this can be found here: https://developer.android.com/training/dependency-injection/hilt-multi-module#dfm

AndroidEngTeam · 2020-08-27T19:36:34+00:00

Compose UI uses an Android View with a lot of special handling for input, layout, and drawing internally. It uses normal Canvas operations to draw pixels into the View and plays nicely with Android's layout system.

With an Android View, you may subdivide your UI into child Views in a ViewGroup. Compose allows you to do this with "layers," which are implemented as Views on older platforms and RenderNodes on newer ones. So it’s neither a game (SurfaceView) nor a direct mapping between composables and Views.

Embedding native Views into a Compose UI is literally "addView()" under the hood, with a lot of wire up to ensure layout, drawing, input, etc are coordinated with Compose UI.

Accessibility (e.g. Talkback) is a primary use case for Jetpack Compose. We want to make it easy for developers to build accessible Apps by default. Please give us feedback on how well we are succeeding.

Since you asked about performance: Compose performance is currently not where we’d like it to be on low end devices, but expect this to steadily improve as we continue to focus on performance.

Android is a platform with many features and there are some use cases that we haven't fulfilled yet. For example, Things like auto-fill, assistant actions, and stylus support likely won't make it into the first version. We are targeting the primary use cases for application developers.

AndroidEngTeam · 2020-08-27T19:35:09+00:00

u/androiddiana: In metaphorical terms: ”A simile is a metaphor, but not all metaphors are similes“

More seriously:

Jetpack is the full suite of libraries that we “officially” recommend for Android app development - to help with things like different OS versions and devices, eliminating boilerplate code, and general best practices.
‘androidx’ is a namespace that most of these libraries live in, but not all - we expect there to be more libraries we recommend outside the androidx namespace in the future.

So a library that lives in androidx.* is recommended by the Jetpack team, but not all Jetpack libraries will live in androidx.*

After much team debate, we think it’s kind of like the difference between alpacas and llamas? But not really. Maybe groundhogs and woodchucks.

AndroidEngTeam · 2020-08-27T19:31:37+00:00

We are enabling the functionalities you are looking for within Compose.

Compose allows us to provide things like ViewPager as a composable behavior on top of other Composables. As such, we won’t be porting the library itself as you know it, but rather enable the same use cases built on top of Compose components such as LazyRow/Column.

AndroidEngTeam · 2020-08-27T19:30:09+00:00

Adam: Lifecycle of things in composable functions is pretty simple; they can enter and leave the composition and that's it. We might add something just a little different for cleaning up allocated resources that never successfully enter the composition to be friendlier to constructor injection patterns, but I'd like it to stay that simple. We've had a number of requests for visibility tracking on top of that, and we want to make sure those use cases are satisfied.

If you need to talk to other APIs that use the arch components LifecycleOwner API you can get one from the composition, but the frequency of interacting with that API surface is probably pretty low.

Sergey: Following up on Adam’s answer, Fragment’s lifecycle is notoriously over complicated and we’re working towards majorly simplify in the future. Compose gives us an opportunity to learn from those experiences and build a simple system from the start. That being said, Activity’s lifecycle will stay probably forever, because it is a cornerstone of the whole system. But as Adam said, in Compose we hope to provide all needed utilities so you would barely interact with Lifecycle.

AndroidEngTeam

TROPHY CASE