Status Update
No update yet.
Comments
ra...@google.com
ap...@google.com
@ezio1497@gmail.com Could you please insert the code snippet that you've used?
Meanwhile I tried a few examples. If we change the layout direction by changing the locale (or setting the developer option "Force RTL layout direction"), it works. But if instead we set the layout direction via the ambient (Providers (LayoutDirectionAmbient provides LayoutDirection.Rtl) { Popup() }), then the layout direction won't be propagated to the content of the Popup
If I understand correctly, the value of the layout direction set via ambient should have been propagated. So it seems like there is an issue with the ambient. Below is the minimum repro:
- Define a new ambient
val MyAmbient = ambientOf<Int>()
- Use it for Popup content size
Providers(MyAmbient provides 200) {
Popup(alignment = Alignment.CenterStart) {
val sizeDp = with(DensityAmbient.current) { MyAmbient.current.toDp() }
Box(Modifier.preferredSize(sizeDp).background(Color.Gray))
}
}
-
Run example and notice the result - Popup size is 200
-
Set the value of MyAmbient in ProvideCommonAmbients to 10
internal fun ProvideCommonAmbients(...) {
Providers(
...,
MyAmbient provides 10,
children = content
)
}
- Rerun using the same code snippet from step 2 and notice that the Popup size becomes 10. So even though we provided 200 on step 2, the content of the Popup still uses the one set on step 4.
Chuck, could you please take a look?
ap...@google.com
Providers(
LayoutDirectionAmbient provides LayoutDirection.Rtl,
) {
AlertDialog(
onDismissRequest = {
showDialog = false
},
text = {
Text(
"هل تريد مسح كافة الطلب؟",
)
},
title = {
Text(
"مسح الطلب",
)
},
confirmButton = {
TextButton(onClick = {
viewModel.clear()
showDialog = false
}) {
Text("نعم", textAlign = TextAlign.Right)
}
},
dismissButton = {
TextButton(onClick = {
showDialog = false
}) {
Text("لا", textAlign = TextAlign.Right)
}
},
)
}
Description
Developers of 3rd party libraries that want to use WorkManager run into the following constraints:
work-multiprocess)work-multiprocess, WorkManager should be initialized and configured withConfiguration.Builder.setDefaultProcessNamein all processes that use it (otherwise the process running a RemoteWorkerService will reschedule all work on startup, leading to canceling work that was just started and running it later)There are a few ways all these constraints could be addressed. One approach might be to provide a
isInitialized()API as well asgetConfiguration()orgetDefaultProcessName().However, I'm not sure that's the best path forward. Multi process is tricky, especially for libraries, because app developers tend to do things in
Application.onCreate()without realizing that a library will start a new process and trigger that code in it. Ideally libraries wouldn't have to deal with init / configuration at all, or they would be able to use WorkManager in isolation with a separate configuration from the app configuration (i.e. maybe get a different WorkManager instance that operates differently from the main singleton).