Ja, die OOP verleitet schon mal dazu alles und jedes schön in einem Objekt zu kapseln - wenn dann aber sehr viele davon erzeugt werden, kostet das zusätzliche Ressourcen gegenüber einem prozeduralem Ansatz. Dem muss man sich natürlich im Klaren sein.
Ja, dies ist die goldene Regel der Programmierung! 
Jede Optimierung, welche den Code umfangreicher und damit unleserlicher macht und am Schluß keinen Unterschied bewirkt ist absolut unötig.
In diesem Fall würde ich aber noch nicht von Optimierung sprechen, denn jedes unötig erzeugte Objekt ist meines Erachtens nach hässlich.
Die [code]if(convertView == null)[/code] macht den Code ja auch nicht unleserlicher - im Gegenteil: es hat dabei geholfen zu erkennen, dass das erstellte Objekt beim nächsten Aufruf der Routine wieder mitgegeben wird.
Das hättest du mal unseren Vorgängern hier sagen sollen! :lol:
Niemand von denen mehr da, keine Doku und der Code das reinste Chaos:
- globale Variablen en masse
- gleich mal 15 davon nur für die (eine!) Uhrzeit
- uninitialisierte Variablen - und das in C!
- hier und da Endlosschleifen
- der komplette Code durchzogen mit alternierenden Präprozessor-Switches
- keine sinnvolle Kommentierung
- und noch viele viele solcher Dinge mehr...
Glaube mir, ich lege sehr viel Wert auf sauberen Code - in welcher Form das passiert ist aber eben wohl doch etwas Geschmackssache.
Ich würde sogar sagen, dass es unsauber ist, überhaupt in Pfund und Fuß zu programmieren - maximal bei der Präsentation für den Nutzer dürfen die Werte umgerechnet, aber keines Falls intern so verwendet werden!
Durch einen Fehler bei einer solchen Einheiten-Geschichte ist sogar schon mal ein Millionen-teuer Mars-Satellite abgestürzt...
Ich habe jetzt eine ListViewEx-Klasse erstellt, welche mir die Arbeit mit einem ListView vereinfacht. Ex steht dabei für Extendet, dass habe ich so von der Windows-API übernommen. Ich möchte dir hier kurz zeigen, wie ich das mit der Komponenten-Philosophie meine - du kannst dann ja für dich entscheiden, ob es vielleicht doch ok ist, oder eben absolut nicht dein Fall.
In ein Package eines Android-Library-Projektes habe ich folgende zwei Klassen gepackt:
[code=Java]
package common.view.list;
import java.util.List;
import android.content.Context;
import android.view.View;
import android.view.ViewGroup;
import android.widget.ArrayAdapter;
import android.widget.LinearLayout;
import android.widget.TextView;
public class ItemAdapter extends ArrayAdapter<Object> {
private Context m_context = null;
private List<Object> m_items = null;
// constructors //////////////////////////////////////////////////////////////
public ItemAdapter(Context context, List<Object> objects) {
super(context, 0, objects);
m_context = context;
m_items = objects;
}
public ItemAdapter(Context context, Object[] objects) {
super(context, 0, objects);
m_context = context;
for(Object item : objects) {
m_items.add(item);
}
}
// override methods //////////////////////////////////////////////////////////
@Override
public View getView(int position, View convertView, ViewGroup parent) {
if(convertView == null) {
convertView = new LinearLayout(m_context);
}
final TextView lblName = new TextView(m_context);
final Object item = this.getItem(position);
lblName.setText(item.toString());
((LinearLayout)convertView).addView(lblName);
return convertView;
}
@Override
public int getCount() {
return m_items.size();
}
@Override
public Object getItem(int position) {
return m_items.get(position);
}
@Override
public void clear() {
m_items.clear();
}
@Override
public void add(Object object) {
m_items.add(object);
}
// other methods /////////////////////////////////////////////////////////////
public void addItemAt(Object item, int pos) {
m_items.add(pos, item);
}
public void addItems(Object[] items) {
for(Object item : items) {
this.add(item);
}
}
public void addItems(List<Object> list) {
for(Object item : list) {
this.add(item);
}
}
public void addItemsAt(Object[] items, int pos) {
for(Object item : items) {
this.addItemAt(item, pos++);
}
}
public void addItemsAt(List<Object> list, int pos) {
for(Object item : list) {
this.addItemAt(item, pos++);
}
}
public void setItems(Object[] items) {
m_items.clear();
for(Object item : items) {
this.add(item);
}
}
public void setItems(List<Object> list) {
m_items.clear();
for(Object item : list) {
this.add(item);
}
}
public List<Object> getItems() {
return m_items;
}
}
[/code]
[code=Java]
package common.view.list;
import java.util.ArrayList;
import java.util.List;
import android.content.Context;
import android.util.AttributeSet;
import android.widget.ListAdapter;
import android.widget.ListView;
public class ListViewEx extends ListView {
// constructors //////////////////////////////////////////////////////////////
public ListViewEx(Context context) {
super(context);
this.setAdapter( (ListAdapter)new ItemAdapter(context, new ArrayList<Object>()) );
}
public ListViewEx(Context context, AttributeSet attrs) {
super(context, attrs);
this.setAdapter( (ListAdapter)new ItemAdapter(context, new ArrayList<Object>()) );
}
public ListViewEx(Context context, AttributeSet attrs, int defStyle) {
super(context, attrs, defStyle);
this.setAdapter( (ListAdapter)new ItemAdapter(context, new ArrayList<Object>()) );
}
// methods ///////////////////////////////////////////////////////////////////
public void addItem(Object item) {
((ItemAdapter)this.getAdapter()).add(item);
}
public void addItemAt(Object item, int pos) {
((ItemAdapter)this.getAdapter()).addItemAt(item, pos);
}
public void addItems(Object[] items) {
((ItemAdapter)this.getAdapter()).addItems(items);
}
public void addItemsAt(Object[] items, int pos) {
((ItemAdapter)this.getAdapter()).addItemsAt(items, pos);
}
public void addItems(List<Object> list) {
((ItemAdapter)this.getAdapter()).addItems(list);
}
public void addItemsAt(List<Object> list, int pos) {
((ItemAdapter)this.getAdapter()).addItemsAt(list, pos);
}
public void setItems(Object[] array) {
((ItemAdapter)this.getAdapter()).setItems(array);
}
public void setData(List<Object> list) {
((ItemAdapter)this.getAdapter()).setItems(list);
}
}
[/code]
Nun binde ich nur noch das Library-Projekt in mein aktuells Android-Projekt ein und kann mit folgenden zwei Zeilen eine ListView anzeigen:
[code=Java]
ListViewEx list = new ListViewEx(context);
list.addItems(COUNTRIES);
[/code]
Dies hat folgende Vorteile:
- das Hauptprojekt wird schank gehalten und bleibt dadruch übersichtlicher
- die zwei Zeilen sind schneller geschrieben, als eine Adapter-Klasse hinzugefügt
- der Anwender der Klasse muss nichts über den intern verwendeten Adapter wissen - er kann einfach über das Intellisense der ListView-Instanz die passende Methode wählen, ohne auch nur eine Google-Suche ausführen zu müssen. Eine Diskussion wie diese wäre überflüssig. => es ist einfach intuitiver!
Man könnte anstatt ListView zu erweitern das Problem auch mittels Komposition lösen, um die Intellisense-Liste sauber zu halten. - In diesem Fall wird man aber in Spezialfällen sicherlich einige Methoden vermissen und muss die ListViewEx dann ggf. erweitern. Mit Vererbung bleibt man flexibler, auch wenn es nicht ganz so sauber ist. So könnte ich z. B. immer noch einen eigenen Adapter verwenden, wenn ich es will.
Evtl. kann man den Adapter noch so erweitern, dass er mehrere Spalten erzeugt, wenn in den einzelnen Items wiederum Arrays stecken. Dies würde aber einige Arbeit machen, da man ja auch den Fall abfangen sollte, wenn der Nutzer unterschiedlich lange Arrays für die Items übergibt - daher habe ich mir das jetzt mal gespart. Dies würde dann der Funktion eines CellRenderers unter Java nahe kommen.
Wenn man dann eine kleine Doku zur Libarary macht und zu jedem Hauptprojekt angibt, was aus der Library verwendet wird, dann sollte jeder damit gut klar kommen - Android-Neulinge vlt. sogar besser, als mit Best Practice.
Noch "ein" Wort zum XML-Layouting: damit komme ich nun überhaupt nicht klar!
- man muss hier nur um einen String zu ändern in eine andere Eclispe-View wechseln, was einige Klicks erfordert
- die XML-Programmierung ist mit seinen öffnenden und schließenden Tags sehr lässtig - Java-Syntax liest sich schöner und ist dazu schneller und einfacher geschrieben.
- die Ressourcen für eine Komponente gehören zur Komponente dazu - sie sollten daher auch am gleichen Ort abgelegt werden (Komponenten-Philosophie eben). Für die autoamtische Generierung der R-Klasse ist aber ein separter Ressourcen-Ordner nötig.
=> Es streubt sich einfach alles in mir, das XML-Layouting anzunehmen.
Das ist wohl so wie mit der Relligion: man muss die Ansichten anderer einfach tolerieren.
Ich lasse mir gern vielen sagen, aber nicht, dass ich unstrukturiert und unsauber programmiere.
Letztenlich muss man einfach mit seinem eigenen Stil klar kommen. Wobei ich bei Android natürlich auch noch am Lernen bin.
- Es kann also gut sein, dass ich in Zukunft leider noch die ein oder andere Diskussion eröffnen muss...
Nochmal vielen Dank für deine Hilfe und auch für die Tipps bzgl. Android-Programmierung. Ich werde diese bei meinen weiteren Erfahrungen mit Android beachten.
