Develop Reference

Multiple EditText in ListView, tap to focus on one EditText and focus jumps to the first

I've got EditTexts in my rows in a ListView. When I tap on one of the EditTexts the soft keyboard appears and the focus jumps to the first EditText in the list instead of staying in the field where I tapped.
Here is a video of it:
https://youtu.be/ZwuFrX-WWBo
I created a completely stripped down app to demonstrate the problem. The full code is here: https://pastebin.com/YT8rxqKa
I'm not doing anything to alter the focus in my code:
#Override
public View getView(int position, View convertView, ViewGroup parent) {
if (convertView == null) {
convertView = layoutInflater.inflate(R.layout.cell_textfield, parent, false);
}
TextView label = (TextView) convertView.findViewById(R.id.textview1);
EditText textfield = (EditText) convertView.findViewById(R.id.textview2);
String text = String.format("Row %d", position);
label.setText(text);
textfield.setText(text);
return convertView;
}
I found another post on StackOverflow giving a workaround for this dumb Android behavior, which involves putting an OnFocusChangedListener on all of the textfields so they can retake focus if it's taken from them improperly.
That worked to regain focus, but then I discovered that when a textfield retakes focus the cursor ends up at the start of the text instead of end, which is unnatural and annoying to my users.
Here is a video of that:
https://youtu.be/A35wLqbuIac
Here's the code for that OnFocusChangeListener. It works to fight the stupid Android behavior of moving focus, but the cursor is misplaced after it regains focus.
View.OnFocusChangeListener onFocusChangeListener = new View.OnFocusChangeListener() {
#Override
public void onFocusChange(View view, boolean hasFocus) {
long t = System.currentTimeMillis();
long delta = t - focusTime;
if (hasFocus) { // gained focus
if (delta > minDeltaForReFocus) {
focusTime = t;
focusTarget = view;
}
}
else { // lost focus
if (delta <= minDeltaForReFocus && view == focusTarget) {
focusTarget.post(new Runnable() { // reset focus to target
public void run() {
Log.d("BA", "requesting focus");
focusTarget.requestFocus();
}
});
}
}
}
};
I hate having to put a bandaid on a bandaid on a bandaid to try to get Android to just behave as it would naturally be expected to behave, but I'll take what I can get.
1) Is there something I can do to fix this problem at the source and not have to have the OnFocusChangeListener at all?
2) If (1) isn't possible, then how can I make sure that when I force focus back to the correct field that I make sure the cursor is placed at the end? I tried using setSelection() right after requestFocus() but since the textfield wasn't yet focused the selection is ignored.

Here was my "solution." In short: ListViews are stupid and will always be a total nightmare when EditTexts are involved, so I changed my Fragment/Adapter code to be able to adapt to either a ListView layout or a ScrollView layout. It only works if you have a small number of rows, because the scrollview implementation isn't able to take advantage of lazy-loading and view recycling. Thankfully, any situation wherein I want EditTexts in a ListView, I rarely have more than 20 rows or so.
When inflating my view in my BaseListFragment, I get my layout id via a method that relies on a hasTextFields() method:
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
View view = inflater.inflate(getLayoutId(), container, false);
return view;
}
public boolean hasTextfields() {
return false;
}
public int getLayoutId() {
if (hasTextfields()) {
return R.layout.scrollfragment;
} else {
return R.layout.listfragment;
}
}
In my various subclasses of my BaseListFragment, if I need to have an EditText in one of my fields, I just override the hasTextFields() method to return true and then my fragment/adapter switchs over to using the basic scrollview implementation.
From there, it's a matter of making sure that the Adapter handles the standard ListView actions for both the ListView and the ScrollView scenarios. Like this:
public void notifyDataSetChanged() {
// If scrollContainer is not null, that means we're in a ScrollView setup
if (this.scrollContainer != null) {
// intentionally not calling super
this.scrollContainer.removeAllViews();
this.setupRows();
} else {
// use the real ListView
super.notifyDataSetChanged();
}
}
public void setupRows() {
for (int i = 0; i < this.getCount(); i++) {
View view = this.getView(i, null, this.scrollContainer);
view.setOnClickListener(myItemClickListener);
this.scrollContainer.addView(view);
}
}
One issue that the click listener presented is that a ListView wants an AdapterView.OnItemClickListener, but arbitrary Views inside a ScrollView want a simple View.OnClickListener. So, I made my ItemClickListener also implement View.OnClickListener and then just dispatched the OnClick to the OnItemClick method:
public class MyItemClickListener implements AdapterView.OnItemClickListener, View.OnClickListener {
#Override
public void onClick(View v) {
// You can either have your Adapter set the tag on the View to be its position
// or you could have your click listener use v.getParent() and iterate through
// the children to find the position. I find its faster and easier to have my
// adapter set the Tag on the view.
int position = v.getTag();
this.onItemClick(null, v, config.getPosition(), 0);
}
#Override
public void onItemClick(AdapterView<?> parent, View view, int position, long id) {
// ...
}
}
Then in MyEditTextListFragment, I create the adapter like this:
listener = createClickListener();
adapter = createListAdapter();
if (scrollContainer != null) {
adapter.setScrollContainer(scrollContainer);
adapter.setMenuItemClickListener(listener);
adapter.setupRows();
} else {
getListView().setOnItemClickListener(listener);
getListView().setAdapter(adapter);
}
Here is my scrollfragment.xml for reference:
<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout
xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:background="#fff"
android:clickable="true"
>
<!--
The following LinearLayout as a focus catcher that won't cause the keyboard to
show without it, the virtual keyboard shows up immediately/always which means we
never get to the enjoy the full size of our screen while scrolling, and
that sucks.
-->
<LinearLayout
android:focusable="true"
android:focusableInTouchMode="true"
android:layout_width="0px"
android:layout_height="0px"/>
<!--
This ListView is still included in the layout but set to visibility=gone. List
fragments require a standard ListView in the layout, so this gets us past that
check and allows us to use the same adapter code in both listview and scrollview
situations.
-->
<ListView android:id="#id/android:list"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:layout_weight="1"
android:drawSelectorOnTop="false"
android:background="#null"
android:layout_alignParentTop="true"
android:descendantFocusability="afterDescendants"
android:visibility="gone"
/>
<!--
This scrollview will act as our fake listview so that we don't have to deal with
all the stupid crap that comes along with having EditTexts inside a ListView.
-->
<ScrollView
android:id="#+id/scrollView"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:descendantFocusability="afterDescendants"
>
<LinearLayout
android:id="#+id/scrollContainer"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:orientation="vertical"
>
</LinearLayout>
</ScrollView>
</RelativeLayout>

Try this once, it worked for me:
public void setCursorPosition() {
focusTarget.requestFocus();
focusTarget.setCursorVisible(true);
other.setCursorVisible(false);
} else {
other.setCursorVisible(true);
focusTarget.setCursorVisible(false);
}
}

android talkback accessibility - customizing sounds

I've created my own set of alphabetical sounds (replacing the regular a,b,c,..z). I'd like to customize the talkback functionality so it uses my own sounds instead of the built-in ones when using my own app. This means that when a visually impaired user would try to read the content of a label in my app he'd hear my own sounds. Is this possible? If so, what would be the right way to achieve this?

Assuming your own sounds have a "phonetic spelling" this would be pretty easy. Let's say you had the letter A and you wanted it to pronounce as "A" and not the sound "uh". You could simply replace "A" with "ay" and TalkBack would pronounce it correctly. Assuming this is the case, what you want to do is very easy. If what you have created is actual sounds, and cannot simply use phonetic spellings as I am assuming, as alanv has said, this is impossible. Or at least, involves more than just changes to your app!!!
What you want to do is intercept all accessibility events coming from your application, and then when you intercept the events, replace the content description with your phonetically spelled content description. The tricky part is emulating TalkBack logic for grabbing text from Accessibility events, so that you grab the correct text! Otherwise you end up modifying the wrong string, or just nothing.
If you attach this accessibility delegate to the views within your view heirarchy, you can override the content description of the accessibility node infos, and replace it with your phonetic pronunciations. I attached all relevant portions of my solution. There may be a way to get this working by only mucking with the root view's accessibility delegate, and not the entire view hierarchy. I may investigate more later, but this works just dandy, and is a linear operation on load (and view addition for dynamic content) which isn't bad at all.
Add this code to your onCreate method, and modify the "convertText" function to suit your needs, and you should be all set!
final View.AccessibilityDelegate accessiblityDelegate = new View.AccessibilityDelegate() {
String convertText(String argString) {
//Do your phonetic conversion in here!
//A little Regex. A little String replacement and you're golden!
return argString;
}
#Override
public void onInitializeAccessibilityNodeInfo(View host, AccessibilityNodeInfo nodeInfo) {
super.onInitializeAccessibilityNodeInfo(host, nodeInfo);
String text = null;
if (nodeInfo.getContentDescription() != null) {
text = convertText(nodeInfo.getContentDescription().toString());
} else if (nodeInfo.getText() != null) {
text = convertText(nodeInfo.getText().toString());
} else if (host instanceof TextView) {
TextView textView = (TextView)host;
text = convertText(textView.getText().toString());
}
if (text != null) nodeInfo.setContentDescription(text);
}
};
rootView.addOnLayoutChangeListener(new View.OnLayoutChangeListener() {
#Override
public void onLayoutChange(View v, int left, int top, int right, int bottom, int oldLeft, int oldTop, int oldRight, int oldBottom) {
addAccessibilityDelegateToViews(v);
}
private void addAccessibilityDelegateToViews(View v) {
v.setAccessibilityDelegate(accessiblityDelegate);
if (v instanceof ViewGroup) {
ViewGroup viewGroup = (ViewGroup)v;
for (int i = 0; i < viewGroup.getChildCount(); ++i) {
View view = viewGroup.getChildAt(i);
addAccessibilityDelegateToViews(view);
}
}
}
});

Extend EditTextPreference and display the DialogMessage

I have extended EditTextPreference, but the Dialog Message won't display. This happens if I add the dialogMessage programatically or in the the preferences.xml.
Here is my onBindDialogView:
AutoCompleteTextView editText = mEditText;
editText.setText(getText());
ViewParent oldParent = editText.getParent();
if (oldParent != view) {
if (oldParent != null) {
((ViewGroup) oldParent).removeView(editText);
}
onAddEditTextToDialogView(view, editText);
}

Is the dialog message really absent? It's probably there but its text color might make it less (or not) visible. (Or try to dismiss software keyboard). Try experimenting with dialog messages having a number of "\n" characters and see if that affects dialog layout. If so, it means the dialog message is actually there but camouflaged too well.
EditTextPreference brings a text view (in the preference_dialog_edittext.xml) that replaces the existing one (in the alert_dialog.xml) for the dialog message, but unfortunately with different text style, which might cause a visibility problem under certain themes. Even their sizes are different.
One solution might be to obtain the text color and size from the original text view to be replaced and apply them to the new one, but I would suggest retaining the original text view instead, because it's more likely to be visually consistent if there are any future UI changes. Try adding the following overrides
protected void onPrepareDialogBuilder(AlertDialog.Builder builder) {
super.onPrepareDialogBuilder(builder);
builder.setMessage(getDialogMessage()); // bring back the original text view
}
protected void onAddEditTextToDialogView(View dialogView, EditText editText) {
int id = getContext().getResources().getIdentifier("edittext_container", "id", "android");
ViewGroup container = (ViewGroup) dialogView.findViewById(id);
container.removeAllViews(); // remove the new text view
super.onAddEditTextToDialogView(dialogView, editText);
}
If you think the dialog message and the edittext view is too far apart, they can be brought together a little closer by adding another override:
protected void showDialog(Bundle state) {
super.showDialog(state);
int id = getContext().getResources().getIdentifier("message", "id", "android");
TextView message = (TextView) getDialog().findViewById(id);
message.setPadding(message.getPaddingLeft(), message.getPaddingTop(), message.getPaddingRight(), 0);
}
and add the following line in the onAddEditTextToDialogView method after calling removeAllViews:
container.setPadding(container.getPaddingLeft(), 0, container.getPaddingRight(), container.getPaddingBottom());

Catch keyboard 'Done' for NumberPicker

I have an AlertDialog with just some text, a NumberPicker, an OK, and a Cancel.
package org.dyndns.schep.example;
import android.os.Bundler;
import android.view.View;
import android.widget.NumberPicker;
import android.app.Activity;
import android.app.AlertDialog;
import android.app.Dialog;
import android.app.DialogFragment;
import android.content.DialogInterface;
public class FooFragment extends DialogFragment {
#Override
public void onAttach(Activity activity) {
super.onAttach(activity);
mParent = (MainActivity) activity;
}
#Override
public Dialog onCreateDialog(Bundle savedInstanceState) {
AlertDialog.Builder builder = new AlertDialog.Builder(getActivity());
builder.setPositiveButton(android.R.string.ok,
new DialogInterface.OnClickListener() {
#Override
public void onClick(DialogInterface dialog, int id) {
mParent.setFoo(foo());
}
})
.setNegativeButton(android.R.string.cancel, null);
View view = getActivity().getLayoutInflater.inflate(
R.layout.dialog_foo, null);
mPicker = (NumberPicker) view.findViewById(R.id.numberPicker1);
mPicker.setValue(mParent.getFoo());
builder.setView(view);
return builder.create();
}
public int foo() {
return mPicker.getValue();
}
private MainActivity mParent;
private NumberPicker mPicker;
}
(This dialog doesn't yet do the things it should to preserve state on Pause and Resume, I know.)
I would like the "Done" action on the soft keyboard or other IME to dismiss the dialog as though "OK" were pressed, since there's only the one widget to edit.
It looks like the best way to deal with an IME "Done" is usually to setOnEditorActionListener on a TextView. But I don't have any TextView variable, and NumberPicker doesn't obviously expose any TextView, or similar editor callbacks. (Maybe NumberPicker contains a TextView with a constant ID I could search for using findViewById?)
NumberPicker.setOnValueChangedListener does get triggered on the "Done" action, but it also fires when tapping or flicking the list of numbers, which definitely should not dismiss the dialog.
Based on this question, I tried checking out setOnKeyListener, but that interface didn't trigger at all when using the soft keyboard. Not a total surprise, since the KeyEvent documentation suggests it's meant more for hardware events, and in recent APIs the soft keyboard won't send them at all.
How can I connect the IME "Done" to my dialog's "OK" action?
Edit: From the looks of the source, a NumberPicker layout does contain a EditText, but its id is id/numberpicker_input in package com.android.internal. Using that would not be easy, and is obviously discouraged. But it seems like there might only be hack ways to get the behavior I want.

How can I connect the IME "Done" to my dialog's "OK" action?
The problem is that you can't pass the IME's events if you don't have a listener set on the TextView widget which currently works with the IME. One way to do what you want is to hook our own logic to the NumberPicker's child which works with the IME(like you already talked in the last part of your question). To avoid using certain ids or other layout tricks(which can be problematic) to get a hold of that widget, you could use a greedy tactic, setting the listener to any widget from the NumberPicker which could trigger the desired event(TextViews or any subclass of TextView). Something like this:
private AlertDialog mCurrentDialog;
private List<TextView> mTargets = new ArrayList<TextView>();
private OnEditorActionListener mListener = new OnEditorActionListener() {
#Override
public boolean onEditorAction(TextView v, int actionId,
KeyEvent event) {
if (actionId == EditorInfo.IME_ACTION_DONE) {
// if a child of NumberPicker triggers the DONE editor event
// get a reference to the positive button(which you use in your
// code) and click it
mCurrentDialog.getButton(Dialog.BUTTON_POSITIVE).performClick();
}
return false;
}
};
#Override
public Dialog onCreateDialog(Bundle savedInstanceState) {
// ...
mPicker = (NumberPicker) view.findViewById(R.id.numberPicker1);
mPicker.setValue(mParent.getFoo());
// clear any previous targets
mTargets.clear();
// find possible targets in the NumberPicker
findTextViews(mPicker);
// setup those possible targets with our own logic
setupEditorListener();
builder.setView(view);
// get a reference to the current showed dialog
mCurrentDialog = builder.create();
return mCurrentDialog;
}
Where the methods are:
private void findTextViews(ViewGroup parent) {
final int count = parent.getChildCount();
for (int i = 0; i < count; i++) {
final View child = parent.getChildAt(i);
if (child instanceof ViewGroup) {
findTextViews((ViewGroup) child);
} else if (child instanceof TextView) {
mTargets.add((TextView) child);
}
}
}
private void setupEditorListener() {
final int count = mTargets.size();
for (int i = 0; i < count; i++) {
final TextView target = mTargets.get(i);
target.setOnEditorActionListener(mListener);
}
}
The other possible(and reasonable) solution(like Naveen already mentioned in his comment) is to use one of the ports of the NumberPicker class(or modify the one from the SDK) out there and insert your own widget ids(which will make getting a reference to the widget a simple task). This would be easier to implement now but inconvenient to maintain on the long run.

My search and experimentation has also turned out empty handed. That said I wouldn't encourage this kind of behavior as it doesn't make much sense.
If you need a NumberPicker it is because you want the feature of scrolling to the value that you need, not entering it (though it is possible). If you want to enter the value you'd use an EditText and you would be able to implement what you need without problems.
Alternatively you have to copy NumberPicker implementation from the source and then change it according to your needs (fx by adding ime options).

Getting list of all Windows in Android

Is it possible to get a list of all Windows in my Android app?
If not, is it possible to get notifications on creation of a new View or a Window?
Cheers :)
For example: I would like to know if there's a visible keyboard view on the screen, or if there's an alert dialog on screen. Is that possible? Can I get the View or Window instance holding it?

Yes this is possible in a number of different ways. All views being displayed on the screen are added to a ViewGroup, which are usually layouts such as R.layout.main, LinearLayout, RelativeLayout, etc.
You can access the views at runtime, after the layouts have been built, using a handler such as onWindowFocusChanged:
#Override
public void onWindowFocusChanged(boolean hasFocus) {
int count = myLayout.getChildCount();
for(int i = 0; i < count; i++)
{
View v = myLayout.getChildAt(i);
...
}
}
You can simply set up a thread inside onWindowFocusChanged that would notify you if a keyboard is created by constantly checking the number of children views of the current layout.

For the keyboard issue, you can use your own keyboard view instance with KeyboardView in your layout: http://developer.android.com/reference/android/inputmethodservice/KeyboardView.html
Use the same principle for the other views you want to handle: manage them yourself in your layout. I don't know if you can in the software you plan to do but this is a way which can work.

You can only get views which are managed by your application.
This includes all views except the status and navigation bars(for higher than HoneyComb). If you choose to have your own InputMethod, that view can be yours as well but you'll need to register the proper keyboard views. See this question for more on that.
Otherwise, if you want to get all the views in your window:
ViewGroup decor = (ViewGroup)activity.getWindow().getDecorView();
int count = decor.getChildCount();
for(int i = 0; i < count; i++) {
View view = decor.getChildAt(i); //voila
}

hey use this code this will help you to find if any dialog is created in your activity
class MyActivity extends Activity {
#Override
public void onAttachedToWindow() {
super.onAttachedToWindow();
Log.d("TAG", "New Window ATTACHED");
}
}
onAttachedToWindow will be called every time user creates new dialog or something