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...
Related
I want to create what is basically a list view but without it being a ListView.
So I have a ListView right now that pulls up a layout with a CardView, TextView, etc. However I need to create multiple lists but listviews wrap the content up and makes me scroll inside the view - I don't want this. I want to be able to see the entire list and scroll in the main view.
How can I just add the layout with the CardView, instead of displaying it as a ListView? Would be a lot easier if I could attach an adapter to a Linear Layout or something.
Edit: I know I could add it all in the XML, but it seems like it'd get very bad looking in the xml code.
ListView (and RecyclerView) do a ton of non-trivial things that are very difficult to independently implement with your own homemade alternative. Fortunately, there are many third-party solutions that address your particular problem. A good choice is CWAC's MergeAdapter. It's essentially a wrapper of sub-adapters.
To handle the section headers, you can either make the first item of each sub-adapter a header item (styled accordingly). Or use MergeAdapter's addView() method to add a "header" view before each addAdapter() call.
Am trying to create a page with a scrollable list. Features would be a normal list to remove item by clicking on it. Number of items in that list are limited and added dynamically by user. You can consider a to do list as example. Now which would be a better approach to implement it? Recycler view with data bound to its adapter? Or the normal linear layout with items added as children at run time?
My current implementation is recycler view. But,I found it lagging and animations are not performing well. So a linear layout is auto animated by specifying it xml -- by setting animate layout changes to true.
FYI data is local and syncs in background.
Never use a LinearLayout for anything longer than a single screen. The whole point of ListView and RecyclerView is to efficiently reuse views instead of needing to hold things in memory when they're not visible. Maybe you can refine or reask your question so people can help you with whatever difficulty you're having with animations, rather than avoiding the issue.
I have a working example of a grid that allows items to be reordered using long touches to active a drag-n-drop. All is working well if the items are simple Views e.g. TextView or ImageView but if the items are LinearLayouts only the layout itself is displayed.
I've been using Tom Quinsn's grid (thanks Tom!!!) from this posting:
Android Gridview drag and drop example
I can get LinearLayouts to work if I derive my own LinearLayout class and override onLayout(), but this forces me to hardcode the positions of the child controls in the layout within this function.
Ideally I would like to be able to define the item layout within an XML file and inflate them before adding them to the Control that handles the grid. I'm guessing that for some reason the framework is not calling the layout function for the children contained within the DraggableGridView view as defined in Tom's code but I can't understand why that is.
I am developing my own Drag and Drop app with good help from this link. You may compare the code with the one from Tom Quesinsn. It also gets the different children of a GridView and add them as "drop targets" that accepts drops on them and copy the Image of the View you are dragging.
This is a known problem with the DraggableGridView that -- unfortunately -- I haven't gotten around to fixing. When I wrote DGV, I didn't entirely grasp how views were laid out. You might try having DGV measure each child before laying it out. Adding something like:
getChildAt(i).measure(MeasureSpec.makeMeasureSpec(childSize, MeasureSpec.EXACTLY), MeasureSpec.makeMeasureSpec(childSize, MeasureSpec.EXACTLY));
before the layout on this line:
getChildAt(i).layout(xy.x, xy.y, xy.x + childSize, xy.y + childSize);
I have a ListView with layouts in them. Sometimes the layouts need to look one way, sometimes the other. They are mainly text laid out in different areas with different weights sizes etc. The ratio of main views compared to other views is about 5:1. When it needs to be changed only 2/3 of the whole view changes.
I think I have two options :
(the way it is now) One layout(so it never has to be re-inflated, as the recycled views are all the same) and the 2nd 2/3 of the view is hidden until it is needed to be changed, then code will reveal it and hide the original 2/3 of the view.
(other way) Two layouts, with the 1/3 layout duplicated, and each having its on other 2/3. Then when one of the different layouts needs to be used, the old view from the ListView recycler gets thrown away and a new correct view is inflated, and back again when the list is moved.
So what I am asking here is that is it better to hide/show parts of the same layout to prevent the recycler in a ListView from inflating more layouts, or have two cut-down layouts with no extra hidden views, and have them inflated when they are needed?
If the TextViews are the main part of those layouts, I don't think there is going to be a big difference in performance so you could go either way. I would go with option two because:
The ratio between the number of normal rows layout vs special rows is big. If you keep the single layout approach then you'll have to modify the layouts in code for each of the rows, normal or special, because you could be dealing with a recycled View that has 2/3 part hidden when it's time to show a normal one(so you end up modifying the layout each time). If you were to use the second option then you could eliminate this part from the getView method and simply use a switch to see with what row type you're dealing with(no more modification of the row layout each time in the getView method, you let the ListView handle that by providing you with the correct type of row layout). Don't worry about inflating another layout file(once), this isn't the performance hit to be afraid of.
Using one type of layout it means you're having Views remaining in memory even if the user doesn't see them(so you may be preventing the ListView from inflating more Views(only one time, in fact) but at the same time you're occupying more memory with the ones you even don't show to the user). The first option has the advantage that the binding of data to the row is more simple as you have all the views at your disposal(even if the user doesn't see a part of them) instead of the second option, where you would have to see which data need to be shown based on row type.
Code readability. Having two row types and testing to see which one you get in the getView method it's more meaningful as you see what logic you have for each type of row. Also, it will be better if you plan to change those row layouts in the future or add more row types.
The ListView does a great job on recycling views as long as you help it with providing the row types.
Edit: The ListView will keep a recycled view for each type you declare in the adapter. So the ListView will inflate the second layout only the first time it finds it in the ListView, next time when it will need a row with with type it will use the recycled one(and it will maintain 2 types of recycled views, the first and second row type).
Actually this little bit of extra GC IMHO should not be the driver for your decision.
I would go the route that is easier to maintain and understand.
Also there is an nice useful include tag in xml like this:
<include
android:id="#+id/abc"
android:layout_height="wrap_content"
android:layout_width="fill_parent"
layout="#layout/abc" , where abc = the xml file you want to include
/>
I'm making a GUI with two different parts. The first part (at the top) is composed of some banners, several fixed buttons. So I think using LinearLayout is the most straightforward way to implement. The second part is composed of several similar items grouped together which can be implemented by using ExpandableListView, I think.
However the problem is that the content exceeds the screen size. So I intend to put two of them into a ScrollView. I checked several sources, it seems that putting "ExpandableListView" inside a ScroolView is NOT possible, or not efficent, so I'm afraid...
Would you help to confirm if this is possible? efficient ?
If no, would you give me some recommendations for this layout design?
I'm indeed looking forward to your supports.
Sincerely.
If you have a fixed header at the top of a list, use ListView's header view feature.
Putting ListViews in ScrollViews fundamentally makes no sense and here is why:
ListView has one purpose: to efficiently display unbounded data sets. Since these can be extremely large (tens of thousands of items and more) you do not want to create a View for each item up front. Instead, ListView asks its Adapter for Views only for the items that currently fit in the ListView's measured space on screen. When an item's View is scrolled out of sight, ListView disconnects that View and hands it back to the adapter to fill out with new data and reuse to show other items. (This is the convertView parameter to an Adapter's getView method.)
ScrollView also has one purpose: to take a single child view and give it "infinite" vertical space to fit within. The user can then scroll up and down to see the full content.
Now given this, how many item Views would a ListView create for a 100,000 item Adapter if it had infinite height available to fill? :)
By putting a ListView inside a ScrollView you defeat ListView's key purpose. The parent ScrollView will give the ListView effectively infinite height to work with, but ListView wants to have a bounded height so that it can provide a limited window into a large data set.
Well Expandable List View itself has scrollable property by placing it in scroll view is really undesirable.As the both scroll would contradict and smooth scrolling can't be obtained in that case..
If we have any data to be shown prior or later to list...
Best way is to use header and footer view to list...
I recommend you use header and footer in your case.