An update on Jetpack Compose Accompanist libraries — August 2023
An update on Jetpack Compose Accompanist libraries — August 2023
Accompanist is a group of libraries that aim to supplement Jetpack Compose with features that are commonly required by developers but not yet officially supported in Jetpack Compose AndroidX libraries. We use it as a “lab-like” environment to try out ideas and incubate experiments we have questions about. We have upstreamed to the main Compose libraries a number of these libraries recently including: Pager, Flow Layout, Navigation Animation & Insets-UI.
Unfortunately, as with all experiments, some are bound to fail. Today I wanted to provide an update on the future of some of the Accompanist libraries
Accompanist will be deprecating the following libraries, with no replacement:
All of these libraries are relatively small and if you are happy with their current functionality, we recommend forking their implementations and customizing them to your needs going forwards. They will remain in Accompanist in a deprecated state for two Compose BOM releases and will then be removed.
Additionally, the following libraries are also now considered feature complete and won’t have new features developed.
The remainder of libraries in Accompanist continue to be experimental. Adaptive, Test Harness & Navigation Material.
More details on why we have made this decision for each library are below:
System UI Controller
The SystemUIController library aimed to make it easier to control the system UI (colors, behavior, visibility)
The primary use case was to make it easier to go edge-to-edge. For this use case, there is now a direct replacement: Activity.enableEdgeToEdge.
As time went on, more APIs were added to SystemUIController related to the window and the underlying WindowInsetsControllerCompat APIs. This started to cause two main issues:
- Many of the underlying window APIs don’t have listeners for when the values change. As a result, exposing them through the
SystemUiControllerobject violated the@Stablecontract and resulted in a Compose class with surprising behavior. Values like the system bar behavior, and system bar color, will only be queried once, and won’t cause recompositions if they change. - For some window APIs, calling them at the correct time is extremely important to avoid flicking or other graphical issues because they are extremely strongly linked to platform objects like activities and dialogs. For example, many of the APIs expect to be called precisely during
onCreate, or during other lifecycle methods. By exposing these APIs through a Compose wrapper likeSystemUIController, this timing expectation can often be broken.
As a result, we can’t see the current SystemUIController design being upstreamed in its current form. It is often convenient to use, but the current API creates expectations about its behavior that it often can’t keep. For this reason, we have decided to deprecate it as we do not want teams investing in it thinking it will be upstreamed in the future.
Recommendation: If you were using SystemUIController to go edge-to-edge in your activity and change the system bar colors and system bar icon colors, use the new Activity.enableEdgeToEdge method available in androidx.activity 1.8.0-alpha03 and later. This method backports the scrims used on some versions of Android. This is a sample PR of the migration to the new method and removing the dependency on SystemUIController in Now in Android.
For other usages, migrate to using WindowInsetsControllerCompat or window APIs directly.
AppCompat and Material Theme Adapters
AppCompat and Material Theme Adapters are libraries to assist with the migration to Compose. They take an existing XML theme and output a Compose theme for consumption in Compose code. Using it stops you having to implement two versions of your theme, one for Views and one for Compose.
Some teams have reported that using these libraries helps them get experiments up and running quickly, but they also find that it is easier to create a Compose theme in parallel to their views theme, as many teams generate their themes by exporting them from a design tool. These tools can be configured to output both a Compose and XML theme and this is seen as the better solution. We even have a tool for that in the Material Theme Builder.
Converting an XML theme to a Compose theme also has a performance cost that is paid at runtime in the current implementation, ideally this cost could be paid at compile time.
As Material 3 is evolving quickly, we have also been unable to keep up with the new attributes in the theme adapter and these currently aren’t being converted.
Recommendation: Use the Material Theme Builder tool, or an alternative design tool, to generate a matching XML and Compose theme implementation for your app. See Migrating XML themes to Compose to learn more.
You can checkout Material Design 3 in Compose to learn more about creating and adding theme to your app using Material Theme Builder.
Pager Indicator, Placeholder & WebView
Now that Compose is stable, with a robust set of APIs that make creating custom widgets far simpler than in the past with the view system, we have decided to no longer add or support our own set of custom widgets in Accompanist. This includes Pager Indicator, Placeholder & WebView.
Compose makes implementing your own versions of these widgets easy. The main problem we have with implementing custom widgets is that we need to support enough customization for everyone. When you implement a widget yourself, you can implement just what you need and nothing more, which greatly simplifies the implementation. Another reason we are no longer supporting custom widget libraries in Accompanist is that we believe by having them in Accompanist, we are deterring the community from developing their own sets of custom widgets.
Recommendation: We recommend using our implementations to fork or create your own custom implementations that suit your needs.
DrawablePainter
DrawablePainter is a well used library but will most likely never be upstreamed as we don’t want to support the fill drawable specification in Compose, we believe Compose provides a better API that makes a lot of what drawables support obsolete. For example, drawable layer lists are unsupported in Compose and this is a deliberate decision as we believe the declarative style of Compose is a better way to handle the situations you would use a layer-list. DrawablePainter doesn’t support layer-lists either but a version that lived in the main Compose libraries would have to support all forms of drawable and so for now we are happy having it live in Accompanist marked as feature complete.
Permissions
We are still evaluating how to best handle Android Permissions and Compose at the platform level. We are happy having the Accompanist solution remain in Accompanist while this decision is in process. We won’t be developing any new features for it but will fix any critical issues that may come up.
