I've been changing over some app menu options lately in order to simplify the graphics and give me more space to work with. I added a radio button, and have it set up to toggle on and off when pressed via a listener:
View.OnClickListener toggleListener = view -> {
Settings.getSetting().toggleSetting();
holder.settingToggleButton.setChecked(!holder.settingToggleButton.isChecked());
};
...
holder.settingToggleButton.setOnClickListener(toggleListener);
But when I load into my app and toggle the button, it'll work initially (options that are on get toggled off, and vice versa) but when I then try to tap it again and toggle the option back on/off, it doesn't work. It sticks either on or off, whichever state it was initially toggled into when I first pressed it. I'm not sure why this is happening, as the logic is very straight-forward... any ideas as to why this set up isn't working?
holder.settingToggleButton.setChecked(!holder.settingToggleButton.isChecked());
The logic here is correct, as #Ansh suggested, I would say the problem is the UI never receives the setChecked attribute and what you're seeing is the default behavior of a radiobutton, which takes the initial input but isn't toggleable without logic code.
If you think that's not the case, try putting down a Button that updates the toggle state of a specific radiobutton. This'll help you see what you're doing wrong.
I have discovered the answer to my question; it's a niche solution related directly to my problem, but overall, it was indeed related to not checking for/modifying the ID of the toggle button. If you're ever having issues with the button toggling one way but not the other, or not toggling at all, make sure all references to that button, and all the changes it's involved in, take it into account.
Related
I made an App with several Toggle Buttons among other constrols. In certain circumstances some of those Toggle Buttons are set checked and unchecked not phisically by the user, but programmatically.
The tests in the Android Virtual Machine shows a normal behaviour of these controls, when I check and uncheck the Toggle Buttons both phisically and programmatically.
But my surprise comes when I run the App in a real Android machine:
When unchecking any Toggle Button programmatically (no matter if I use the setChecked(false) or the toggle() functions), the Toggle Button indeed goes to the OFF state but with a yellow light/dash instead of an empty gray dash as it would be normal to infer... (Of course, when unchecking the button phisically, the problem doesn't exist)
No matter if I use:
toggleb.setChecked(false);
or...
toggleb.toggle();
Approximated Image:
I suspect that it is related to the Android version of the real device that is more advanced than the Android Virual Machine...
So, I would like to know how to turn off any dash/light of the Toggle Button programmatically when setting it up to the OFF state.
I search all over the web for that circumstance, but, incredibly, I found no mention of it...
Thank you very much in advance...
I have to add an update:
The problem appears under specific and complex conditions and only in some Android devices, as if it were a kind of unwanted side effect. This is why this problem is so strange and does not appear in eclipse's Virtual machine (API 10: Android 2.3.3) and appears in my LG G3. I have to clarify it after several tests I made because I was not aware of it.
The App where I found the problem has a large and complex code where the ToggleButtons are not activated directly by the usual OnClick method, but by an OnTouch method whose Listener is linked to a ImageView (with a View it is the same) element that covers the whole Android device screen area.
So, this virtual element cover all buttons and controls of the App. Activating the buttons is made by registering the touch coordinantes by the OnTouch method and checking if that coordinates match the area of some of the ToggleButtons.
If the coordinates match the area of one given ToggleButton and is not checked (turned off), then that ToggleButton is checked (turned on).
On the contrary, If the coordinates match the area of one given ToggleButton and is checked (turned on), then that ToggleButton is unchecked (turned off).
With some conditions, unchecking one ToggleButton, will uncheck others. This is the point where the problem appears: when unchecking the others, the yellow dash appears only in these others.
If I put some of these other ToggleButtons over the virtual screen (or transparent ImageView element), incredibly, the problem disappear for those ones, but the onTouch fucntion does not work for direct touch for those ones, so this could not be a solution for me.
I have to report all of this.
Sorry, I still can't put code because it is very large and complex.
Thank you in advance.
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.
I have created a custom class which extends ToggleButton and I override the toggle method and do not do anything in that. This has helped me in having control of switching togglebutton from on to off. Is this proper way of doing?
I wanted to have the control of togglebutton switching. I mean it should go from on to off based on certain conditions otherwise it should remain in the state it was.
This way its working but want to know whether its the correct way of doing or not.
What you are looking for is ToggleButton.setChecked.
I'm looking for suggestions on how to go about adding a ListView selector that is 'permanent'. By this, I mean a single row in the ListView is always highlighted; it should move up or down in reponse to any D-pad presses (i.e. like the default selector) but also remain set/highlighted if the user were to scroll the ListView in either direction (i.e. it's still highlighted even when it's off-screen).
I've looked at using the standard selector mechanism, but am unable to get the selector to remain in place if the ListView is touched (and thus scrolled), so it makes me think that this isn't the best option? Perhaps there's a <selector> "state_*" that I've ignored?
The other option would be to use the onItemSelected() callback, but at first look this appears more convoluted?
Any suggestions/recommendations/experiences gratefully receieved.
Cheers
James
I'm looking for suggestions on how to go about adding a ListView selector that is 'permanent'.
Please do not do this. There is no selection in touch mode, and that is by design. As suggested in this article, "Use the appropriate feature if you need persistent selection (radio button, check box, the ListView choice mode, etc.). Do not try to keep the focus or selection in touch mode."
I have a clickable TextView with a drawable as its background. I'm looking for the right way to implement a down-state drawable so the background changes when the user presses down. I have been able to almost perfectly replicate this behavior by listening for MotionEvents and changing the background when the user is pressing down.. The only thing that doesn't match up with system-wide down state behavior here is that if the user keeps holding down and moves their finger off the button, the state remains down until they release their finger from the screen... whereas in Maps overlays or Buttons or ListViews or anything else the state immediately goes back to off when the finger moves from the object.
I know there must be some proper way to go about doing this... A nudge in the right direction would be great!
Thanks,
Nick
You need to use a Selector for the background. I'm not sure if there is an official example of how to use Selectors, but I found this site that seems to have a pretty good example:
http://www.craiget.com/2009/03/restyling-android-imagebuttons/
That should get you on the right track.
Edit: Apparently that first link is down, until/unless it comes back here is another example: http://www.mkyong.com/android/android-imagebutton-selector-example/