Danger Mines

I’ve started coding Android again and in all honestly it fields like jumping head first into a mine field. Everything is littered with hidden problems that you have to carefully navigate around. This time I’ll try to cherry pick some of the problems I’ve had whilst getting a normal list view to work. This is probably the first and most standard thing you would want to implement when building an app yet all the resources are so scarce in detail when it comes to the only slightly more advanced features like laying out multiple items in the list or filling your screen with more than just a handful of items. So here it goes, below is an image of what I tried to achieve:

Android ListView

Android ListView

Thumbnail pictures

One of the things I wanted was a thumbnail picture sized with free width (according to aspect ratio) but with a clamped height, not higher that of the list item height. This took me a good 4 hours before I came across a couple of sources  saying that no matter how many combinations of layout_height, layout_width etc you try you will not get the image not to occupy unnessecary space when rescaling. So in the end I used ScaleImageView written by Maurycy Wojtowicz. Basically what it does is to recalculate the actual width of the image when I rescale it by height. I would’ve thought the standard ImageView would do this but apparently not, so instead of hurting your head with getting the image to work try this from the start. In addition to just adding the class you also need to create a resource file: resvaluesattrs.xml, this file should contain the following to be able to reference the new custom view in xml:

That is to say, this was the problem once I had retrieved the images. Of course they weren’t on disk so I had to fetch them from a URL, just this requires a big bit of code I would’ve thought would be included by default in the framework. For my downloading I used this following AsyncTask implementation that upon completion of download assigns the ImageView the bitmap (taken from here). Something to consider here is to also cache this download (as you’ll come to see why below).

 Weighted layout

Another big issue was getting the layout to play nicely, much to do with the fact that my image was taking up to much space but also due to the tricky nature of weighed layouts in Android. There are a lot of resources about this out there, unfortunately not enough to not make the Android Developer Docs come out on top, the least descriptive one. Instead I would warmly recommend this one that visually really explains how the weighted values work. Basically the layout_weight describes how big a portion of the sum of all weights the element should grab of the remaining free space. So what we would be used to in percentages 25+25+50% would be described as 1+1+2 and that still just acts on the free space so elements with wrap_content will still get their fair share of space anyway.

The layout I ended up with in the list image above looks like this:

List item view caching

If you’ve got to this page you’ve probably already implemented your first custom list adapter, maybe using something like this:

You may also have been a bit curious about what this if(view == null) means in all the examples and I just found out the hard way.

If you have a list of a thousand items you can image that keeping them all in memory would be a bit painful, therefore Android caches the item views for you to repopulate when new items come into view… wait what? Yes, sure it makes sense but it also means that your getView() actually should not have as a main focus to create new views but to populate views because only for the first set of items being displayed in the list will you actually create new views. Most applications using a list will definitely have more items than that in a list, after all otherwise a list would be somewhat overkill. This means that we need to take great care into doing a set of different things:

1.Make sure you set all item properties, if you’ve hidden things previously make sure to unhide them and clear out any old values

2. If you “change” your view, say remove stuff, these will be permanently gone

3. Your items will be recreated each time they come into view, as such, don’t load stuff in here or at least make sure you cache them

This article explains the above a bit more in detail.

One thing you can do that might ease this is to create view types, I’m not entirely convinced by using these soft integer id’s for types but it’s better than nothing, in short you override a getViewType method in the adapter and return the type of view you have for an item, this way you can handle objects of different kinds making sure the view they reuse is of the same layout time, ie:

I’ll anything else I come across in the days to come.

If you got here before wasting hours bashing your head against this, you’re welcome if not, you have my condolences, I’m going to try and reassemble my own patience now and try to get on with it. Thanks for reading.