CardView und RecyclerView in Android Lollipop

Android Lollipop: Neue UI-Widgets

Lars Röwekamp, Arne Limburg

© Shutterstock/koya979

Nachdem wir in der letzten Folge gezeigt haben, welche Möglichkeiten die neuen Animationen in Android 5.0 „Lollipop“ mit sich bringen, wollen wir in der aktuellen Kolumne [zuerst erschienen im Java Magazin 11.14, Anm. d. Red.] einen Blick auf zwei neue UI-Widgets – CardView und RecyclerView – werfen und klären, ob deren Einsatz in der eigenen App zukünftig Vorteile mit sich bringen kann.

Wie bereits in der letzten Folge berichtet, bringt Android L [mittlerweile bekannt als „Lollipop“, Anm. d. Red.] nicht nur ein neues Look and Feel (Material Design) mit sich, sondern auch zwei UI-Widgets, die das zugehörige Theme als Style nutzen. Während das erste Widget RecyclerView stark an die bereits existierende ListView erinnert, stellt das zweite Widget CardView ein völlig neues UI-Element dar. Beide Widgets zeichnen sich durch eine hohe Flexibilität aus, die aber zumindest bei einer der beiden Widgets gleichzeitig auch eine nicht geringe Komplexität mit sich bringt. Aber immer der Reihe nach.

RecyclerView

Ein erster Blick auf die offizielle Android-L-Dokumentation von Google legt den Verdacht nahe, dass es sich bei der RecyclerView lediglich um eine Art „gepimpte“ Variante der ListView handelt, denn hier wird die View explizit als „more advanced and flexible version of ListView“ angepriesen. Ganz verkehrt ist dies sicherlich nicht, da die RecyclerView als Container zur Verwaltung von frei definierbaren Detailviews verwendet werden soll, die wiederum zur Darstellung von durch einen speziellen Adapter zur Verfügung gestellten Daten dienen. „Verwaltung von Views“ bedeutet in diesem Kontext u. a., dass sich die RecyclerView um das Wiederverwenden (aka „recyclen“) von Viewinstanzen kümmert – daher der Name – und so u. a. ein deutlich effizienteres Scrollen durch lange Listen von Daten ermöglicht.

Um den Einstieg in die Nutzung des neuen Widgets möglichst einfach zu gestalten, werden ein Layout-Manager zur Positionierung der List-Items (LinearLayoutManager) sowie Animationen für Operationen, wie zum Beispiel der Selektion eines Listenelements (DefaultItemAnimator) standardmäßig vorgegeben. Natürlich können beide Elemente – Layout-Manager und Animationen – auch durch eigene Varianten ersetzt werden. Möchte man eine RecyclerView innerhalb einer eigenen Activity verwenden, muss für diese neben dem bereits erwähnten Layout-Manager zusätzlich ein Adapter zum Zugriff auf die Daten angegeben werden. Auch wenn es sich hierbei nicht um den von der ListView bekannten Adapter – android.widget.BaseAdapter – sondern um einen RecyclerView.Adapter mit gänzlich anderen Callback-Methoden handelt, erinnert dieses Vorgehen doch stark an das bereits bekannte ListView Pattern.

Das eigentliche „Recyclen“ der Viewinstanzen der RecyclerView erfolgt durch das Zusammenspiel von Layout-Manager und Adapter. Der Layout-Manager positioniert die Elemente innerhalb des umliegenden View-Containers und stellt so fest, wann ein Element nicht mehr sichtbar ist und daher potenziell „recycled“ werden kann. In diesem Moment fragt der Layout-Manager – je nach Implementierung – beim Adapter einen neuen Datensatz an, mit dem er den alten Datensatz in der bestehenden View ersetzten und so die Viewinstanz wiederverwenden kann. Dieses Vorgehen bringt einen erheblichen Performanzgewinn mit sich, da weder neue Viewinstanzen für einzelne Listenelemente erzeugt noch die relativ kostspieligen findByViewId-Lookups durchgeführt werden müssen. Listing 1 zeigt eine Activity unter Verwendung einer RecyclerView.

public class FastListActivity extends Activity {

  private RecyclerView mRecyclerView;
  private RecyclerView.Adapter mAdapter;
  private RecyclerView.LayoutManager mLayoutManager;

  @Override
  protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.my_activity);
    mRecyclerView = (RecyclerView) findViewById(R.id.my_recycler_view);

    // improve performance if you know that changes in content
    // do not change the size of the RecyclerView
    mRecyclerView.setHasFixedSize(true);

    // use the default layout manager
    mLayoutManager = new LinearLayoutManager(this);
    mRecyclerView.setLayoutManager(mLayoutManager);

    // specify the adapter to use
    mAdapter = new MyAdapter(myDataset);
    mRecyclerView.setAdapter(mAdapter);
  }
  ...
}

Die Besonderheit der RecyclerView liegt in ihrer Flexibilität. Sowohl Layout-Manager als auch Adapter können beliebig ausgetauscht werden. Gleiches gilt für eine Reihe von weiteren Klassen, die im Zusammenspiel mit der RecyclerView von Relevanz sind, deren Erläuterung aber den Umfang dieser Kolumne deutlich sprengen würde. Wer das Zusammenspiel der einzelnen Klassen im Detail nachlesen möchte, sollte auf jeden Fall einen Blick in den Blog von Wolfram Rittmeyer werfen.

CardView

Das zweite neue UI-Widget – CardView – ist deutlich einfacher zu handhaben, als die eben betrachtet RecyclerView, bringt aber ebenfalls eine gewisse Flexibilität mit sich. Ziel der vom FrameLayout abgeleiteten CardView ist es, beliebige Informationen auf einer „Karte“ bzw. einem „Deck“ gruppiert darzustellen. Der Clou dabei ist, dass die Card dank cardCornerRadius-Attribut abgerundete Ecken besitzen kann. Zusätzlich kann mithilfe des elevation-Attributs ein 3-D- bzw. Schatteneffekt erzeugt werden. Listing 2 zeigt ein Beispiel einer extrem einfachen CardView aus der Originaldokumentation von Google.

<!-- A CardView that contains a TextView -->
<android.support.v7.widget.CardView
  xmlns:card_view="http://schemas.android.com/apk/res-auto"
  android:id="@+id/card_view"
  android:layout_gravity="center"
  android:layout_width="200dp"
  android:layout_height="200dp"
  card_view:cardCornerRadius="4dp">

  <TextView
    android:id="@+id/info_text"
    android:layout_width="match_parent"
    android:layout_height="match_parent" />
</android.support.v7.widget.CardView>

Gezielt eingesetzt kann die CardView zu einer verbesserten User Experience beitragen, da sich insbesondere in Listen die einzelnen Cards visuell stärker voneinander abgrenzen als die bisherigen UI-Widgets. Allerdings gilt wie so oft „weniger ist mehr“. Ziel sollte es nicht sein, alle View-Elemente mittels CardView mit einem 3-D-Effekt zu versehen, sondern das neue Widget nur dann zu verwenden, wenn es wirklich einen ergonomischen Mehrwert innerhalb der App bietet.

Fazit

Die beiden UI-Widgets CardView und RecyclerView der neuen Android-Version „L Developers Preview“ stellen eine konsequente Weiterentwicklung bestehender UI-Elemente vorheriger Versionen dar. Während die auf dem FrameLayout aufsetzende CardView den neuen Features des Material Designs Rechnung trägt und u. a. die Realisierung eines 3-D-Effekts via elevation ermöglicht, ergänzt die RecyclerView die Möglichkeiten der existierenden ListView um bisher nicht gekannte Flexibilität (ohne dabei direkt von der ListView abzuleiten). Vom Ansatz her gut durchdacht könnte aber genau diese Flexibilität zum Stolperstein der RecyclerView werden. Mit all ihren Abhängigkeiten zu anderen Klassen wirkt das neue UI-Widget bisher noch ein wenig zu komplex, um von allen Entwicklern wirklich zu 100 Prozent verstanden und somit produktiv genutzt werden zu können. Zwar existieren für Layout-Manager und Item Animations sinnvolle Defaults, die einen schnellen Einstieg erleichtern. Hier hört dann die Unterstützung aber auch schon auf. Denn anders als bei der ListView und den zugehörigen Loadern existiert bisher keine sinnvolle Standardimplementierung für den notwendigen Adapter, sodass man grundsätzlich eine eigene Variante bauen muss.

Erschwerend kommt hinzu, dass das API sich noch ziemlich im Fluss befindet, ein Tribut an den Zusatz „Developer Preview“ der aktuellen Version L. Debug-Log-Meldungen wie „You MUST implement scrollToPosition. It will soon become abstract“ für eine nicht als abstrakt gekennzeichnete Callback-Methode, wirken auf den ersten Blick etwas verstörend. Allerdings zeigen gerade diese Hinweise, dass man in der Konzeption bei Google schon deutlich weiter ist, als es der aktuelle Codestand widerspiegelt. Es ist daher zum Beispiel durchaus wahrscheinlich, dass es in der finalen Version einige weitere Implementierungen für Layout-Manager und Item Animations geben wird. Und auch vorgefertigte Varianten des Adapters, zum Beispiel für einfache Arrays oder einen Cursor scheinen in einer finalen Version nicht abwegig. In diesem Sinne: Stay tuned!

Aufmacherbild: application icons around smart phone 3d concept von Shutterstock / Urheberrecht: koya979

Geschrieben von
Lars Röwekamp
Lars Röwekamp
Lars Röwekamp ist Gründer des IT-Beratungs- und Entwicklungsunternehmens open knowledge GmbH, beschäftigt sich im Rahmen seiner Tätigkeit als „CIO New Technologies“ mit der eingehenden Analyse und Bewertung neuer Software- und Technologietrends. Ein besonderer Schwerpunkt seiner Arbeit liegt derzeit in den Bereichen Enterprise und Mobile Computing, wobei neben Design- und Architekturfragen insbesondere die Real-Life-Aspekte im Fokus seiner Betrachtung stehen. Lars Röwekamp, Autor mehrerer Fachartikel und -bücher, beschäftigt sich seit der Geburtsstunde von Java mit dieser Programmiersprache, wobei er einen Großteil seiner praktischen Erfahrungen im Rahmen großer internationaler Projekte sammeln konnte.
Arne Limburg
Arne Limburg
Arne Limburg ist Softwarearchitekt bei der open knowledge GmbH in Oldenburg. Er verfügt über langjährige Erfahrung als Entwickler, Architekt und Consultant im Java-Umfeld und ist auch seit der ersten Stunde im Android-Umfeld aktiv.
Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: