I have a ModalBottomSheetLayout with a list of items in my Compose view, which can be showed by some UI interaction.
By default, when bottomSheetState.show() is called, the visible ratio for the BottomSheet is 50%. However, this is not ideal from a UX perspective as the user will have to physically pull up the bottom sheet to see all the contents in the list.
Extremely frustrating is the fact that bottomSheetState.show() does not take in any parameters, and that the 50% value seems to be hard coded in. According to the declaration in androix.compose.material:
suspend fun show() {
val targetValue =
if (isHalfExpandedEnabled) HalfExpanded
else Expanded
animateTo(targetValue = targetValue)
}
I would like to instead show a custom value, say 75%, when the bottom sheet is showed, but so far I haven't found a way to do so. Is there a workaround to this?
I am not sure if you can make it 75% visible but you can show it expanded
bottomSheetState.animateTo(ModalBottomSheetValue.Expanded)
Related
I have this code
setContent {
val items = mutableListOf<Int>().apply {
(1..100).forEach { add(it) }
}
LazyColumn {
items(items) { item ->
TextField("$item", {})
}
}
}
With android:windowSoftInputMode="adjustResize" in my AndroidManifest.xml.
If I click on a TextField at the top of the list, I can enter text fine.
If I click on a TextField near the bottom of the screen, the keyboard appears momentarily, then disappears quickly after, and prevents me from entering text.
How can I enter text when the TextField is at the bottom of the screen? Thanks!
Your keyboard disappears after having appeared for a brief, shiny moment. Here's the reason:
You tap the TextField, it calls it's built-in focus requestor, and requests the focus from the OS by calling appropriate (or inappropriate, who's to say) internal methods, as a result of which, the keyboard pops out (again, built-in mechanism.) and you can type all the more you want... AS LONG AS THE FIELD IS VISIBLE; or in Compose terms, long as the Composable holding the requestor, is in composition.
It should be clear, that once the Composable that owns the focus requestor goes off the screen, it is destroyed (well not every time, there are only certain specific cases when it is destroyed..., but yours is one of them), and when the Composable is destroyed, the focus requestor is destroyed. No focus requestor, no focus owner - the keyboard vanishes.
Now this is really important because you are using a LazyColumn, a lazy Composable, infamous for its merciless slaughtering of the Composables that are no longer visible to the user. HENCE, as long as it is the top (or other "visible") textfield that is in concern, it stays and works as expected. However, the bottom textfield, as the keyboard pops up, goes so much out of the visible bounds, that it gets slaughtered (recycled is the technical term, but what fun is that?), taking away the purpose of the keyboard.
Now, the lazy column, like any criminal, left a clue behind, and didn't notice it, which lead us to catch him red-handed. It is quite interesting, really, to see the column in action.
Now, workarounds include using a column, instead of a lazy column; creating your own lazy column using a custom lazy Composable, and manually handling the heap size for the Composable so the final field doesn't go out of composition.
That's it, you're cured.
Just leaving another answer, since OP didn't verify other purpose of him specifying adjustResize,if whether removing or changing it will be fine, but another solution aside from the mentioned comment about different API version is specifying adjustPan, which worked in my case, either
via AndroidManifest
android:windowSoftInputMode="adjustPan"
or programmatically
window.setSoftInputMode(WindowManager.LayoutParams.SOFT_INPUT_ADJUST_PAN)
Same code base but with adjustPan
This issue is fixed in the current alpha version 1.4.0-alpha05
https://issuetracker.google.com/issues/179203700
I'm using Jetpack Compose with the BottomSheetScaffold. To be able to show and hide the bottom sheet from both within and outside the composable, I used a showBottomSheet: MutableState<Boolean> variable. The peek height within the composable is then determined like this:
val baseBottomSheetPeekHeight by remember { mutableStateOf(60.dp) }
val bottomSheetPeekHeight = if (showBottomSheet.value) baseBottomSheetPeekHeight else 0.dp
Later, in the BottomSheetScaffold, I use the variable like this:
BottomSheetScaffold(
...
sheetPeekHeight = bottomSheetPeekHeight,
...
)
(Full reproducer project here: https://github.com/dbrgn/compose-repro)
This generally works as intended, I can set showBottomSheet.value to false to hide the bottom sheet. However, the hiding looks janky, because not all sub-composables are hidden at the same time.
It's a bit hard to see in the animation above due to the GIF conversion, but when closing the bottom sheet peek pane, the other content (below it) is visible for a short moment, before the bottom sheet disappears.
Is there a way to avoid this janky hiding behavior? Or even better, is there a way to smoothly animate the hiding of the pane?
In my case for Smooth closing BottomSheetScaffold I used to: scaffoldState.bottomSheetState.animateTo(Collapsed, tween(duration))
-- (when duration is any Int you want).
The same for Expanding:
scaffoldState.bottomSheetState.animateTo(Expanded, tween(duration))
If you look at the source code of collapse() or expand() function, you will see there just calling animateTo(Expanded) and animateTo(Collapsed). You can customize animateTo() as you wish.
See animateTo() documentation.
I am trying to make an image picker component in LibreOffice.
I have a dialog that is dynamically filled with images. When the user clicks on one images, it should be selected and the dialog should be closed.
The problem is that the number of images is variable. So I need to enable scrolling in the dialog (so that the user can navigate through all images).
There seems to be some properties on the dialog object (Scrollbars, Scroll width, Scroll height, etc)
However, I cannot find a way to use them anywhere.
Any ideas?
The scrollbar is one of the Controls available through the dialog box editor. That is the easier way to put a ScrollBar on a dialog box. Just insert it like any other control. There is a harder way via DialogModel.addControl but that seems non-essential to answering this question.
If you add a scrollbar to the dialog box and run the dialog box, you will find it does nothing by default. The functionality (apparently) must be written into a macro. The appropriate triggering event is the While Adjusting event on the ScrollBar object, although it does not trigger the macro simply with the "Test Mode" function in the dialog editor. Running the dialog box through a macro triggers the While Adjusting event when the scroll arrows are triggered, when the slider area is clicked to move the slider, and when the slider itself is dragged. The Object variable returned by the scrollbar event contains a property .Value which is an absolute value between 0 and the EventObject.Model.ScrollValueMax, which allows you to manipulate the other objects on the page manually based on the position of the slider.
Yes, that's right, manipulate objects manually. The sole example I found, from the LibreOffice 4.5 SDK, does precisely this. Of course, it is not as bad as it sounds, because one can iterate through all of the objects on the page by reading the array Dialog.getControls(). In any event, the secret sauce of the example provided in the SDK is to define Static variables to save the initial positions of all of the objects you manipulate with the scrollbar and then simply index those initial positions based on a ratio derived from the scrollbar Value divided by the ScrollValueMax.
Here is a very simple working example of how to scroll. This requires a saved Dialog1 in the Standard library of your document, which contains an object ScrollBar1 (a vertical scrollbar) and Label1 anywhere in the dialog. The ScrollBar1 must be configured to execute the macro ScrBar subroutine (below) on the While Adjusting event. Open the dialog by executing the OpenDialog macro and the scrollbar will move the Label1 control up and down in proportion to the page.
Sub OpenDialog
DialogLibraries.LoadLibrary("Standard")
oVariable = DialogLibraries.Standard.Dialog1
oDialog1 = CreateUnoDialog( oVariable )
oDialog1.Execute()
End Sub
Sub ScrBar (oEventObj As Object)
Static bInit As Boolean
Static PositionLbl1Y0 As Long
oSrc = oEventObj.Source
oSrcModel = oSrc.Model
scrollRatio = oEventObj.Value / oSrcModel.ScrollValueMax
oContx = oSrc.Context
oContxModl = oContx.Model
oLbl1 = oContx.getControl("Label1")
oLbl1Model = oLbl1.Model
REM on initialization remember the position of the label
If bInit = False Then
bInit = True
PositionLbl1Y0 = oLbl1Model.PositionY
End If
oLbl1Model.PositionY = PositionLbl1Y0 - (scrollRatio * oContx.Size.Height)
End Sub
The example provided by the SDK does not run on my setup, but the principles are sound.
There appears to be a second improvised method closer to the functionality one might expect. This method uses the DialogModel.scrollTop property. The property appears to iterate the entire box up or down as a scroll based on the user input. There are two problems using this methodology, however. First, unless you put the scrollbar somewhere else, the scroll bar will scroll away along with the rest of the page. You will need to adjust the location of the scrollbar precisely to compensate for/negate the scrolling of the entire page. In the example below I tried but did not perfect this. Second, the property seems to miss inputs with frequency and easily goes out of alignment/ enters a maladjusted state. Perhaps you can overcome these limitations. Here is the example, relying on the same setup described above.
Sub ScrBar (oEventObj As Object)
Static scrollPos
oSrc = oEventObj.Source
oSrcModel = oSrc.Model
scrollRatio = oEventObj.Value / oSrcModel.ScrollValueMax
If IsEmpty(scrollPos) = False Then
scrollDiff = oEventObj.Value - scrollPos
Else
scrollDiff = oEventObj.Value
End If
scrollPos = oEventObj.Value
oContx = oSrc.Context
oContxModl = oContx.Model
oContxModl.scrollTop = scrollDiff * -1
oSrcModel.PositionY=(scrollRatio * oContx.Size.Height/5) * -1
End Sub
This (sort of) will scroll the contents of the entire dialog box, within limits and with the caveats noted above.
I have this tool tip that is created every so often. What is the appropriate actionscript etiquite?
A. To Create and remove the tooltip moveclip when needed?
or
B. To hide and show the tooltip movieclip when needed?
With these A and B, the answer is B, because creating and then removing an object a lot of times creates a lot of garbage in the memory, which eventually leads to garbage collector calls, that slow your SWF's performance. You can easily go with a single tooltip MC, just fill it with information that corresponds to the new mouse coordinates before you show it.
There is another question, not so straightforward as yours, about how to hide and show a movie clip, either via visible property or via addChild() and removeChild() (AS3 only). If you are using AS2 or AS1, use visible property to hide and show your tooltip.
There are three ways to hide something in Actionscript : Alpha, visible and remove child.
Apha: If you turn the alpha zero the renderer always comes to this displayObject and renders it at alpha zero. So the object is always rendered you just cannot see it.
Visible == false In this case the object still exists in your displaylist. So the renderer comes to the object. Sees it's property is false and leaves it but it still exists in the display list.
removeChild This means that you're removing the object from the display list. This means that the renderer never had to even check for it. Which makes it the fastest option.
addChild doesn't take that much computing power as visible check. I'm sure you can find benchmarks on this.
If you don't have a lot of objects on yours screen and the tooltip is there every second I'd go with visible is false. In all other cases go with the third option.
On a side note, I've found it always easier to manage them with a toolTipManager. A class that makes sure that you have one tooltip on the screen because usually users only use one tooltip. So that makes things easier for me. I just always create the necessary tooltips and add them to the displaylist when required and remove them. (Not recreate them) At the same time have only one tooltip on stage.
Is it possible to add gui components to blackberry screen beginning from the bottom instead of the top ?
Thanks
A quick response would be no but let me explain why and suggest afew work arounds;
Screens don't actually handle the laying out of fields onto themselves, to do this they delcare a delegate manager which can be any type of manager, vertical, horizontal etc. The problem is all managers begin painting themselves from the top left. For a manager to paint fields starting from the bottom it would have to know exaclty where the bottom is located and add components up rather than down which goes against all the low level code inside the manager class. You can read more on managers in the BlackBerry API documentation.
You could still achieve an effect similar to this though by tweaking how you add fields and playing with field styles. For example consider this code:
add(new LabelField("field 1"));
add(new LabelField("field 2"));
This would give us the results;
field 1
field 2
because field 1 is drawn then field 2 below it. However if we were always to insert fields at the begining of our manager e.g. position 0 like so:
insert(new LabelField("field 1", FIELD_BOTTOM), 0);
insert(new LabelField("field 2", FIELD_BOTTOM), 0);
We would get the results;
field 2
field 1
Which is the results you'd expect from a screen described in your question.
I'm not really sure how you'd get the fields to paint to the bottom of a screen though, you could try researching the "position relative bottom" styles but I'm honestly unsure.
You are probably using a VerticalFieldManager, and the documentation on that says:
A vertical field manager lays out
fields top to bottom in a single
column.
So if you
manager.add(field1);
manager.add(field2);
manager.add(field3);
The order of the fields on the screen will be just that.
But you could do something like this:
Vector v = new Vector();
v.add(field1);
v.add(field2);
v.add(field3);
for(int i=v.size()-1;i>=0;i--) {
manager.add((Field)v.elementAt(i));
}
Sort of. You can use the Manager#insert(Field, int) method and always insert at the zero index. If you do this with a VerticalFieldManager, it would simulate a bottom-up adding of Fields to the Manager.
Some of the answers so far are to use Manager.insert(Field, int), and keep inserting at position 0. This will work, but the running time of the insert is linear in the number of elements already added to the manager. Meaning this solution will have an overall quadratic running time. Not a big deal if you're adding under 10 fields, but if you're planning on adding more than that, the insert overhead will be substantial.
If you can do the inserts top to bottom, by reordering the fields as Muger's solution suggests, the running time will be much improved.
Finally, you can write your own BottomUpVerticalFieldManager that does the layout the way you want. When you write your own manager, you can layout the fields in whatever way pleases you. In this case, it would be bottom to top. Writing your own manager may seem daunting, but it will give you considerable freedom in the future when trying to solve layout issues.