I have several widgets in a view, each needing its own ActionMode. I see that the ActionMode does not dismiss automatically when the user taps outside the action bar. Thus, it is easily possible for the user to start an ActionMode for one control, then tap (longclick in my case) another control and stack a second ActionBar on top of the first. This causes programming logic havoc.
I can keep track of the current ActionMode with an activity-level member variable and dismiss the current one if a new one is needed. Howewver, this is making my code messy to read and maintain. And further, I'd prefer to dismiss it immediately when the user taps anything outside the action bar.
Any suggestions on a good way to handle this?
I was looking for a solution of this problem some time ago and as I know you couldn't track it without saving current action-mode state in a global variable. However I don't think that one variable with proper name would make your code messy.
Related
I am not quite sure what I should be searching for, so I thought I would ask if anyone could 1) Help me identify the NAME of what it is I am trying to create or 2) give me an idea of a library / how I would go about creating this.
See this (Poorly-drawn) picture:
What I am trying to do is to create a normal Fragment which has normal content in it, but when you press a button somewhere (IE action bar), it creates a recyclerview that is "floating" as a type of overlay on top of your fragment. Ideally if the user clicks elsewhere, it will close it (So it should simulate the behavior of a dismissible dialog box), but also allow clicking within the view itself.
Also, if possible, I want to make a connection between the + sign and the recyclerview (Like a line or something) just to indicate it is connected and is an overlay.
Anyone have any recommendations as to what I should do or what I should be looking for? Thanks!
-Sil
You can place your RecyclerView within a DialogFragment. That way you can get the overlay feel, and you can also dismiss it when user clicks anywhere outside of it.
Say I have several dialog fragments that are shown in response to messages and events that can arrive in any order. Normally, the last dialog shown will be on top. Is there a way to show a dialog fragment under an existing one, or change their z-order after they are shown?
It should be pretty rare for my app to show more than one dialog at a time, but it could happen. There is one particular dialog that should always be on top whenever it's visible.
A dialog creates an application sub-window. Android's window manager (WindowManagerService) automatically computes window's z-order depending on its type and stores it in WindowState's mLayer field. Internal Android classes have access to this field and change window's z-order sometimes, but this API is not exposed to Android SDK. So it seems that the only way to affect dialog's z-order is to recreate it.
Everything I wrote above is just a result of a brief investigation of Android's source code so I may be wrong. And maybe there's some hacky way to do what you want using reflection and accessing private fields and methods. But I'm not sure it's a good idea to try and do it. In my opinion it would be better to have just a single dialog or even activity, and manage fragments within it.
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 have a Seekbar and I want to save the state to database when the progress is changed.
I am wondering in which event to put my code onProgressChanged vs. onStopTrackingTouch?
I am going to disagree with both mbaird and jqpubliq, for one simple reason: they assume the user is using a touchscreen.
Most Android devices have touchscreens. Not all will. For example, there are firms developing Android set-top boxes (think Android equivalents of Roku or Boxee Box). Most televisions are not touchscreens.
Now, if you want your application to only be usable with a touchscreen -- and you have set the appropriate <uses-configuration> elements in your manifest -- onStopTrackingTouch() may be reliable for detecting a progress change.
Personally, I would update the database on neither onProgressChanged() nor onStopTrackingTouch(), but at the point when the user does something positive to indicate they want to persist the current screen's contents -- pressing the BACK button, clicking a Save button, etc. But I certainly would not rely on onStopTrackingTouch() unless you are developing a touchscreen-only app.
I would use onProgressChanged if you need to update any elements of the UI as the user is sliding the progress bar.
I would wait for onStopTrackingTouch to actually update the database.
Unless you have reason to believe that the application will often crash in the middle of the gesture and you need to save where the user was at that time, I would recommend onStopTrackingTouch.