Question

I’m writing a vertical scrollable calendar application(listview) that is always showing 1 month at a time. Whenever the user scrolls a certain amount of dip either up or down the I want the calendar to jump either to the next or previous month(depending of the direction of the scroll).

I do the jump with the setSelection method. My problem is that for some reason setSelection calls getView twice. First it calls for position 0 then for position 1 – always.
So basically whenever I want to scroll to an adjacent month getView is called 3 times.
First it is called because the list needs to show the top/bottom of the next/previous month
and after that – as I said – it is called twice because of setSelection(for position 0 and position 1 always).

I have two problems with this. First I have a textview that keeps refreshing every time I scroll to a new month. I provide the data for this textview based on calculations I do in getView and since the getView is called 2 additional times with false datas(for position 0 and 1… in other words the very first and second month the calendar is capable showing) my date textviews shows wrong date sometimes.(to be more exact it shows the first month of the list whenever I scroll really fast instead of the actual month)

Of course I could solve this somehow e.g. I put a counter integer in the getView method or something like this but my other problem is that the calendar is a bit laggy. Instead of scrolling smoothly it needs about a second to load the next month whenever I start the scrolling motion.
If somehow I could avoid setSelection that’d solve both of my problems.
I’ve tried using scrollBy but it doesn’t generate the next month.

Any ideas?
Thanks in advance

Answer 1

Rather than trying to reduce the number of getView calls you should reduce the amount of processing that is done within the getView method. This method should focus on assigning values rather than performing calculations. You should not try to pre-empt the calls.

In this case you could easily hold a list of post-calculated data objects that your adapter can read off.

If you are not already doing so, you should also take advantage of the view holder pattern demonstrated here.