I have an android dialog with EditText in it.
When the user clicks the EditText, the keyboard is opened
but the dialog is shrink.
The dialog root background is a 9patch
I want it to be cut, meaning its corners won't be rounded but square.
Now, the user might think the shrink dialog is the dialog full size.
I want the keyboard to be laid on the dialog in a way the user will see the dialog is originally larger there are not visible fields.
I have tried this on the activity that opens the dialog:
mDialog.getWindow().setSoftInputMode(
WindowManager.LayoutParams.SOFT_INPUT_ADJUST_PAN);
manifest:
android:windowSoftInputMode="adjustPan"
See my similar answer here: https://stackoverflow.com/a/22463549/335650
Is any part of your layout a scrollable container (like ListView)? If
so, try setting android:isScrollContainer="false" on that item in your
XML layout.
If you have any views which have android:isScrollContainer="true", the
layout manager will attempt to resize your layout when the keyboard
pops up, regardless of `android:windowSoftInputMode'.
Related
I have a Popup window where pressing on a button opens a Snackbar. I want this Snackbar to show on the bottom of the screen, not on the bottom of the popup window, so I pass the root View to the Snackbar.make function instead of the popup view.
The Snackbar shows up on the bottom of the screen now, but since the screen behind the popup window is darkened, the snackbar object is also shown behind the gray filter.
I would like to keep this gray layer above the window behind the popup window while showing the snackbar as if it were on the top layer (without the gray filter on it). How do I do that?
Thanks!
Make a Snackbar opening function on the fragment or activity, then when you instantiate the PopupView you pass the method through a listener.
When the keyboard in my application is open, the BottomNavigationView is attached to the keyboard. So I added in AndroidManifest android: windowSoftInputMode = "adjustPan" but now the keyboard covers the bottom of the content. That is, ScrollView cannot change the maximum height to the keyboard. As if the fragment does not see when the keyboard is turned on. How can I show the keyboard so that the fragment adapts and the BottomNavigationView disappears. Help me pls.
Nothing can change the maximum height of the keyboard. The keyboard itself gets to decide that. There are only 2 actions you can take when the keyboard appears- pan or resize. The first will scroll your app so that the cursor appears on screen. The second will relayout your app in the space above the keyboard. Which if your screen is designed to can shrink extra space to make more stuff fit.
There is no option to hide certain views when the keyboard appears. There are hacks you can find that try to detect when the keyboard appears, but they all have flaws and ways they break. Android isn't set up to enable you to know when the keyboard is onscreen. You can try one of those, but more realistically you're going to live with this behavior.
I need to know how to select a layout for a java swing application with multiple windows.
It has a dashboard kind home or main window with few icons(12 or more) on it. Clicking on an icon it will open a complex window on top of it then the main window is no longer visible. There will be another home icon to get back to main window on new view. Complex in the sense the opened window will have a tabbed layout. What i need to know is what layout should I use for this purpose.
Card layout and layered layout are the candidates I suppose. Or should I use separate frames or is there some other option available.
If the window can take the full screen and position the icons on it zooming appropriately according to the screen size would be great.
I'm glad if you can provide me a reference to a sample code.
Thank you in advance for helping me out.
I suppose you want to hide home screen when user opens another screen, and show it again when user clicks something like "Home" button.
For similar thing, I used JLayeredPane. It essentially allows you to sat Z-order for your components. In this case, you would have a JPanel for each screen you want to show, and you need to place it inside JLayeredPane, with home screen being initially on top. When you want to show another screen, you set it's layer to be topmost.
I have a fragment in my app that has a scroll view for the signup and login pages. Right now there isn't enough content in the scroll view to actually make it scroll, however when the keyboard appears, it does cover up most of the content in the view. This causes a lot of issues especially on devices with smaller screens, it blocks a lot, and the view is NOT scrollable, so I have to close the keyboard to get to the rest of the inputs.
I need the bottom of the fragments frame layout to be pushed up to JUST above the top of the keyboard, so the keyboard won't actually hide any content, and still allow the scroll view to actually scroll to the rest of the content.
I have seen the usual fix to an issue similar to this, which would to change the AndroidManifest.xml to the following:
android:windowSoftInputMode="adjustResize"
but this will push up the entire page, which includes the footer view I have under and outside of the login and signup fragment layouts. It makes my scrollview smaller and allows for it to scroll, but I need the footer to stay hidden under the keyboard still.
I think a work around to this would be to have override onConfigurationChanged(); in MyActivity that will detect if the keyboard has appeared, and if it has, push the bottom of the framelayout to be JUST above the keyboard, thus making the scroll view smaller, and allowing us to actually scroll. I am not quite sure HOW to do this though.
Here is what it looks like with the keyboard up, blocking the content. This would be okay IF the scroll view was scrollable, allowing me to see the rest of the content, however it will not scroll and the only way to access the content under it is to close the keyboard first.
EDIT
I was able to use the answer below, editing the Android manifest for
android:windowSoftInputMode="adjustResize"
and the first method using the code below
final View activityRootView = findViewById(R.id.activityRoot);
activityRootView.getViewTreeObserver().addOnGlobalLayoutListener(new OnGlobalLayoutListener() {
#Override
public void onGlobalLayout() {
int heightDiff = activityRootView.getRootView().getHeight() - activityRootView.getHeight();
if (heightDiff > 100) { // if more than 100 pixels, its probably a keyboard...
... do something here
}
}
});
I had it adjust my views so the footer would be pushed way down below, then resize the layout holding the fragment to extend down allowing it to be scrollable still.
Okay, here's how I solved it.
The basic idea is that you have to:
Detect whether or not a soft-keyboard is showing,
React. Based on the detected information (is-soft-keyboard-showing), resize your layout accordingly.
There are two ways of achieving this:
to give your activity's root view a known ID, say '#+id/activityRoot', hook a GlobalLayoutListener into the ViewTreeObserver, and from there calculate the size diff between your activity's view root and the window size:
Customize your top-level layout class into one which overrides onMeasure()
And I would like to credit the above answer to this SO Post: how-to-check-visibility-of-software-keyboard-in-android, which I have found earlier on this particular problem.
I have an app with ListView in it and I added search functionality to it. When I press on EditText and it opens keyboard, it pushes everything in the layout along with it.
Normal layout:
With keyboard:
As you can see; the ad, play button, seekbar are all pushed up along with the keyboard, but I don't want that. Is there a way I can avoid this?
I tried adding this to Manifest file:
android:windowSoftInputMode="stateUnchanged"
But that doesn't work.
You probably want to use "adjustPan".
From the documentation:
The activity's main window is not resized to make room for the soft
keyboard. Rather, the contents of the window are automatically panned
so that the current focus is never obscured by the keyboard and users
can always see what they are typing. This is generally less desirable
than resizing, because the user may need to close the soft keyboard to
get at and interact with obscured parts of the window.