In my current application, which is for in-car use, I am displaying a series of Views (which represent gauges) at arbitrary locations within a RelativeLayout (the dashboard). There is obviously an amount of backing data that describes the positioning of those gauges, their attributes, the measurement data that they display, and so forth.
At this point, it would seem sensible for me to create a separate adapter class to contain the code that translates the backing data into the appropriate gauge Views. This would follow the existing Android pattern doing things, whereby various types of View (ListView, Spinner, etc.) accept an appropriate subclass of BaseAdapter to take care of interfacing to the backing data.
What I was considering doing is extending RelativeLayout so that it accepts an Adapter and calls the standard Adapter methods (like getCount(), getView(), and so forth). My custom Adapter would apply appropriate LayoutParams to each View so that it is appropriately positioned in the RelativeLayout.
So, rather than being a specific question as such, I’m just curious to know whether using the Adapter interface is suitable in this instance. What bugs me slightly is that in the Android library, Adapters seem to be commonly used for Views that present information in a list format. Do you think that subclassing Adapter (or BaseAdapter) sounds like a good pattern for what I’m doing, or is it going against the grain somewhat by using it in a situation where data isn’t being presented in a list?
IMHO, no, unless you have an arbitrary number of gauges.
AdapterViewis designed around supporting 0-N children using a recycling pattern to only require a few actual children.Adapteris designed around being used withAdapterView.