i have to draw a listview with sections.
To be precise i have to display events in the different months of the year. In this the month name becomes the header of the section and the event in that month become the data inside the section.
i am currently getting data in a hashmap, with the month name as the key and an array on events in that month as an object.
how do i achieve this effect? In iphone app development i believe there is a inbuilt functionality for this, is there such a provision in android?
thank you in advance.
NOTE:
why can't i use a TableView inside a ScrollView to do the above? There is no need to go through adapters and all when i can do this. The process should become very less complex.
Due to the lack of built-in support for sectional header lists, we have to deal with section-header and caption views separably, where sectional-header should be non-clickable and should not be counted as a ListView child. For this you have to override some methods like getView, getCount etc of an efficient adapter.
Search separatedListAdapter for more references.
Related
I am doing app as Google Calendar to add events.
The Google Calendar uses this UI:
When you create an Event, it draws a blue Layout(or TextView) to represent the duration of the Event.
I am trying to do that effect. I have my ListView where each row represents one hour.
If I have a Event with 2.5 hour of duration, the Layout must be on 2 and a half rows of the ListView.
How can I draw a single Layout on multiple rows?
I am using a custom ListView with a custom Adapter. I understand when you override getView() in the Adapter, you draw just one row of the list. I don't know if this is the correct approach to do this.
Thanks for your help and sorry for the bad english.
I guess Google Calendar use custom container instead of ListView for doing that. If you take a look at original calendar with switched on "Show layout bounds" or by using DDMS you will see following:
So to achive the same behavior, taking in account that GC Event could be scheduled with 5min precision the best way to achive this is by manualy manipulating views on layout (creating own container for Event views).
Also you could take a look on existing libraries like following:
Calendar-Day-View
Android-Week-View
If I have a custom autocomplete fragment, in which I repeatedly destroy the contents and refill it with (at most 6) text views, as the user types a string.
Currently I'm using a LinearLayout for the text views, but I was considering using a RecyclerView for this. I'm unsure if this is really necessary though, given the fact that I have:
At most 6 text views in the dropdown and I expect the user to type ~ 5 characters before submitting or choosing an autocomplete item.
So the question is: Will there be a performance difference between the two? Should I bother changing from LinearLayout to RecyclerView?
See, any how recyclerview is better because it reuses the itemview for displaying the list. And in future , if we add more items, just add the items,to the array lisy, it will do all the task automatically.
I don't think there will be a better performance using recyclerview. Since you only have 6 fixed textviews to deal with, there is no reason to switch.
recyclerview's performance boost comes to having super long lists while updating, adding, removing its data on runtime. Otherwise there's no difference.
Why not use AutoCompleteTextView ?
When you are working with a long, big list, certainly one should use ListView because it handles cell recycling.
Notice here, for example Can i use nested linearlayouts instead of list view, for a big list? the OP is asking about ListView verses a dynamic LinearList -- the answer is "have to use a ListView, because of recycling"
Now, say you are making a short list -- imagine say a popup with only 10 or 20 items. It may even fit all on the one screen, so there's no recycling.
In fact, is there any difference between using a ListView and just using a LinearLayout, and dynamically populating the little views inside it?
It seems to me that the latter is in many cases much simpler, more elegant, and easier to work with. But I could well be missing something that seasoned Android engineers know about.
Should I just use an ordinary LinearList (populate it dynamically) for lists where recycling is not relevant? What's the usual, and why? Cheers!
{Incidentally, for popup cases, is there some better, lightweight method for "choose one from a popup-list" that I'm too silly to know about?! :) )
ListView(and other lists) supports very useful idea: splitting data and view. These parts could be changed at any time so it's important to support flexibility. And it could be solved by special mediator object: Adapter. Adapter roughly speaking says how to fill your view with particular data item.
So I'm sure that if you decide to use LinearLayout sooner or later you will implement you own Adapter.
If you used dynamic linear view then rendering the view will take more time as compare to listview. In listview we are rendering views which are visible only but if you used dynamic linear view then its problem.
In the Google I/O 2010 talk about ListView they say you might not need to use a ListView with a bounded and reasonable number of rows. They state if you are dealing with a reasonable number of rows it is possible to just lay them out in a ScrollView.
I'm curious what people find "reasonble length" means in practice.
Would a list of 50 items with each row's views just having a few strings be reasonable to layout without using a ListView? How about 12?
I'm used to using UITableViews on iPhone for most UI so I'm inclined to use ListViews on Android but I also want to be aware it might be overkill for some scenarios and I have a really limited understanding of perf on android presently.
ListView is really the best option for anything over 3 items, it is a good option for even 2 or 3 items. If not you'll end up writing a bunch of code that converts indexes to individual variables instead of arrays, database rows, or other data structure.
It's not only about the number of items but also about whether or not your data collection will be dynamically updated. If you know you will never update the list while it's on screen and it doesn't have many items then a LinearLayout will do just fine.
In the Google I/O 2010 talk about ListView they say you might not need to use a ListView with a bounded and reasonable number of rows. They state if you are dealing with a reasonable number of rows it is possible to just lay them out in a ScrollView.
Hmmm, I can understand the logic up to a point but in reality using a ListActivity, for example, as your base class makes things very simple. OK, if you have a static list of only a dozen or so lines of text (one for each list 'item') then using a ScrollView containing TextViews would be an alternative but in reality using the adapter approach to ListViews is a lot more flexible in my opinion.
Would a list of 50 items with each row's views just having a few strings be reasonable to layout without using a ListView? How about 12?
No, if each list item has a few strings to be laid out then custom list item layouts together with a ListView and a custom adapter are basically a must.
I have a custom adapter to display a list of items with section headings. I've looked at Jeff Sharkey's SeparatedListAdapter and CommonsWare's MergeAdapter as examples of how to achieve this, and I now have a solution which works by providing a separate adapter for the content of each section.
This creates a big performance problem, though. In my case, there are potentially thousands of items in the list, each with an associated date, and I want to use the date as section heading for all the items with that date.
So, without section headings, I'd have a single Cursor which returns the items sorted by date. Nice and easy.
With section headings, I'm currently doing this:
One Cursor to select all distinct dates in the dataset
For each distinct date, a separate Cursor to return the items matching that date
Pour the dates (section headings) and separate SimpleCursorAdapters for each date's items, into my custom adapter.
This requires many more database queries and Cursors to be generated than I want, and there's a delay of several seconds before the ListView appears.
I suspect there might be a simpler solution where getView does something clever and detects when the date has changed between successive items, and then sneaks in a new heading by itself, thus requiring just the one Cursor. Can anyone suggest a way of doing this?
I guess the easiest way would be to check within every getView call whether the previous item has a different date, and if so to simply embed the header within the current view.
You can try http://code.google.com/p/android-section-list/, which requires just single cursor behind (returning cursor + section in one object). However it will anyhow have to go through all the elements (once) to calculate the size of resulting list+headers (needed by list adapter) - so it might still be slow.