Can components be interacted with when their visibility is set to GONE? - android

I could not find anything that straight out answers this question. If I set the component (such as a Button, ListView, EditText) in the xml with a visibility of GONE, am I still able to interact with those components even though they are invisible? I tested it out with a Button and it seems to be no but I want to make sure.

When the visibility is set to GONE, the component is removed from the view hierarchy and no space is set aside for it. Moreover, there is no way for the user to interact with it (However, changes made to the View by the programmer while it is GONE become manifest when the visibility is changed to VISIBLE).
When the visibility is set to INVISIBLE, the component is still actually present in the view hierarchy, and space is calculated for it.

Related

Activity performance with conditional visibility gone/visible

I have a fragment that contains a LinearLayout that is conditionnaly displayed or not. In terms of performance what is the best? Mark the LinearLayout as android:visibility="gone" in the XML, and then in code I set its visibility if needed, or the opposite?
Inflating a layout with some views with a visibility set to GONE is bad for performances, especially if the view is a bit complex.
check url :http://magicmicky.github.io/android_development/benchmark-using-traceview/
Unless that layout is very complex and has too many views, I wouldn't worry about it, it won't matter very much.
But it does seem more logical to initially set it to be gone unless you decide that it should be visible afterwards.
You could also think of it from a UX point of view, should the user see it very briefly then it disappears? or should it work the other way around?
I think there is nothing much with the performance in these two implementation unless you are hiding the layout after a long running network calls or something like this which requires some time to make the decision of hiding and showing the layout or the layout is too complex.
However, I would suggest you to keep the following things in mind.
In case of orientation changes of your activity, you need to handle the layout visibility in your onCreate or onResume function as the activity gets recreated. If you are hiding the layout and not keeping a track of it in a global static variable, the decision might get lost and you might get inconsistency in your overall layout design. However, if you are hiding your LinearLayout based on a decision which is being made in your onCreate function, you will not face this exact situation.
If this LinearLayout is inside an item of your RecyclerView or ListView, think of handling each of your layouts items carefully.

Android: Invisible objects still clickable

I have an activity that has buttons and images that can appear and disappear depending on user interactions.
What I am finding is that objects at the back, which have been set to invisible, are still triggering clicks, sort of. They are not processing the code related to being clicked, but they sort of momentarily reappear, and then disappear again instantly when clicked on.
They also appear to be interfering somewhat with buttons laid over the top of them. These buttons become very fiddly and difficult to click at times, when there is an invisible object behind them.
I am using simply:
object.setVisibility(View.VISIBLE);
And:
object.setVisibility(View.INVISIBLE);
To make my items appear and disappear. Is this not what I should be doing?
EDIT:
People keep asking me for the exact same code that they are giving me. This is the code I have been given, and that I am using currently.
btnLifePlus5.setVisibility(View.GONE);
btnLifePlus5.setFocusableInTouchMode(false);
txtLifePlus5.setVisibility(View.GONE);
txtLifePlus5.setFocusableInTouchMode(false);
btnLifePlus1.setVisibility(View.GONE);
btnLifePlus1.setFocusableInTouchMode(false);
txtLifePlus1.setVisibility(View.GONE);
txtLifePlus1.setFocusableInTouchMode(false);
btnLifeMinus5.setVisibility(View.GONE);
btnLifeMinus5.setFocusableInTouchMode(false);
txtLifeMinus5.setVisibility(View.GONE);
txtLifeMinus5.setFocusableInTouchMode(false);
btnLifeMinus1.setVisibility(View.GONE);
btnLifeMinus1.setFocusableInTouchMode(false);
txtLifeMinus1.setVisibility(View.GONE);
txtLifeMinus1.setFocusableInTouchMode(false);
This makes no difference to just setting them as invisible.
Making any View invisible don't prevent us to trigger their listeners. It's just you can not see it every other thing would be same as if it was visible.
If you don't want to use it at all change it to View.GONE
Difference in View.INVISIBLE and View.GONE: Invisible objects keep on utilizing the space assigned to it while object set as View.GONE would leave the space of space as if its not on screen.
Use
object.setVisibility(View.GONE);
rather than
object.setVisibility(View.INVISIBLE);
Use object.setVisibility(View.GONE); instead object.setVisibility(View.INVISIBLE);
View.GONE Means This view is invisible, and it doesn't take any space for layout purposes.
View.GONE This view is invisible, and it doesn't take any space for
layout purposes.
View.INVISIBLE This view is invisible, but it still takes up space for
layout purposes.
I hope it will helps you .
Try:
object.setClickable(false);
As an alternative, you can:
object.setEnabled(false);
The only way I managed to solve this ridiculous issue was to create a sort of view panel that sits between the objects in my activity. This view panel is the size of the screen, uses the same colour background, and starts invisible.
Normally, I make object A disappear, and make object B appear. When I click the space previously occupied by object A, it momentarily flashes back onto the screen and then disappears again. It looks terrible. Subsequent clicks do not reproduce this bug until the next time I make object A disappear.
The fix is to make object A disappear, make the new view panel visible on top of it, and then make object B appear on top of the view panel. So the panel acts as a sort of barrier between the hidden object, and user interactions. The user is not aware that this view panel even exists, as it blends in to the standard background, but when I now click the space where object A would be, it now no longer flashes back onto the screen momentarily. While this is a poor solution to have to use, this OS is bugged and I am left with no choice.
My activity now looks as though it is perfectly stable and working perfectly. I don't like it, but it works.
Thanks a lot, google.
Try object.setVisibility(View.GONE)
View.GONE prevents view to draw its layout bounds (width and height) whereas View.INVISIBLE draws it.
You should use:
object.setVisibility(View.GONE);
View.GONE removes your view completely from the layout, but View.INVISIBLE only makes your view invisible but still found in your layout, thus clickable.
In my case, I was animating a layout and then set it hidden.
However, I was using View.GONE but still, the layout views were taking clicks.
Then I found that in the animation I was using anim.setFillAfter = true
changing it to "False" fixed the clicks issue for me.
Hope it helps someone banging their head.

Setting the visibility for a linear layout(view group)

When I set setVisibility(View.GONE) or setVisibility(View.VISIBLE) for a linear layout it seems that it does not changes the visibility of the view(saying view group would be more accurate). At various post in SO, it has been suggested that get the count for the particular linear layout and change the visibility of each child one by one. Well that can work but it also increases the time taken to process that piece of code. And when there are various view involve, it will be increase to many folds. Same goes for setEnabled(true) or setEnabled(false).
My question is there a alternative for this, as directly changing the visibility is definitely not working? And if not can anybody explain to me why android choose to keep it this way, i.e developer cannot directly change the state(visibility/enabling) of the view group.

Difference between foo.setVisibility(View.GONE) and parent.removeView(foo)

If foo is a view, what is the difference between foo.setVisibility(View.GONE) and fooParent.removeView(foo)? I am particularly interested in memory consumption of the view, before and after both statements.
Does a view with visibility set to GONE consume memory ?
If you need to remove them and then show them again, it could be better to just set visibility to gone and then change back to visible again.
If you on the other hand don't need them visible again, simply remove them.
suppose,
if you need to delete all the available option of flying once you
select a particular flight. then go with fooParent.removeView(foo).
or,
if you need to selection of a particular flight all the flying options
are disappeared, and deselection of flying option again show all the
available options then go with foo.setVisibility(View.GONE) and
foo.setVisibility(View.VISIBLE)
setVisibility(View.VISIBLE) = setVisibility(0)
setVisibility(View.GONE) = setVisibility(8)
setVisibility(View.INVISIBLE ) = setVisibility(4)
I know this question is too old, but after what I have encountered in my recent projects, I want to give an idea of how View.GONE works, and how it can come in handy for some runtime view position manipulations.
Suppose you have added two child views inside a RelativeLayout, cv1 and cv2, and that cv2 is relatively below cv1(using layout_below). Then if you plan to set visibility of cv1 to GONE in runtime, then it won't cause any runtime error.
That's amazing to see because cv2 was relative to cv1, and now cv1's visibility is GONE.
So what happens actually with visibility GONE is that,
view's height and width becomes zero, but, view stays in the parent,
like a tiny dot or point.
So, even if any view is placed relative to it, it will be like, that view will occupy its place(here cv2 will occupy place of cv1 in runtime). Later on, if cv2's visibility is turned back to VISIBLE, than, cv1 will now occupy its actual position, with cv2 below it.
This link describes my usecase.
This approach of showing and hiding view comes in handy, when you don't want to handle the hassle of manipulating the LayoutParams of a view in runtime, when your usecase is this simple.
On the other hand, parent.addView() / parent.removeView() approach is opted when your view hierarchy is complex, and you want to manipulate margins, paddings, and relative positions of the views drastically during runtime.

Android LinearLayout Visibility issues with Animation

I am trying to swap two LinearLayouts by setting their visibility properties to "VISIBLE" and "GONE" respectively. I am also using an animation while the layouts are being swapped. The animation completes successfully and I see the correct layout. However, the previous Layout which has its visibility property set to "GONE" still receives clicks even though it's not visible. At the same time, the layout which is "VISIBLE" receives clicks only when clicked in area where the "GONE" layout isn't clickable. I am also calling the requestFocus method on the "VISIBLE" layout. But it doesn't help.
Moreover, if I skip the animation part and just set the visibility properties, everything works correctly.
What am I missing here?
If you are animating widgets, you need to make changes to the layout to have the results "stick". Just using the fillAfter stuff will give you some of the effects you see -- it is drawing them in the new location but they aren't really in the new location.
So, I would start by turning off any fill* settings (e.g., fillAfter) in your animation. See what your animation behaves like then. Most likely, it visually will now depict what the clicks tell you.
Then, set up an AnimationListener to get control when the animation ends, and at that point, make real changes to the widgets and their containers to affect your end positions.
Here is a sample project that demonstrates what I mean, albeit in an overly complicated fashion, since I am animating a custom View rather than an off-the-shelf widget.

Categories

Resources