I'm currently learning Android development from a book and I've come to the topic of radio buttons. The book explains that you handle radio button clicks (within a RadioGroup) using setOnCheckedChangeListener() with an anonymous OnCheckedChangeListener class as an argument.
However, according to the Android documentation you can set the onClick attribute on radio buttons to simply refer to a method of your design and handle clicks there.
Is there a reason to choose one over the other? What I'm asking is if there is some difference between the two that I'm missing, or if they simply both do the same thing.
setOnCheckedChangeListener() is listening to checked state, so if it is changed programmatically your code will be triggered. onClick listener only detects changes on checked state only if the element is clicked.
Related
Is there a possibility using Java Swing to add in a existing running Swing application a button as an example. The action of the button to have a call to an existing method in that application. Maybe using xml to define the structure of the button.
You can do it. When any action triggered you can create the button and set the listener for it.
But best practice is to create the button and listener at the build time. Here you need to hide/set visibility to false initially and when any action triggered, set the visibility to true.
I work with TextToSpeech and adding "android:contentDescription="#string/custom_button" for ImageButton in xml, reads the value from "#string/custom_button" and adds another "button" in speech.
EG:
"#string/custom_button" = "Custom Button" mapped for mentiond ImageButton, is read as "Custom Button button". There is no text in this button. Id is much different.
How to get rid ot this last "button". It refers to all views read by TextToSpeech.
From my work/research with accessibility, Android automatically adds "button' to the end of talk back for buttons. I could not find any documentation breaking now accessibility to the coding level, but from what i gather they probably add this in the case the developer forgets to indicate in the content description that the the user has clicked a button. There is nothing you can do to remove android's addition of the word button. What you can do is remove it from you custom description so that is only says "Custom". Hope this helps.
Hello I'm creating an android application that uses checkbox's, i'm wondering if it is better to use an OnCheckedChangeListener to do something when the state of the checkbox is changed or if it would be better to use an OnClickListener with an if statement inside it that is executed everytime the checkbox is checked or unchecked? Thanks
With OnCheckedChangeListener you receive an event whenever the checked status changes, even when done in code by using .setChecked().
Depending on what you are doing this can lead to unexpected behavior (for example when you have a checkbox in a listview, the view is recycled and the checkbox state is modified programmatically, it looks exactly the same way as if the user had clicked it).
Therefore, when you are writing code that is supposed to react to a user who clicked the checkbox you should use OnClickListener.
My overriding question is this: In Android PreferenceActivity, how can I write an OnClickListener which will have the same functionality as pressing the Android back button as I navigate through PreferenceScreen defined menus? That is to say, I would like users of my App to explicity see a menu choice "Back" which will bring them to the previous menu, or bring them out of the menu activity to their previous activity if they are at the root of this particular PreferenceActivity session.
The android developer documents tell us
Note that this XML resource contains a preference screen holding another fragment, the Prefs1FragmentInner implemented here. This allows the user to traverse down a hierarchy of preferences; pressing back will pop each fragment off the stack to return to the previous preferences.
And they are correct about that. I navigate happily through my menus by clicking on PreferenceScreen items to get to that screen, and using the Android back button to go Back up a level. But I'm not sure a casual user really understands the "Back" button, I know I didn't until I read about it in Developer docs. SO I would would like them to have an explicit Preference defined menu choice whos OnClickListener duplicates the function of the Android back button.
So I tried to put in a Preference in my menu that would go back. Having determined that a not Overriden onBackPressed in a my subclass of PreferenceActivity just referred back to Activity.onBackPressed() which merely calls finish(), I tried this OnClickListener:
private OnPreferenceClickListener clickFinishesSuccessfully = new OnPreferenceClickListener() {
#Override
public boolean onPreferenceClick(Preference preference) {
finish();
return true;
}
};
As it turns out, this did NOT do the same thing as pressing the back button! Pressing this button always took me out of the PreferenceActivity entirely, back to the Activity from which I had called my PreferenceActivity. Specifically, it did NOT navigate back through my menus no matter how deep I was when I clicked it.
I am guessing here: When I have gotten to a submenu by clicking an onscreen preference which is really a PreferenceScreen, I am no longer in my own PreferenceActivity. I must be in some other Activity?
So my functional question: what can I put in my OnClickListener of my "Back" Preference to get the same function as the Android Back button navigating through my menus?
I think the casual user should know about the back button. The button is used everywhere so it might be a problem getting used in the first day but after that it's natural. Without being used to the "back" button I can hardly imagine doing the everyday tasks.
The preference you want to add just duplicates functionality and doesn't provide a consistent way with the rest of the system. If Google was considering back being an uncommon thing for casual users would have added that option in phone's Settings which is also a PreferenceActivity.
I have searched and searched Google, Stack Overflow, etc. for an answer to this and failed!
I wish to programatically disable/enable selected radio buttons in a single Android preference.
For example, there is a radio button preference with 6 choices, but depending on some condtions (not related to the preferences) some of them will be unselectable and should be shown as disabled.
I can see how we can disable complete radio button groups, but not individual radio buttons
Can Anyone help?
AFAIK, this is not supported by the built-in ListPreference. You are welcome to write your own custom Preference, or perhaps extend ListPreference, where you supply your own Adapter and disable certain items that way.