I have already viewed other posts on the site. They suggest using the focusRequestor modifier and I've tried that.
val scope = rememberCoroutineScope()
val focusRequester = remember { FocusRequester() }
Text(
modifier = Modifier
.focusable()
.focusTarget() //Tried Adding/Removing
.onFocusChanged {
if (it.hasFocus || it.isFocused) {
Log.i("Test", "Text Focused")
}
} // Tried Adding Visual Elements to delete it as well.
.focusRequester(focusRequester),
text = "MARSK"
)
LaunchedEffect(scope) {
focusRequester.requestFocus()
}
I'm taking Text in this example, but actually I need to implement this on Canvas. This approach is not working on Box too. I'm afraid the same is the case for other containers as well.
For background, this is being built for my TV, so I wish to make this element clickable by the OK button on the remote's D-Pad. My approach is to make it focused first, then assuming that once it is focused, it will automatically detect the press of the OK button as the 'click'. If there is something wrong with my approach, feedback for improvements is also welcome.
PS: The solution by Abhimanyu works like a charm on Mobile Devices. However, since I mentioned a TV above, a TV is the device in consideration. On the TV, I have to press a button (Any button on the DPAD works, even the OK button, strangely) to get it focused up. Any idea how to get round this issue?
Thanks
Issue
The onFocusChanged should be added BEFORE the focusTarget or focusable that is being observed.
Source
Changes
Remove focusTarget and move onFocusChanged before focusable.
Also, note that focusRequester must be before focusable.
This would hopefully work for all comopsables. I have tested using Text and the example from Docs was using Box.
Extra details.
Prefer focusable over focusTarget.
From focusTarget docs,
Note: This is a low level modifier. Before using this consider using Modifier.focusable(). It uses a focusTarget in its implementation. Modifier.focusable() adds semantics that are needed for accessibility.
Order of Modifiers matter
Layouts in Jetpack Compose Codelab
Check Order Matters section
order matters when chaining modifiers as they're applied to the composable they modify from earlier to later,
Sample code
#Composable
fun FocusableText() {
val scope = rememberCoroutineScope()
val focusRequester = remember { FocusRequester() }
var color by remember { mutableStateOf(White) }
LaunchedEffect(scope) {
focusRequester.requestFocus()
}
Text(
modifier = Modifier
.background(color)
.onFocusChanged {
color = if (it.hasFocus || it.isFocused) {
LightGray
} else {
White
}
}
.focusRequester(focusRequester)
.focusable(),
text = "Test Text"
)
}
The Text background is LightGray which indicates the text is focused.
Related
I know how to implement BottomSheet in Material 2 Jetpack Compose using BottomSheetScaffold.
But there is no BottomSheetScaffold in Material 3. Also, there is nothing in official samples about BottomSheet.
So I was able to make it work!
It seems that, as of today, BottomSheetScaffold is not available yet on Material3, this is discussed in this issue I found digging around: https://issuetracker.google.com/issues/229839039
I quote the important part from the reply of a google dev:
we aren't in a super easy spot with Swipeable. It currently has a number of critical bugs that need to be addressed first (we are working on this), which is why we are limiting the surface we are exposing for Swipeable in M3 for the time. Our plan for the coming months is to focus on this specific area and improve developer experience.
Material 3 for Jetpack Compose is still in alpha - this means we
consider components production-ready, but the API shape is flexible
while in alpha. This gives us space to iterate while getting
real-world feedback from developers, which ultimately helps improve
your experience. Copy-pasting source code for components that are not
(fully) implemented or exposed in an alpha version can be a good thing
to do in the meantime! Owning the source code while the API shape is
still flexible gives you a number of benefits like ease of updating
dependencies, even if the APIs change, and allows you to evolve your
components in your own pace.
So I just followed the advice and I copy pasted BottomSheetScaffold into my project. Of course it did not work straight away because of a few missing classes and some minor API changes. At the end I was able to make it work by pulling and hacking the following classes and adding them to my project:
BottomSheetScaffold.kt
Drawer.kt
Strings.kt
Swipeable.kt
I have created a gist with the source code if you want to try:
https://gist.github.com/Marlinski/0b043968c2f574d70ee6060aeda54882
You will have to change the import to make it work on your project as well as add the "-Xjvm-default=all" option by adding the following into your gradle file in the android{} section:
android{
...
kotlinOptions {
freeCompilerArgs += ["-Xjvm-default=all"]
// "-Xjvm-default=all" option added because of this error:
// ... Inheritance from an interface with '#JvmDefault' members is only allowed with -Xjvm-default option
// triggered by porting BottomSheetScaffold for Material3 on Swipeable.kt:844
}
}
It works very well for me, will keep this solution until it is officially supported in material3.
Hope it helps!
I got pretty similar results using a fullscreen dialog with AnimatedVisibility, here is the code if interested:
// Visibility state for the dialog which will trigger it only once when called
val transitionState = remember {
MutableTransitionState(false).apply {
targetState = true
}
}
Dialog(
onDismissRequest = {} // You can set a visibility state variable to false in here which will close the dialog when clicked outside its bounds, no reason to when full screen though,
properties = DialogProperties(
// This property makes the dialog full width of the screen
usePlatformDefaultWidth = false
)
) {
// Visibility animation, more information in android docs if needed
AnimatedVisibility(
visibleState = transitionState,
enter = slideInVertically(
initialOffsetY = { it },
animationSpec = ...
),
exit = slideOutVertically(
targetOffsetY = { it },
animationSpec = ...
)
)
) {
Box(
modifier = Modifier.fillMaxSize().background(color = ...)
) {
// Your layout
// This can be any user interraction that closes the dialog
Button(
transitionState.apply { targetState = false }
) ...
}
}
All of this is in a composable function that gets called when a UI action to open said dialog is performed, it's not ideal but it works.
Hope I was able to help!
There is already a great answer by Marlinski, but i would like to add that there is also a ModalBottomSheetLayout which also does not have any implementation for Material 3.
I created a gist for people who need it in use right now:
https://gist.github.com/Pasha831/bdedcfee01acdc96cf3ae643da64f88a
We finally have ModalBottomSheet in Material3.
var openBottomSheet by rememberSaveable { mutableStateOf(false) }
val bottomSheetState = rememberSheetState(skipHalfExpanded = true)
// Sheet content
if (openBottomSheet) {
ModalBottomSheet(
onDismissRequest = { openBottomSheet = false },
sheetState = bottomSheetState,
) {
Row(Modifier.fillMaxWidth(), horizontalArrangement = Arrangement.Center) {
Button(
// Note: If you provide logic outside of onDismissRequest to remove the sheet,
// you must additionally handle intended state cleanup, if any.
onClick = {
scope.launch { bottomSheetState.hide() }.invokeOnCompletion {
if (!bottomSheetState.isVisible) {
openBottomSheet = false
}
}
}
) {
Text("Hide Bottom Sheet")
}
}
}
}
For more link here: https://developer.android.com/reference/kotlin/androidx/compose/material3/package-summary#ModalBottomSheet(kotlin.Function0,androidx.compose.ui.Modifier,androidx.compose.material3.SheetState,androidx.compose.ui.graphics.Shape,androidx.compose.ui.graphics.Color,androidx.compose.ui.graphics.Color,androidx.compose.ui.unit.Dp,androidx.compose.ui.graphics.Color,kotlin.Function0,kotlin.Function1)
I'm trying to test a Text that on my component I can print it in different colors, so on my test I'm verifying it gets the expected color. I was looking for a method to return the color but I did not find any.
From now I'm asserting that the text is correct and the visibility is correct, but when trying to find the method to get the colour I get too deep and I'm looking for a simpler solution.
composeTestRule.onNode(hasTestTag("testTagForButton"), true)
.assertExists()
.assertTextEquals("Testing")
I've check that I can do something like .fetchSemanticsNode().layoutInfo.getModifierInfo() to get into the Modifier and perhaps from there I can get the colour, but it's too much maybe. Also I've found this .captureToImage() that perhaps I could get the colour on it, but since I had to put the pixels I decided that it's not the way.
Is there any simple way to get that?
I am by no means a compose expert, but just looking at compose source code, you could utilize their GetTextLayoutResult accessibility semantic action. This will contain all the properties that are used to render the Text on a canvas.
Some quick and dirty extension functions I put up for convenience:
fun SemanticsNodeInteraction.assertTextColor(
color: Color
): SemanticsNodeInteraction = assert(isOfColor(color))
private fun isOfColor(color: Color): SemanticsMatcher = SemanticsMatcher(
"${SemanticsProperties.Text.name} is of color '$color'"
) {
val textLayoutResults = mutableListOf<TextLayoutResult>()
it.config.getOrNull(SemanticsActions.GetTextLayoutResult)
?.action
?.invoke(textLayoutResults)
return#SemanticsMatcher if (textLayoutResults.isEmpty()) {
false
} else {
textLayoutResults.first().layoutInput.style.color == color
}
}
Which can be then used like this:
composeTestRule.onNode(hasTestTag("testTagForButton"), true)
.assertExists()
.assertTextEquals("Testing")
.assertTextColor(Color.Black)
I am unable to comment post above, also didn't find question about checking background color, so decide to place my version here.
private fun hasBackground(node: SemanticsNode, color: Color, shape: Shape): Boolean {
return node.layoutInfo.getModifierInfo().filter { modifierInfo ->
modifierInfo.modifier == Modifier.background(color, shape)
}.size == 1
}
To test background color and don't touch debug inspection info (this isn't for testing) we are unable to test only background color, but can test whole background by comparing production background (which placed into modifier) with our testing one.
Hope it help somebody.
I am using a BottomNavigation with 4 composables. All of them have a LazyColumn with each item in the LazyColumn having an image populated from the network using Coil for Jetpack Compose. Similar to Twitter/YouTube.
When I navigate between these items, the composables get destroyed and recompose only when navigated back to them. Even the coil images are cleared and re-fetched (from memory or local storage) when navigated between these composables. This is of course the expected behavior.
The problem is that this is causing the navigation between them to be too slow. Coil images take about 400ms to 700ms to load the image for every navigation. Apps like YouTube/LinkedIn are literally instant in their BottomBar navigations.
When I was using XML for this, I would make the fragments(used as bottom nav items ) with an appear/disappear logic to avoid this time delay while navigating between them.
How do I achieve the same with Compose ?
I am using the following versions:
//compose navigation
implementation "androidx.navigation:navigation-compose:2.4.0-beta01"
implementation "com.google.accompanist:accompanist-navigation-animation:0.21.0-beta"
Well I had the same problem using emulator or phone both work well with small simplistic composables. And when I create more complex Composable and try animating the navigation, using the accompanist animation library it gets very laggy.
But then I tried building the release APK file, since it is usually optimized and way faster, and that will significantly speed up your app. Here is link on how you can generate signed APK then install it on your phone or emulator and see if that fixes your problem!
You could also check if you accidentally disabled the hardware acceleration from the manifest. Make sure you set android:hardwareAccelerated="true" in you activity tag.
In case that does not help either, then you have to implement your own animation and use Shared ViewModel, for communication and triggering the transition from one Composable to another. The idea is that you can use modifier offset property to show/hide the Composable by placing it outside the screen.
First set your ViewModel, and add mutable state variable, that will trigger the transition from Home to Settings and vice versa.
This is not the best practice, since there is no way to directly pass data from one composable to another as you would normally do with the normal navigation. But you can still share data using the Shared ViewModel. Using this method it will not recompose your Composable, and thus be really fast. So far I have no problem with any out of memory exceptions even on some very old/slow devices with 2GB RAM.
class SharedViewModel : ViewModel() {
// changing this mutable state will trigger the transition animation
private val _switchHomeToSetting = mutableStateOf(true)
val switchHomeToSetting: State<Boolean> = _switchHomeToSetting
fun switchHomeToSettings() {
_switchHomeToSetting.value = !_switchHomeToSetting.value
}
}
Now create your two Composable functions Home and Settings respectively
#Composable
fun HomeScreen(viewModel: SharedViewModel) {
// draw your subcomponents
}
#Composable
fun SettingsScreen(viewModel: SharedViewModel) {
// draw your subcomponents
}
And finally initialize the animation in you main activity
class MainActivity : ComponentActivity() {
val viewModel by viewModels<CityWeatherViewModel>()
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContent {
// set your offset animation
val density = LocalDensity.current
val width = with(density) { (1.adw).toPx() }
val animatedOffsetX: Float by animateFloatAsState(
targetValue = if (!viewModel.switchHomeToSetting.value) 0f else width,
animationSpec = tween(1200)
)
// Home screen
Box(
modifier = Modifier
.fillMaxSize()
.offset { IntOffset((-width + animatedOffsetX).toInt(), 0) }
) {
HomeScreen(viewModel = viewModel)
}
// Settings screen
Box(
modifier = Modifier
.fillMaxSize()
.offset { IntOffset(animatedOffsetX.toInt(), 0) }
) {
SettingsScreen(viewModel = viewModel)
}
}
}
}
Here is the result using the Composable Navigation, together with the Accompanist Animation. As you can see it is very laggy indeed
And now here is the result using our custom animation, where it is very smooth since no Composable is recomposed.
I am trying to have a way to show a BottomSheet from everywhere within my app, for that I use the BottomSheetScaffold and a LiveData object that holds the current composable function which is observed as state:
val sheetContent by MusicHub.state.bottomSheet.getContent().observeAsState()
BottomSheetScaffold(
modifier = Modifier
.fillMaxSize(),
scaffoldState = bottomSheetScaffoldState,
sheetPeekHeight = 0.dp,
sheetContent = sheetContent!!
)
I use the BottomSheet as a context menu in my app. For example when i longClick on a playlist in my app it sets the content of the BottomSheet and shows it like this:
PlaylistItem(
// ...
onLongClick = {
// Set the LiveData composable
MusicHub.state.bottomSheet.setContent {
PlaylistContextMenuTest(playlist!!, viewModel)
}
// Expand BottomSheet
scope.launch {
MusicHub.state.bottomSheet.expand()
}
}
)
In general this works but the first time the BottomSheet gets expanded it shows for a split second before it disappears at the bottom again. Here is a small GIF:
My guess is that somehow the size of the BottomSheet is not recalculated yet and hence it only works in the next recomposition. Coming from web dev i would say its a typical case of requestAnimationFrame but i don't quite know how to solve this issue in compose.
Edit:
PlaylistContextMenuTest code:
#Composable
fun PlaylistContextMenuTest(playlist: Playlist, viewModel: LibraryViewModel = activityViewModel()){
val scrollState = rememberScrollState()
Column(
modifier = Modifier
.fillMaxWidth()
.navigationBarsPadding()
// TODO: Replace that with a percentage of the screen height
.heightIn(max = 384.dp)
.verticalScroll(scrollState),
content = {
ContextMenu {
repeat(4){
addOption(R.drawable.ic_delete_black_24dp, "Delete"){
Timber.d("Delete Playlist")
viewModel.deletePlaylist(playlist)
}
}
}
}
)
}
Full ContextMenu source: (https://pastebin.com/sg4ed96L)
You seem to be right. The first time it seems to be re-calculating the BottomSheet's height.
As this does not change on the second try, it will then be displayed.
Does this answer help you?
It seems to work out quite okay for BottomSheetScaffold, but not for ModalBottomSheetLayout (the thing I was looking for as you can see in the comments of the linked answer).
Edit: Accompanist's Navigation Material is also worth a look.
This issue has been resolved with a new release of jetpack compose. I am not sure if it was beta 8 or 9 but everything works as intended now.
I am using android compose jetpack version "0.1.0-dev14". According to application requirement, I want to auto focus TextField once screen is visible. and another scenario is like I want to focus next TextField in same screen on next ImeAction.Next action. I could not find any method or solution for this problem. If Anyone can help me to sole this problem, It will be really appreciated.
Thank you..!!
With 1.0.0 to achieve autofocus you can use:
DisposableEffect(Unit) {
focusRequester.requestFocus()
onDispose { }
}
In this way the system grants focus to the component associated with this FocusRequester.
For example:
val focusRequester = FocusRequester()
TextField(
//...
modifier = Modifier
// add focusRequester modifier
.focusRequester(focusRequester)
)
This sample shows how to request focus on the next view.
To achieve autofocus on first view on the screen, I believe this can be used:
// ... composable context...
onActive(callback = {
focusModifiers.first().requestFocus()
})
// ... composable context...