I recently wrote my first app for android, and I created a listview for selecting an element from a list of about 500 items. Since it's basically the default listview, it's searchable, and I can bring up the onscreen keyboard by holding down the menu button, but I was wondering if there was a way to bring up the keyboard automatically (and not make it freak out if the phone has a physical keyboard). Does anyone know how I can do this? I've been searching around and haven't found anything.
Add this to your xml activity list definition (AndroidManifest.xml)
android:windowSoftInputMode="stateAlwaysVisible|adjustResize"
Maybe not exactly what you want, nevertheless; you could add a EditText above your list. When this EditText gets focus (which it will by default when you show your activity, presuming it's the first GUI component on the layout) it will also automatically trigger the software keyboard.
The neat thing of this approach is that it gets even more intuitive for the user that he or she can actually search the list by entering a search criteria.
Related
Another day, another bug...
I have three AutoCompleteTextFields with the filter overrided to get completion from my REST service, but my big problem is that the suggestions popups of those text are clickthrough... so when I've already completed one of them, any click on the suggestion popup of another will trigger the underlying ACTF, which is already filled and so show it's own popup, making impossible to select the item from the other ACTF suggestion popup.
The two screenshots here show the situation, the ACTF are the textfield hinted "Partenaire", "Contact..." and the already autocompleted one under.
On the second screenshot, I've tried to select the item over the third ACTF, and so the four first results are from the third ACTF, and the four last are from the "Partenaire" ACTF.
Is there a way to override something like onShow() for the popup and it's hiding equivalent, so I could disable the other ACTF when I type in one of them ?
I think it's a good way to solve the problem, but I am open to any other idea :)
I've forget to mention it, but the problem occur on Android and on the simulator, but iOS has not such problem.
Check that your UI has scrolling set correctly, only one container in the hierarchy can be scrollable on the Y axis. By default the Form's content pane should be scrollable on Y (unless it's a border layout).
I'm writing an app using Titanium. I want to be able to automatically dismiss the keyboard anytime something outside of the text field is clicked. I have yet to find an elegant solution for this issue.
Couple things that I've thought about, but am still looking for a better solution:
Assign event listeners to basically everything else present in the view, and dismiss the keyboard (using textField.blur()). I want to avoid this since it results in a LOT of code just to dismiss the keyboard. Also, if I end up adding anything else to the view, I'll have to add a click listener to that object as well, so it's not very maintainable.
Create a large transparent view, and have it take up the entire screen. Place it directly beneath the text field and add to it one click listener on that which will dismiss the keyboard. This is a better solution than #1, but still isn't great because I've had a lot of trouble getting zIndexes to work properly. It's also inefficient for my purposes because I've got views with a specific width and height that encapsulate text fields. I've used these for the sake of code simplicity and I re-use them throughout my application.
I've tried adding a listener for the "blur" event for the text field but that doesn't seem to get fired appropriately.
That's about it. I'm sort of at a loss. The zIndexing also behaves strangely on the iPhone, and I haven't tried on Android yet. Also, as I mentioned above, many of the text fields I use are encapsulated within small views with set widths/heights-- so I think that will affect the functionality of Z-indexes.
So the root question is: What's the best way to dismiss a keyboard whenever anything outside the text field that's in focus is clicked?
If I'm correct the click event propagates through all views and windows therefore your #1 option could be modified to check for clicks on the bottom most layer (view or window), check for its source then decide what to do.
First of all, I am aware of about 1000 other questions regarding the android keyboard... I am aware I can manually hide keyboard from window or control, and pass in any number of flags that are supposed to control where and when keyboard pops up.
Basically, I aim to have PREDICTABLE keyboard handling in my app... that is that unless explicitly told to focus this control, and popup keyboard, it'll only pop up when a user taps a text edit.
This app is extensive, and manually attempting to hide keyboard from even just the focused control (vs explicitly hiding each and every edit field).
I am also aware I can avoid the popup up keyboard when you dont want it there, by setting focus on a non text editable field, however, that seems like more of a hack than anything else.
So my question is... is there a way to just force app to never auto pop up keyboard on new dialogs, fragments etc... app wide? If I want this text field to et focus on new dialog, I'll manually handle those cases. In addition, any way to automatically handle keyboard dissapear when the previously focused control dissapears?
I just dont get logic there... if I step back and think about this, I'd only want keyboard popping up if I wanted to go type something. As far as keyboard popping up immediately when new dialog opens... seems like the exceptional case (there may be a couple times I'd want to do that).
I dont mind building a manager or something that keeps track of the state of keyboard, however i dont know if I can get at the information I'd need to make it work in a remotely intuitive manner, efficiently.
Any pointers or ideas would be greatly appreciated... because I am at my whits end with this... and I can assure you I've spent a good deal of time researching this and attempting fixes.
Note: Sorry about the title or hostility... I've fought this for quite some time, and been generally infuriated with how bizarre dealing with the keyboard can be.
So my question is... is there a way to just force app to never auto pop up keyboard on new dialogs, fragments etc... app wide?
No.
But you can use:
this.getWindow().setSoftInputMode(WindowManager.LayoutParams.SOFT_INPUT_STATE_ALWAYS_HIDDEN);
On each activity.
Ok, I think I get what you're asking. Have a look at the second answer here:
Stop EditText from gaining focus at Activity startup
You can specify in your AndroidManifest.xml whether or not the softkeyboard should be hidden by adding this android:windowSoftInputMode="stateHidden" to the beginning of your activities tag (<activity>)
I'm new into android and i'm dealing with the following problem. I need to create a button which groups another two buttons of similar features (sort of submenu). So let's say we have a button called "search", by clicking on it the search button should disappear and the two buttons (e.g. "google" and "bing") should be seen on the screen.
So, my idea was to manage all three buttons programmatically in the same layout instead of creating a new (temp)layout just to show and handle the two buttons. Like a state machine. More precisely it would be like this:
We press on the "search" button.
onClick(View) determines wheter we are on the main screen (mode=mainmenu), renames the search button to "google" and creates the second button named "bing", or (mode=submenu) then call the function of the button due to the search button is already renamed to "google"...
By pressing the back button onBackPressed() checks if we are in the submenu (mode=submenu) then hide the "bing" button and rename "google" to "search", otherwise we are in the main menu (mode=mainmenu), finish the activity.
Does this make sense at all? Besides this will produce lots of code with rising count of buttons and (sub)menus and worse maintainability for further changes.
Thanks!
P.S. Sorry if my english sucks (not my native language) ;-)
That's too much code and too much debugging will be needed, so I think, a better way is just creating a new layout.
Well if you have performance issues or expecting performance issues can arise (due to complexity of you GUI) then may be this make sense. But if not, code simplicity is more important than slight increase in performance.
You can create an button that remain invisible(gone, to be exact) until the "search" button is pressed, and rename the original search button. It works, and it will be easier to implement if you set up layout in xml. It also give you a preview that shows what it looks like. To show widget programmatically will have code that hard to maintain.
However, the design that change button text is not a good design. First, when the "search" is pressed, changing its text is very confusing. I personally suggest you to pop-out a selection dialog. Or just show both search button at first place, unless you really do not have place for two button.
The home screen of my Android application has three EditText views, meant to be used as three different search functions, each with a "Search" button.
The app works perfectly on the device (G1) when using the trackball: I can move between the EditTexts with the trackball, all the events fire as expected, I can enter text using the physical keyboard in the selected EditText, Enter correctly submits the proper search, etc.
etc.
However, I can't switch between the EditText views using touches - only by using the trackball. Touches seem to be completely ignored by the EditText. Touches do fire for the buttons, but very hard - takes a lot of tries to make a touch register.
In the simulator, clicking on any EditText does nothing - the first one always remains selected, and I never get a soft keyboard.
This is all inside a TabHost - I've read there are some problems with that configuration, but it sounds like a slightly different issue (the EditText doesn't seem to lose focus - everything works perfectly with the trackball).
Any suggestions for what I can check?
It sounds like your touch targets are too small. I would suggest adding some padding to each of your EditTexts, or using a TouchDelegate to increase the size of the touch target.
Ah, I figured it out.
I had a ListView left in my layout from when I first set up the TabHost. Since it didn't show anything on the screen, and it was at the bottom of my layout file after everything else, I didn't notice it... Just noticed it didn't belong there and erased it, and all the controls started behaving properly.
D'oh.