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.)