I am building an application for Android (1.5) that, after quering a webservice, shows to the user a big amount of data that should be displayed in a "grid" or "table" style.
I must show a result of about 7 columns and 50 rows (for example a customer list with names, addresses, telephone number, sales amount last year and so).
Obviously, the 7 columns will not fix in the screen and I would like the user would be able to scroll up/down and LEFT/RIGHT (important because of the number of columns) to explore the grid results.
Cell selection level is NOT necessary, as much I would need row selection level.
What is the best approach to get this interface element? Listview / GridView / TableLayout?
I would suggest a grid with rows that are 'expandable' to show the child row containing a subset of the data that you could maybe consider as details. That way the user can look at data for the rows they are interested in, but ignore the rest.
By the objects you mention it looks like you're talking about .NET. In that case GridView will get your data displaying quickly (least programming) and in the most flexible fashion.
All you have to do is assign your contacts data to the grid view's DataSource member and you're done.
I don't know much about Android GUI programming, but the best approach for me would be using landscape orientation, few rows per page (like 5-10) and paging so that GUI will not get slow.
Check out the SlowAdapter, List13 example in the samples folder.
That might answer your questions.
On my PC the path is
"sdk folder"->android-2.1->samples->ApiDemos->src->com->example->android->apis->view
This 2 dimensional scrollview might be what you're looking for: http://androiddevblog.blogspot.com/2009/12/creating-two-dimensions-scroll-view.html
It is using a TableLayout so for reallly large datasets it might not be optimal because the views won't get re-used on scrolling. But 7x50 does'
Related
Is there a limit in rows in listview, or rows and columns in the case of gridview, that could slow down the app?
I'm looking at, a maximum nearly 5,000 individual datas with at least 3 table attributes to be displayed in each row of the listview.
It depends of how much information you are putting in each cell (if your cell contains images, for example, it obviously will take more memory). It also depends if the phone has more or less memory (the application heap is variable).
And most important, it depends if you are recycling views (see How ListView's recycling mechanism works)
one of the fragments used in this app should be a table of mostly numerical data.
6 columns by 15 rows
the top four header rows have some fused cells
that's roughly 90 views (minus the fused cells + the purely layout views - tablelayout, tablerow, for example).
The first problem is a warning that over 80 views is too much, and the app might get laggy.
What can I do about this, considering this fragment/view can't be split? - the user needs access to this table of data all at once.
Secondly, the data in the table is static - and a lot of it is calculable. However different languages don't present numerical data the same way; for example "1,000" in English would be "1000" in French - and would maybe not be represented using roman numerals in some language I don't know.
Should these roughly 30 numerical items go in a /res/values/string_file.xml, considering the file will exist anyways, if only for the table headers, or should the app calculate them, apply a locale filter, and output them to the layout?
Thank you
I'm currently working on an android application and I recently came across something which mentioned that an activity should aim to have less than 80 views.
I have a couple tablelayouts with some textviews in each one. Would it be more efficient/possible to have one textview and use html tables to try and achieve the same look I have with the tablelayouts?
It would cut down on the number of views, but would it be worth the time to rework the layout?
To get a Spannable-object (which can be displayed in a TextView) form an HTML snipped, you can use the HTML-class from the Android framework, as illustrated here: How to display HTML in TextView?
However, the docs for this class also state that:
This class processes HTML strings into displayable styled text. Not
all HTML tags are supported.
A nice list of supported tags can be found in this answer and this Blog-Post (Spoiler: <table> is not supported).
Theoretically, having more than 80 views on one Activity is a lot. In pratice, it turns out that this can be handled by many phones with ease.
I created an application that collected Geo-Data and displayed all taken locations in a table (which would have more than 900 items). Even with the full table it scrolls smoothly (on my Motorola Xoom and my HTC Desire HD).
If you should encounter any problems with long lists/tables on certain devices, there is always the option of lazy loading.
It should be a general goal to show the most important/precise data at the top (so the user does not need to scroll at all).
So, you would show the lets say 30 best hits and when the user has scrolled down to number 20 (or so), you asynchronously load the next 30 entries. That way, you get a never ending list (given that the data is endless).
I am an experienced developer, but I'm inexperienced on the Android platform. So I am seeking some advice from developers with more experience with Android.
I am building a Honeycomb application using Fragments. One of the fragments calls for a vertically scroll-able read-only "HTML table-like" view with dynamically loaded data. Similar to a spreadsheet, I should have clickable headers which I can implement server-side requests to filter/sort the data.
I am pretty sure this Control doesn't exist yet, am I right? Do I have to build it?
Assuming I have to build it, which existing widget should I extend? ListView, Table, GridView?
I assume I would have one widget for the header, and then wrap the body of the table in a scrollable layout to handle scrolling while keeping the header visible. I am concerned that I might not be able to guarantee that the headers line up with the columns.
Thanks in advance,
Tim
Android layouts are pretty basic - there are not any shipped layouts that will really do what you are looking for automatically, but you could probably do what you want with a heavily controlled gridView. Android is also pretty bad about controlling multiple elements to fit within the screen size, as it's goal is to support multiple screen sizes and densities.
From what I understand your desire to be, I think the best solution is to create a nx2 grid view dynamically, and control the width of the view based on the device size. You would have n number of headers on the top, and you could fill the lower half of the grid with your textViews, or whatever data you wanted. The hard part would be keeping the widths of the grid elements under control and on the screen. In addition, you will probably find that you can only fit a small number of header items on the screen because of the phone's small size, so you may discover a better layout to fit your needs.
I want to create a grid of words approximately three wide and eight deep. I would like to be able to select some of the words and do a fade animation on them. I would also like to know when a word has been selected. I have been looking at TableLayout and GridView to do this. Would one of these be better than the other to do this? Is one of them more adaptable to the different screen sizes in Android than the other?
I've played around a bit with tablelayout (and tablerow) and it will definitely do the trick, I guess more importantly the question is whether you expect to have a fixed number of columns or not ("approximately" doesn't help...). If so and you have very good control of what goes in the table/grid, tablelayout may very well be what you're looking for (I just find it simpler, but maybe I'm wrong).
They both can adapt to screen size with the right layout instructions, and proper programming will give you similar results.
But then, if you allow the screen to rotate, you may want to use gridview
parameters, parameters, parameters...
I think a TableLayout would be more easy to use. For a GridLayout you need to build custom adapters and so one which result in a more complicated application.
Looking at different sceensizes, a GridLayout will choose a good number of columns and rows by itself according to the content and it will be more flexible with adding items.
Also the GridLayout will be more flexible but it is some more work to make.