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.
Related
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.
This is an odd problem that took me quite awhile to reproduce reliably.
I have a menu activity that is very simple; just some buttons defined in xml.
I have an activity with a layout with a GLSurfaceView and some buttons defined in xml.
These buttons have onClick attributes defined. This activity is accessed from the menu activity.
In the OpenGL activity there are the associated onClick functions "onFoo(View view)".
When I navigate back to the menu activity using the native Back button nothing interesting happens; however, when I click ANY of the xml defined buttons with an onClick attribute and then navigate back some of the ImageViews on the menu activity appear as black but otherwise in their correct locations, sizes, etc. Their xml defined onClick functions work correctly as well.
I am having all of the images on the menu activity re-exported (to eliminate any export setting flaws since the assets were originally exported at various times), but while I wait for that to happen I figured maybe someone out there has run into this problem before.
For the purpose of limiting variables in this problem I even commented out the function's contents in the OpenGL activity to make sure nothing in the onClick functions was causing a conflict.
e.g.
public void onMainMenu (View view)
{
}
So, to clarify, if I click a button defined in xml with an onClick attribute e.g.
android:onClick="onMainMenu" with the above empty method, then press the native back button the issue occurs, but not when skipping the clicking of the onMainMenu button.
I can't be sure if it is always the same set of ImageViews that turn black, but one ImageView does seem to consistently survive with the correct Drawable; this is odd because the ImageViews are defined identically other than their src attribute. They are all relatively the same size and not large at all.
I originally thought it had something to do with the EGL context (Android displays black rectangles instead of drawable images after opening openGL context) (and it still may be the case), but then I discovered how to reproduce it 100% of the time by pressing a button with an onClick attribute before navigating backwards. Memory usage is in control and I am lost for a possible solution or trail to one.
I can reproduce this on the three devices I have: an HTC One, Droid Bionic, Galaxy Tab 2 7.
The Application is minSdk:14, target:17. Hardware acceleration is on.
I tried playing with hardware acceleration settings with the following results:
If I turn off hardware acceleration for the application, and add it to just the OpenGl activity the main menu issue does not appear, but the same issue starts occurring in the OpenGL activity. In the case of this activity some ImageView's drawable resources are switched out at run-time. The switched in resources display correctly, but when switched back to the same resource that the was defined for that ImageView in xml it renders black.
To clarify the switching: in one such case I have views with a drawable-state-selector for their backgrounds. When switching between the two states (they function like tabs i.e. their default states as defined in xml are opposite) the default state always displays as black but the secondary state displays correctly.
If I turn off hardware acceleration for the application AND the OpenGL activity, the problem appears to go away completely.
I worry about using that as a solution though as I can't be sure of any performance problems that may occur on devices I do not have to test with.
Removing hardware acceleration from the OpenGL activity breaks a view that overlays the GLSurfaceView on at least the Droid Bionic, so I'd rather not use this pseudo-solution.
This is the first time I have posted a question on Stack Overflow. I always find a solid lead searching, but just could not find a solution or even a problem with similar circumstances in this case.
Thanks for any help and wisdom the community can provide!
The problem came down to a call to GLES20.glDeleteTextures(int size, int[] textureNames, int offset). I was calling this during onPause() which was somehow causing a conflict. I am not sure how it was related to touching a UI item outside of the GLSurfaceView. Removing the one call somehow prevents the issue.
I have designed a menu that consists of a few buttons in several different LinearLayouts all placed over an animated GLSurfaceView within a FrameLayout. When the user clicks a button in the interface, I set the current layout's visibility to GONE before making the next layout VISIBLE When the user selects a level, then game play starts and all layouts are GONE (apart from a control bar on the right of the screen, but that is not contained inside the FrameLayout)
On most phones the menu works like a charm, but I did a quick test on an Xperia Ray only to find that I couldn't go anywhere because the buttons wouldn't click. I have Log.d tags set up in most of my onClick Listeners, and in this case they aren't showing in the Logcat so it doesn't seem like the Listeners are firing at all. I also noticed that the GLSurfaceView wasn't returning anything from it's own TouchEventListener. Even though the functions triggered by tapping the GLSurfaceView are disabled while on the top menu, I normally still get a message in the Logcat.
I thought it could be something to do with the way I have used the FrameLayout. The documentation says it should only have one child, but another article I read on android developers demonstrated captioning images by displaying text over ImageViews inside a FrameLayout.
On a final note, I'll also say that I've tested in the emulators and I found that both android v2.3 and android v4 display the same behaviour as the ray. Currently those are the only ones I am sure of, aside from android v2.2 which runs my app perfectly. I am hesitant to trust the results of testing on the emulators.
I am personally stumped seeing as there is no error message to go on, but can anybody suggest a solution?
I found the solution.
Turns out that I had a stray ScrollView hanging around in my layout that was both above my root layout in z-order and visible by default. Instead of toggling the visibility of this view, I was doing so for it's child layout. Oops.
On most devices I have tested on, the stray ScrollView has not effected the functionality of my app, probably because the empty layout was allowing buttons behind it to be clicked. However it turns out that some devices, such as the Xperia Ray, are a little more strict on whether clicks can be passed down through layouts (possibly a performance decision).
The ScrollView was a required part of the layout so I couldn't just remove it. Instead I gave the the android:visibilty attribute to the ScrollView so that it would be GONE until it is needed by the interface and it won't block the user from clicking buttons.
I made one simple android application and I notice next problem:
I have several controls with attached click (or i say touch) event (buttons, imageviews). Some of them are loaded from android xml file, and some I make "in fly".
Now when I scroll screen, I must 2 time click on button to make effect (click event). It seems to me that this have some connection with losing focus.
Am I right and how to solve it? I want just one click to execute some operation.
This happen only on real device (HTC Wildfire). In emulator there is no this problem.
Thanks!
Do you, by any chance, have
android:focusableInTouchMode="true"
for the Button? Because this will cause the button to need one touch to gain focus and another one to fire the click.
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.