Accompanist is a bunch of libraries that purpose to complement Jetpack Compose with options which are generally required by builders however not but formally supported in Jetpack Compose AndroidX libraries. We use it as a “lab-like” setting to check out concepts and incubate experiments we have now questions on. We now have upstreamed to the principle Compose libraries a lot of these libraries not too long ago together with: Pager, Move Format, Navigation Animation & Insets-UI.
Sadly, as with all experiments, some are certain to fail. At this time I wished to offer an replace on the way forward for among the Accompanist libraries
Accompanist might be deprecating the next libraries, with no substitute:
All of those libraries are comparatively small and in case you are pleased with their present performance, we suggest forking their implementations and customizing them to your wants going forwards. They are going to stay in Accompanist in a deprecated state for 2 Compose BOM releases and can then be eliminated.
Moreover, the next libraries are additionally now thought of characteristic full and received’t have new options developed.
The rest of libraries in Accompanist proceed to be experimental. Adaptive, Check Harness & Navigation Materials.
Extra particulars on why we have now made this choice for every library are under:
The SystemUIController library aimed to make it simpler to manage the system UI (colours, conduct, visibility)
The first use case was to make it simpler to go edge-to-edge. For this use case, there may be now a direct substitute: Exercise.enableEdgeToEdge.
As time went on, extra APIs have been added to SystemUIController associated to the window and the underlying WindowInsetsControllerCompat APIs. This began to trigger two foremost points:
- Lots of the underlying window APIs don’t have listeners for when the values change. In consequence, exposing them via the
SystemUiControllerobject violated the@Steadycontract and resulted in a Compose class with stunning conduct. Values just like the system bar conduct, and system bar coloration, will solely be queried as soon as, and received’t trigger recompositions if they alter. - For some window APIs, calling them on the right time is extraordinarily vital to keep away from flicking or different graphical points as a result of they’re extraordinarily strongly linked to platform objects like actions and dialogs. For instance, lots of the APIs count on to be known as exactly throughout
onCreate, or throughout different lifecycle strategies. By exposing these APIs via a Compose wrapper likeSystemUIController, this timing expectation can usually be damaged.
In consequence, we will’t see the present SystemUIController design being upstreamed in its present type. It’s usually handy to make use of, however the present API creates expectations about its conduct that it usually can’t hold. Because of this, we have now determined to deprecate it as we don’t need groups investing in it pondering will probably be upstreamed sooner or later.
Suggestion: When you have been utilizing SystemUIController to go edge-to-edge in your exercise and alter the system bar colours and system bar icon colours, use the brand new Exercise.enableEdgeToEdge methodology accessible in androidx.exercise 1.8.0-alpha03 and later. This methodology backports the scrims used on some variations of Android. This is a pattern PR of the migration to the brand new methodology and eradicating the dependency on SystemUIController in Now in Android.
For different usages, migrate to utilizing WindowInsetsControllerCompat or window APIs instantly.
AppCompat and Materials Theme Adapters are libraries to help with the migration to Compose. They take an current XML theme and output a Compose theme for consumption in Compose code. Utilizing it stops you having to implement two variations of your theme, one for Views and one for Compose.
Some groups have reported that utilizing these libraries helps them get experiments up and operating shortly, however in addition they discover that it’s simpler to create a Compose theme in parallel to their views theme, as many groups generate their themes by exporting them from a design device. These instruments will be configured to output each a Compose and XML theme and that is seen as the higher resolution. We also have a device for that within the Materials Theme Builder.
Changing an XML theme to a Compose theme additionally has a efficiency price that’s paid at runtime within the present implementation, ideally this price may very well be paid at compile time.
As Materials 3 is evolving shortly, we have now additionally been unable to maintain up with the brand new attributes within the theme adapter and these at the moment aren’t being transformed.
Suggestion: Use the Materials Theme Builder device, or an alternate design device, to generate an identical XML and Compose theme implementation in your app. See Migrating XML themes to Compose to be taught extra.
You’ll be able to checkout Materials Design 3 in Compose to be taught extra about creating and including theme to your app utilizing Materials Theme Builder.
Now that Compose is secure, with a strong set of APIs that make creating customized widgets far less complicated than up to now with the view system, we have now determined to now not add or help our personal set of customized widgets in Accompanist. This consists of Pager Indicator, Placeholder & WebView.
Compose makes implementing your personal variations of those widgets simple. The primary downside we have now with implementing customized widgets is that we have to help sufficient customization for everybody. If you implement a widget your self, you may implement simply what you want and nothing extra, which significantly simplifies the implementation. One more reason we’re now not supporting customized widget libraries in Accompanist is that we consider by having them in Accompanist, we’re deterring the neighborhood from growing their very own units of customized widgets.
Suggestion: We suggest utilizing our implementations to fork or create your personal customized implementations that fit your wants.
DrawablePainter is a properly used library however will most probably by no means be upstreamed as we don’t wish to help the fill drawable specification in Compose, we consider Compose offers a greater API that makes lots of what drawables help out of date. For instance, drawable layer lists are unsupported in Compose and this can be a deliberate choice as we consider the declarative fashion of Compose is a greater solution to deal with the conditions you’d use a layer-list. DrawablePainter doesn’t help layer-lists both however a model that lived in the principle Compose libraries must help all types of drawable and so for now we’re pleased having it stay in Accompanist marked as characteristic full.
We’re nonetheless evaluating easy methods to finest deal with Android Permissions and Compose on the platform stage. We’re pleased having the Accompanist resolution stay in Accompanist whereas this choice is in course of. We received’t be growing any new options for it however will repair any important points that will come up.
