I am trying to create a linearlayout with different relativeview layouts (containing text, image, google map, fragments. Mixed depending on the need) inside it. the views inside linearlayout will vary between 30 to 40 views. It will be mixed type of views.
I found there are two options:
Using recycler view with getItemViewType().
Directly creating views using layoutinflator.
Which option is good with respect to:
a) it should be fast.
Use a RecyclerView for performance gains. We have exact same use case #NY Times and had dramatic improvement in scroll performance when we switched from a linear layout with 30 children to instead be a linear layout with 30 rows (of about ten different view types)
Its a bit more work to setup but you'll thank yourself later.
Related
I want to use CardViews in my app only for the visual effect.
All CardViews will contain very different views, so I cannot really design a good adapter and thus I cannot use a RecyclerView.
The result is perfectly clean, but for this I had to nest a lot of ConstraintLayout, and so the layout take several seconds to draw itself. (any advice on how to measure more precisely this delay ?)
Here the hierarchy of my layout (with 9 CardViews and not 2):
ConstraintLayout
-Image + text x4
-ScrollView
--ConstraintLayout
---Cardview
----ConstraintLayout
-----text, spinner, button, etc
---Cardview
----ConstraintLayout
-----text, spinner, button, etc
You can see the max depth is ConstraintLayout>ScrollView>ConstraintLayout>CardView>ConstraintLayout, which seems inefficient as hell, as stated in the Android Optimizing Layout Hierarchies Guide.
What should I do to flatten my layout ?
I think your setup is fine. And not too deep. The layout is probably not the problem.
Note that it only draws the item on the screen. It does create layouts for the others in the ScrollView, but does not render them. If the drawing was the problem, the scrolling would be slow. You can check that.
Layout might be slow, but I doubt it. There are ways to monitor this though.
Are you loading all images off the UI thread? Nothing on the screen is coming from a server or going through some other complicated (parsing) method?
SOLUTION 1:
It's okay for RecyclerView to load different views and you can design good adapter for it. Check A RecyclerView with multiple item types and Heterogenous Layouts inside RecyclerView.
SOLUTION 2:
Considering your hierarchy you can place your cards directly to ScrollView without ConstraintLayout:
ConstraintLayout
-Image + text x4
-ScrollView
--Cardview
---ConstraintLayout
----text, spinner, button, etc
--Cardview
---ConstraintLayout
----text, spinner, button, etc
Here is an easy solution: Don't use nested ConstraintLayouts, the idea of ConstraintLayout is to reduce the amount of nested objects, but there is a performance price for it.
Base on this comment it's up to 3 times slawer than RelativeLayout. And I think that nesting it only increase the problem.
So try replacing ConstraintLayout with RelativeLayout and please reply here with the difference in performance, I bet you will see one.
I've created a very big layout (approx 2000 lines) that contains a large number of views and sub-layouts, often with weighted measures. The tree is pretty complex and goes down to 8 or more levels of nesting.
To create different "perspectives", the app programmatically sets some of the views' visibility to View.GONE, expecially those one that are at the head of a tree of views that I don't want to be displayed, in different moments of the app life cycle, and sometimes changes the weights to resize views; hence, the final layout that is displayed to the user contains at every time not more than 1/3 of the views and view-trees that are in the main layout.
I don't care about the performance at "switch" time, so when the user switches from one perspective to the other, I've got plenty of time to switch on and off the visibility and that's not a problem.
Instead, does having so many view and view trees set to View.GONE affect performance at runtime? What is the effect of GONE views on CPU and Memory performance, in contrast to a smaller layout (maybe programmatically inflated) where all views are displayed?
Actually while creating complex layout have to use constraint layout.
ConstraintLayout allows you to create large and complex layouts with a flat view hierarchy (no nested view groups). It's similar to RelativeLayout in that all views are laid out according to relationships between sibling views and the parent layout, but it's more flexible than RelativeLayout and easier to use with Android Studio's Layout Editor.
Please find the doc from url :
https://developer.android.com/training/constraint-layout/index.html
My boss refuses to let me use RelativeLayout. Everything is done using LinearLayout and minimal use of RelativeLayout, such that the layout that I could run with two levels of nesting with RelativeLayout, I now have to do with four using LinearLayout. Any comments on this? What links can share?
In my opinion it would be better to combine these two elements to get the perfect layout.
It depends on the level of nesting indeed. Android suggests to use a minimum Layouts in Layouts as possible, and if you can achieve with one layout, what you want to do with 3, why not?
The app will run faster for it, though with 2-3 nestings you wont see it.
I for example, create a bunch of included layouts, which i reuse in other layouts.
And the level of nesting could get very deep with that
With the LinearLayout we get the clear separation of view or we can say that each layout is separate. With the Linearlayout each UI element us independent of the other. You get the maximum flexibility. It enables to give the vertical and horizontal orientation.
Linearlayout you can control look more and make it almost similar even
on the device change. And also, using LinearLayout is simpler though
starting phase can be quite confusing
From the Docs
A Layout that arranges its children in a single column or a single
row. The direction of the row can be set by calling setOrientation().
You can also specify gravity, which specifies the alignment of all the
child elements by calling setGravity() or specify that specific
children grow to fill up any remaining space in the layout by setting
the weight member of LinearLayout.LayoutParams.
LinearLayout is a view group that aligns all children in a single
direction, vertically or horizontally. You can specify the layout
direction with the android:orientation attribute.
Again it depends upon your need..I also agree with #Lena Bru answer.
What Is A Relative Layout?
After linear layouts, which display controls in a single row or column, relative layouts are one of the more common types of layouts used by Android user interface designers. Much like other layouts, relative layouts can be defined within XML layout resources or programmatically in the application's Java code. The relative layout works much as its name implies: it organizes controls relative to one another, or to the parent control itself.
Get to love the RelativeLayout. It will make your life much easier, when designing for multiple resolutions/densities. If you have an old SDK, update your eclipse plugin. It has graphical snap-lines for RelativeLayouts similar to designing a form in Visual Studio, so you can see what is anchored where. It's really quite good.
google says:
Layouts are a key part of Android applications that directly affect the user experience. If implemented poorly, your layout can lead to a memory hungry application with slow UIs. The Android SDK includes tools to help you identify problems in your layout performance, which when combined the lessons here, you will be able to implement smooth scrolling interfaces with a minimum memory footprint.
I am going to start one app where my activity page will contain "n" grouped views. Grouped view means "collections of views (i.e. One group can have TextView+Button+ImageView)". So the page will have "n" number of such grouped views.
I need suggestions like what would be the best practice to implement this. I could think of below ones:
1) Should a ScrollView be used (Then I will have to create groups in runtime and place one under another)?
2) Or a ListView be used (Then how can I accommodate the height of each row as grouped views height may differ from each other?)
Or is there any other way I can go along with?
Appreciate the suggestions and any sample examples if have. Advance Thanks.
Both options would work, it really depends on your use case.
Place a vertical LinearLayout inside of a ScrollView and add your grouped-views to the LinearLayout. I would recommend this if you have a relatively small number of such views (not necessarily a fixed number, but small enough that you wouldn't have to scroll many "pages" to see them all). Make sure the ScrollView has android:layout_height="match_parent" and the LinearLayout has android:layout_height="wrap_content".
If the number of grouped-views is not small, you could use a ListView and make an Adapter for it. This lets you take advantage of ListView's automatic view recycling when items get scrolled off screen.
For either case, make an XML file for just the grouped-views. In code, you would get a LayoutInflater object (usually by calling Activity.getLayoutInflater()) and call inflate(R.layout.your_grouped_views, null). If using the LinearLayout, you would add it in code with one of the LinearLayout.addView(..) methods; if using the ListView, your adapter would return the whole thing from getView(...).
create one xml layout containing the constant elements of your group view.
in you main xml layout which will be the contentView of your application, put a ScrollView and a single LinearLayout.
then in the program inflate as many views of your group view as you want.
For your answer i want to give you referance of this website, on this website you can learn create dynamic view in android...
Lets say I have a list on screen, which I always want to be usable. I also want a small image or textview to slightly overlap the listview. Is anything this possible without using absolute layout parameters?
I've never seen it in any android app or tutorial, but there are things like this in many iPhone apps. It adds a nice touch.
(Also, I don't have any code to show because I'm not sure where to start)
Relative Layouts also allow things to overlap. Views declared later in the xml will be on top. I believe that aligning view edges and use of margins should allow you to achieve this affect without great difficulty.
You could use RelativeLayout and set for example android:layout_marginTop="-50dip" android:layout_below="#id/my_list".
As well as RelativeLayouts, you can also use FrameLayouts to stack objects. Other than the z-order (last object declared = highest z-order), the child objects don't depend on the positioning of other objects in the group, so you can just set margins or gravity to position them.
So in your instance, just declare a TextView after your ListView, and position it wherever you want. It won't interfere with the ListView's positioning, and it will sit on top.