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.
Related
Whenever a new view is added or removed, everything is adjusted. I can see how in majority of use-cases this is a very good thing, but unfortunately for me, it's something I need to avoid. I'm assuming that onMeasure() is called whenever a view is removed or added, resulting in it changing the X and Y coordinates I gave it, however I want to "disable" this.
My app utilizes dynamically moving and resizing views, determined by the user at runtime, hence if whenever the user removes a view or adds a new one, it shifts everything around, it'd be extremely annoying. Also I'd think that (although not sure) that preventing this could only help performance right? Not measuring each view, in fact, I do not want it to measure it at all because, once again, the user decides the view size and location, not the linear layout.
I was thinking of creating my own ViewGroup, but I've never done this before. I know you can extend a pre-existing one, like LinearLayout or RelativeLayout, but I need help determining which one I should use, and whether or not I should just create a full on ViewGroup.
As I said, it doesn't need to measure the views at all, and in fact, if it were possible, a container that does nothing would be optimal, and I'd think would yield more performance. Can anyone help me with this problem?
Summary:
Need a way to either prevent a pre-existing ViewGroup, I.E FrameLayout, RelativeLayout and LinearLayout, that do not adjust the position nor size of the view, or create a new ViewGroup which doesn't do any measuring at all because the user defines the location and size at runtime and should not be altered by the container.
If this is a bad question or another question exists that answers this, please let me know.
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.
I've been using some progressbars in my android app (Lazy loading GridViews). So when each item is loaded I set the progressbar to become INVISIBLE. I know that
INVISIBLE : This view is invisible, but it still takes up space for layout purposes.
GONE: This view is invisible, and it doesn't take any space for layout purposes.
My doubt is when I set the progressbar to INVISIBLE does it mean that the resources needed by that View are still being used in the background? (Example the progressbar animation). If I set it to GONE will there be any change in performance (I know it might be negligible). I'm curious to know it's implications on performance. Thanks.
The performance difference would likely vary on what the view's contents and complexity are, and if there are nested views within it. While the layout information still has to be inflated into memory for the entire layout, the view measurements would not have to be calculated for a view that is GONE or its children, and it would not be drawn, whereas INVISIBLE only removes the rendering of the view (and its children) while still calculating the view measurements and its children.
If you don't want the view to appear again in the current lifetime of the activity or fragment, you can use parent.removeView(progressView) to remove it entirely for the best performance and memory optimization.
In your case it may not help much, but if you're going for bleeding edge optimization then I would take the approach to remove the view once it's done.
In my app, for instance, when a user creates a new post, he or she can select a type of media (photo, video, text, place, etc.) and then review it in the following activity.
The way I have been doing it is to have all of the views (i.e. ImageView, VideoView, WebView, etc.) there, but set their visibility to invisible, unless the user chooses that type of media.
For instance, all of the views are invisible until the user takes a photo and then only the ImageView is visible. This seems wasteful though. Before I start the activity, I know which type of media the user chooses, but still have the invisible, unused views.
Would it be smarter to have separate layouts for each type of media with the repeated elements (the create post button, the privacy and venue buttons, etc.)? But this would violate the DRY principle...
How costly are invisible views? What is the correct way of doing this?
Depends on the complexity of the Layouts, I had this issue in previous app, in first iteration I did like you, but in 2nd iteration I found its hard to optimise single layout with bunch of invisible views; much less the if else cases to toggle views visibility.
and about layout performance, also it depends on layout/design complexity, I don't think unused view will consume that much of memory or cpu.
so if your layout is simple, its okay for now, if not I recommend to use separate layout for each design/type.
and as #ashishduh said, the best is to set visibility to GONE instead of INVISIBLE, since the parent layout will not measure GONE views, but this doesn't prevent view usage of memory or cpu (mostly in custom views)
I'm using Eclipse graphical layout, and i want to Drag and Drop components to the layout and i want them to stay at the exact position that i dragged them.
Relative Layout is the closet thing but it changes the location of the components after couple insertion.
thanks.
Rami.
i want them to stay at the exact position that i dragged them.
No, you don't. Android devices come with screens in many different sized and resolutions, so fixed positioning of components is a recipe for making the application unusable to users with a different screen that you.
The point of layouts is that they can adjust to different screen sizes. Learn to use them properly.
You're looking for AbsoluteLayout, but it is deprecated.
RelativeLayout is the way to go, just pay some attention to the hints drawed on-screen when you place your elements.
You should be careful also to avoid circular references otherwise your items will be scattered randomly over the layout. (Example: Textview A on right of TextView B; TextView B on left of TextView A)
Be careful also when you change your element's id because the IDE does not update automatically all the references and thus your layout gets scattered again. When you update an ID you must update all its references in the XML file by hand.
Actually absolute layout is the answer what u want ,but that is deprecated.Relative layout does what you want.But it arrange its child based on parent position.If you drag a text view ,then other view will depend on this text view.If you have inserted 2 view,then third view will depend on the parent(2 views).But in between if u disturb any of the view ,it may affect other views.So do things systematically
In Java what we can typically use is GroupLayout. You may see what the equivalent is for android.