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.
Related
Do we get any benefits of implementing a ListView for which every item would have different layout? Would it be a better idea to put those items into ScrollView with LinearLayout instead?
Intuitively, it seems like using a ListView may still give better performance, though it might be negligible depending on the size of your content. Because the ListView inflates the views as it needs them, it seems like you might save some time by not parsing/rendering views that a user might never see. A long ScrollView with a bunch of views inside seems like it would take additional time when first launched, since the view hierarchy is more complex.
I do think Michael is mostly correct though, that the main advantage of a ListView is that views are reused, which saves on memory/processing. Unless you have a ton of content in the ScrollView, I suspect the performance difference is not significant, and will almost definitely be more complex -- in particular, having to create an adapter that knows how to create each view type for each row.
I don't understand why you may use ListView for this. Listview is a list of common data using the same layout if you click on it. Users depend on same/similar GUI patterns.
How about Sliding Tabs or the newer navigation drawer, link NavigationDrawer.
If you like sliding tabs, then I can give you more details.
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 have an activity with more then 200 diffident views and layouts. Some of the views are images and some are texts or buttons. The visibility of the views changes from time to time, and so some of the textView contents, but nothing more.
The problem is with devices with big screens when the activity is out of focus and gets deleted from the stuck (see here under "Saving activity state" section). Unfortunately, to restore it with onRestoreInstanceState() , is a real mess.
I was wondering maybe I should not use Views but implement it in a different way in order to save memory?
Maybe just bitmap images on a Canvas or something else?
Any suggestion tricks, tips will be appreciated.
I suggest you to use Fragments, if you have a lot of views and layouts in one activity.
you can use any number of views as layout, you saying that it will change depends on time,
use setVisibility(View.Visible)
setVisibility(View.GONE)
setVisibility(View.INVISIBLE)
I would like to know how to go about doing this small problem that I am encountering while making a video player app.
On clicking the first control(the rectangular icon) in the above image the following view must be displayed instead of it which I am quite unsure as to how to do it. Here is what it is replaced by
Also please note, by any chance the activity should not be changed. I have been able to design the views individually but having problem changing them at runtime when user clicks. Could someone go about explaining as to how it can be done or provide some suitable links to achieve my goal. Thanks.
For something as simple as this you can just change the visibility of the views.
view.setVisibility(View.INVISIBLE)
Or the more effective:
view.setVisibility(View.GONE)
Do that on the views you want gone, I suggest a wrapper class. It's either this or changing the contentView as describded below.
this.setContentView(R.layout.newLayoutToUse);
However, I have a feeling there is a better way to do what you want. It's overkill to load a complete new layout if you just want to change the image of some buttons or imageviews.
This might be a stupid solution, 'cause i'm terribly tired right now, but why not use the bringToFront() method on the View that you want to display in the front? Display them both in front of each other, maybe in a RelativeLayout, and then swap between them as you wish.
They are small objects, so don't consume memory. I don't see why this shouldn't work.
OR
Place them above one another, so they overlap and then make the above view visible/invisible depending on which one you need to display.
OR
just remembered I read somewhere that you can scroll through a ScrollView automatically from code. So display both Views in a ScrollView in succession and when pressing the button or whatever, you scroll down to make the next menu visible. When pres back, you scroll up to make the previous thing available. Should work, and might also make a nice animation between changing of the menus.
I have implemented a ViewPager in my app, and aside from the swipe paging, I have buttons for "Next" and "Back", with a simple onClick method with the only line being a setCurrentItem for the ViewPager.
While the paging animation is completely smooth during swiping, it is more or less instantaneous (just flips instead of scrolling) when I click Next or Back. There is no visible "scrolling" motion, or sometimes barely visible, however not even close to smooth. It does not hurt the usability of the app in any way, since the transition still happens immediately, but visually it looks a lot less appealing, and the user experience suffers.
Now, I suspect it has something to do with the app drawing the next View and therefore "skipping" the animation. My instantiateItem uses LayoutInflater and a simple switch statement to inflate each view (4 pages at most), and I am loading custom ListViews inside each case in the switch statement. The custom ListViews are at most 3 items long, with a TextView and an ImageView in each row (ImageView resource is 5kb in size). To me it seems this amount of objects should not be reason enough to slow down the paging animation.
Aside from that, I also have a custom background assigned to my app in styles.xml, and this is the background used through every activity (160kb in size).
Those are the only things that I think could be slowing down the app, since the onClick method contains only one line (setCurrentItem), so nothing aside from going to the next view is happening in the app, and the instantiateItem is the simplest implementation of the method possible that I know of.
Things I've tried:
Setting the ViewPager's setOffScreenPageLimit to 4, which I thought would pre-load the views and eliminate any loading in between paging, but in the end setting it to 0 seemed to make the thing slightly more likely to show at least a frame of animation
Optimizing the custom ListViews by using convertView to reuse old views, while it did result in more of the animation being shown, it still wasn't completely smooth, varying from "almost perfect animation" to "instant flip"
Removing the custom background, which together with the above two fixes lead to an almost good enough solution, but still resulted in flips every few steps.
The tinkering described above leads me to believe it has something to do with the views being loaded, but I've not found a good solution for pre-loading these to the desirable effect.
Knowing my newbie programming skills, I know there is a sure fire way to solve this without resorting to gimping the design of the app itself, but reading through the documentation, Stack Overflow questions, Googling for advice, I've just ran out of places to look to.
To sum up this probably too verbally descriptive post my main questions are:
Is there a way to ensure the animation of the ViewPager is executed smoothly? A separate thread perhaps? As I understand though, UI stuff should only be on the main thread, where it already is, and nothing else aside from the view loading is executed anywhere in the code when paging.
Should I be using a different way to load the pages? Would Fragments help?
Thank you for any advice.
ps. The lack of code is due to the methods in question being the most basic implementations possible, but I will provide the code if necessary.