best way to implement a list of special UI elements? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 8 years ago.

Improve this question

guys. I need an advice. What is the best way to implement in android a list of such UI elements (see the ref) A list contains a lot of such elements (about 30-40). I'm using now relative 开发者_Go百科layout and 4 text fields and I think it isn't a good way... I think it's too heavy (full list will contain: 30 relative layouts and 30*5 = 150 text fields).

Any suggestions how to make it more lightweight?

Thanks guys )

---

That view is fairly straightforward, and performancewise should be no problem at all as long as you use a ListView with a ListAdapter that properly utilizes view recycling and the holder pattern (see the Android API Demos List14 demo for a good example of that). That means your row view will only be inflated (the expensive part) a few times, and after that you'll simply be populating an existing row that has moved off screen with new information to be rerendered, so in reality there end up being only 6 or 7 instances of your row view in memory, not 40.

Caveats: Make sure you're not doing anything that blocks the UI thread in your adapter's view inflation/population, like loading an image from the network or making random expensive SQLite queries, since this will noticeably affect experience during scrolling. Most of that sort of work should be done in background threads, usually with a delay to not kick off mid-scroll (see Brad Fitzpatrick's 2010 IO talk for more on that).

I highly reccommend watching Romain Guy's presentations from Google I/O 2009/2010 on UI speedups mostly relating to ListView to all Android developers. The 2009 one is a bit old (Cupcake era) but both have lots of goodies on listviews and view recycling and some real-world benchmarks on the benefits, and some other less-obvious performance killer warnings (like "don't allocate objects in your adapter's getView()" -- causing GC is bad.)