Wer Applikationen für Android entwickelt, lernt die mit der dritten Version des Systems eingeführten Fragmente schätzen. Sie erlauben das Realisieren „recyclebarer“ Komponenten, die sich in diverse Layoutdateien einbinden lassen.
Im Laufe der Zeit kommt man auf die Idee, dass man sein Fragment ? zumindest in der Theorie ? auch in der XML-Datei deklarieren kann. Das führt zu Code nach dem folgenden Schema:
<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:id="@+id/container"
android:layout_width="match_parent"
android:layout_height="match_parent"
tools:context="com.example.rsstool.DetailActivity"
tools:ignore="MergeRootFrame" >
<fragment android:name="com.example.rsstool.MessageFragment"
android:id="@+id/titles" android:layout_width="match_parent"
android:layout_height="match_parent" />
</FrameLayout>
Das böse Erwachen folgt, wenn man ein auf diese Art deklariertes Fragment mit dem Fragment-Manager „beseitigen“ möchte. Normalerweise würde eine derartige Transaktion ausreichen:
FragmentTransaction ft = getFragmentManager().beginTransaction();
ft.replace(R.id.titles, new MessageFragment());
ft.commit();
Normalerweise würde das am Bildschirm befindliche Fragment von seinem Nachfolger verdrängt. In diesem Fall passiert dies nicht ? die beiden Elemente erscheinen übereinander.
Dieses seltsame Verhalten liegt an einer wenig beachteten Besonderheit des Betriebssystems. Ein aus einer XMLl-Datei heraus „erhobenes“ Fragment wird zur Laufzeit ein vollständiger Teil des Formulars ? die „Fragmenthülle“ wird aus Performancegründen entfernt. Der einzige Weg zur „Beseitigung“ dieses Fragments wäre das Öffnen einer neuen Activity.
Holen Sie sich die Fakten Verwandte Seiten