For your different types I'd choose to change properties not related to the LayoutParams, for example use setPadding
or a view to the left whose visibility you toggle between gone
/invisible
or gone
/visible
. I like the setPadding
approach, seems to me it will be the quickest and cleanest thing.
I bet the mess is somehow related to changing Layout Parameters for every getView()
: It should work, but you would need to call requestLayout
inside getView
everytime and it can adversely affect performance. I'm no expert at this, but it's even probable that the time you win for using a convertView
is lost when you force the measure
and layout
phase again and again for every view (something that in the case of a quick fling is happening tens of times continuously)
From http://developer.android.com/training/custom-views/optimizing-view.html:
Another very expensive operation is traversing layouts. Any time a view calls requestLayout()
, the Android UI system needs to traverse the entire view hierarchy to find out how big each view needs to be. If it finds conflicting measurements, it may need to traverse the hierarchy multiple times. UI designers sometimes create deep hierarchies of nested ViewGroup objects in order to get the UI to behave properly. These deep view hierarchies cause performance problems. Make your view hierarchies as shallow as possible.
Besides the setPadding
solution, if you are adding more types in the future (ie. a file attach/voice/images...) it's not a bad idea to implement the ViewTypeCount
, etc... as @Picpik suggests. This way, in convertView
you will get a view to reuse of the same type as the new view and you can safely use the different layouts approach.