Dienstag, 22. Mai 2012

ActionBar

The menu control of Android is an interesting example for how the developers of the system react on experiences with the usage of the system. In the beginning - before 3.0 - the options menu was regarded so important, that there was given a seperate key for it. The menu was realized as a pure popup menu. Even the name speaks for the purpose of the menu as editing settings of the application. Indeed it happened that many applications mis-used the options menu to realize navigation.
With 3.0 the concept was re-worked. Surely it was taken into account, that the purpose of this version was mainly to support tablets and so there was enough space on the screen. The action bar as a totally new element was introduced and the options menu was integrated in this component. The action bar as a given part by default is always visible on the screen (though it may be deactivated). Since Android 4.0 the action bar is also part of the smartphone variant of the operating system. The menu key is not longer a required element of a smartphone.
The action bar is mainly devided into 4 parts ("app icon", "view control", "action buttons" and "action overflow"). The visible appearance is configurable and depends on the space available on the actual device. So the "view control" may be shown in an additional row below the main action bar (as visible in the image) or the "action buttons" may use the space on the bottom of the screen.
The "app icon" (left in the image) serves to identify the running application. It can also be used to navigate "home" or "back".
The "view control" is used to navigate in between the application, for example to activate different pages (fragments) of an activity in form of tabs.
The "action buttons" (right in the image) get close to the options menu used so far. They serve to call context sensitive additional actions. For actions used regularly this can be done directly by icon in this area, less reqularly used actions can be placed in the "action overflow" part. If there is a menu key on the device, the "action overflow" is activated by this key, otherwise there will be shown an appropriate selection list.
Not only relating to content and to handling the actions buttons of Android 3.0 replace the options menu of the earlier versions, but also from the programmers view. The transfer is very transparent.
With 2.x an options menu could be simply declared as following:

<?xml version="1.0" encoding="utf-8"?>
<menu xmlns:android="http://schemas.android.com/apk/res/android" >
 <item android:id="@+id/mainMenuItem" android:title="@string/main" />
    <item android:id="@+id/layoutDemoMenuItem" android:title="@string/layoutDemo" />
    <item android:id="@+id/layoutDemo2MenuItem" android:title="@string/layoutDemo" />
    <item android:id="@+id/fragmentMenuItem" android:title="@string/fragment" />
</menu>
Methods to add the options menu and to react on the selection of an item are overwritten on the Activity. In this case in form of a BaseActivity, where all the Acivity-Classes that use the options menu may be derived.

public class BaseActivity extends Activity {

     @Override
 public boolean onCreateOptionsMenu(Menu menu) {
  MenuInflater menuInflater = getMenuInflater();
  menuInflater.inflate(R.menu.menu, menu);
  return true;
 }

 @Override
 public boolean onOptionsItemSelected(MenuItem item) {
  switch (item.getItemId()) {
  case R.id.mainMenuItem:
  case android.R.id.home:
   Log.v(getLocalClassName(), "call main");
   Intent intent = new Intent(this, Workshop4Activity.class);
            intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
   startActivity(intent);
   break;
  case R.id.fragmentMenuItem:
   Log.v(getLocalClassName(), "call fragment");
   startActivity(new Intent(this, FragmentActivity.class));
   break;
  case R.id.layoutDemoMenuItem:
   Log.v(getLocalClassName(), "call layoutDemo");
   startActivity(new Intent(this, LayoutDemoActivity.class));
   break;
  case R.id.layoutDemo2MenuItem:
   Log.v(getLocalClassName(), "call layoutDemo");
   startActivity(new Intent(this, LayoutDemoActivity2.class));
   break;
  }
  return true;
 }
}
That's all for the trivial case.
To make the entries of the options menu visible in the action bar on Android 4.0, the corresponding entry of the XML file is given an attribute "android:showAsAction". Possible values are "never", "always", "ifRoom", "withText" and "collapseActionView". Those values may be - if it makes sense - combined with "|".
That's all so far, the BaseActivity does not need to be changed.

<?xml version="1.0" encoding="utf-8"?>
<menu xmlns:android="http://schemas.android.com/apk/res/android" >
 <item android:id="@+id/mainMenuItem" android:title="@string/main"
  android:showAsAction="ifRoom|withText" />
    <item android:id="@+id/layoutDemoMenuItem" android:title="@string/layoutDemo"
   android:showAsAction="always" />
    <item android:id="@+id/layoutDemo2MenuItem" android:title="@string/layoutDemo"
  android:showAsAction="ifRoom" />
    <item android:id="@+id/fragmentMenuItem" android:title="@string/fragment"
  android:showAsAction="ifRoom" />
</menu>
It is possible to replace the "action buttons" by more complicated controls. The possibilities surely are limited by the rare available space. An ActionProvider may replace the complete logic. "collapseActionView" allows a "short view", from which by click a more detailed view is opened.
The navigation in the "view control" part of the action bar also is not very complicated. The developer documentation describes this very useful (http://developer.android.com/guide/topics/ui/actionbar.html). There is for the case, that the pages to navigate to are realized as Fragments, simply implemented an ActionBar.TabListener. This one instantiiates the concrete Fragments as needed. Each "view control" entry of the action bar is linked with the corresponding Listener. At last only the NavigationMode of the action bar has to be set to "NAVIGATION_MODE_TABS" - in the onCreate-method of the Activity. The ContentView of the Activity has not to be set, only the default container is used. It also is relatively simple, to use a Spinner-control instead of a tab navigation. The elements of the list are defined in an array ressource and the selection of the elements is realized by a SpinnerAdapter and an OnNavigationListener.

ActionBar

Die Menu-Steuerung in Android ist ein interessantes Beispiel dafür, wie die Entwickler des Systems auf Erfahrungen mit der Verwendung des Systems eingehen. Ursprünglich – vor 3.0 - wurde das Options-Menu so wichtig erachtet, dass dafür sogar eine eigene Taste spendiert wurde. Das Menu wurde als reines Popup-Menu realisiert. Schon der Name spricht dafür, dass dieses Menu in erster Linie dazu gedacht war, Einstellungen für die App vorzunehmen. Es stellte sich allerdings heraus, dass viele Anwendungen das Options-Menu dazu missbrauchten, Navigationen zu realisieren.
Ab 3.0 wurde das Konzept überarbeitet – wobei sicherlich auch die Tatsache von Bedeutung war, dass diese Version speziell für Tablets vorgesehen und damit reichlich Platz auf dem Screen vorhanden war. Die Action-Bar als vollkommen neues Element wurde eingeführt und das bisherige Options-Menu in diese Komponente integriert. Die Action-Bar ist als fester Bestandteil per Default immer am Screen sichtbar (kann aber auch deaktiviert werden). Ab Android 4.0 ist die Action-Bar dann auch Bestandteil der Smartphone-Variante des Betriebssystems. Die Menu-Taste ist damit kein Pflichtelement eines Smartphones mehr.
Die ActionBar ist im wesentlichen in 4 Bereiche unterteilt („App-Icon“, „View-Control“, „Action-Buttons“ und „Action-Overflow“), wobei die Darstellung konfigurierbar ist und auch davon abhängig, wie viel Platz auf dem aktuellen Gerät zur Verfügung steht. So kann der „View-Control“-Bereich in einer zusätzlichen Zeile unterhalb der Haupt-ActionBar dargestellt werden (wie im Bild erkennbar) oder die „Action-Buttons“ verwenden den Platz am Fuß des Bildschirms.
Das „App-Icon“ (im Bild ganz links) soll natürlich in erster Linie dazu dienen, die aktuell laufende App zu identifizieren. Es kann auch dazu verwendet werden, zur „Home“-Activity der App oder einfach „Back“ zu navigieren.
Die „View-Control“ wird zur Navigation innerhalb der App verwendet, beispielsweise um in Form von Tabs verschiedene Seiten (Fragmente) einer Activity zu aktivieren.
Die „Action-Buttons“ (im Bild ganz rechts) kommen dem bisherigen Options-Menu noch am nächsten. Sie sollen dazu dienen, kontextabhängig zusätzliche Aktionen aufzurufen. Für häufige Aktionen kann das direkt per Icon in diesem Bereich erfolgen, weniger häufig benötigte Aktionen können im „Action-Overflow“-Bereich liegen. Wenn das Device eine Menu-Taste besitzt, wird dieser „Action-Overflow“-Bereich durch Klick auf die Taste aktiviert, ansonsten wird ein entsprechende Auswahl-Liste dargestellt.
Nicht nur bezüglich Inhalt und Bedienung lösen die Action-Buttons ab Android 3.0 das Options Menu der vorhergehenden Versionen weitestgehend ab, auch aus Sicht der Programmierung. Der Übergang ist auf dieser Ebene sehr transparent:
Unter 2.x konnte ein Options Menu einfach in der folgenden Form deklariert werden:

<?xml version="1.0" encoding="utf-8"?>
<menu xmlns:android="http://schemas.android.com/apk/res/android" >
 <item android:id="@+id/mainMenuItem" android:title="@string/main" />
    <item android:id="@+id/layoutDemoMenuItem" android:title="@string/layoutDemo" />
    <item android:id="@+id/layoutDemo2MenuItem" android:title="@string/layoutDemo" />
    <item android:id="@+id/fragmentMenuItem" android:title="@string/fragment" />
</menu>
Methoden zum Anhängen des Options Menu und zur Reaktion auf die Auswahl eines Items werden an der Activity überschrieben. Hier in Form einer BaseActivity, von der alle Activities abgeleitet werden können, die das Options Menu bereitstellen sollen:

public class BaseActivity extends Activity {

     @Override
 public boolean onCreateOptionsMenu(Menu menu) {
  MenuInflater menuInflater = getMenuInflater();
  menuInflater.inflate(R.menu.menu, menu);
  return true;
 }

 @Override
 public boolean onOptionsItemSelected(MenuItem item) {
  switch (item.getItemId()) {
  case R.id.mainMenuItem:
  case android.R.id.home:
   Log.v(getLocalClassName(), "call main");
   Intent intent = new Intent(this, Workshop4Activity.class);
            intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
   startActivity(intent);
   break;
  case R.id.fragmentMenuItem:
   Log.v(getLocalClassName(), "call fragment");
   startActivity(new Intent(this, FragmentActivity.class));
   break;
  case R.id.layoutDemoMenuItem:
   Log.v(getLocalClassName(), "call layoutDemo");
   startActivity(new Intent(this, LayoutDemoActivity.class));
   break;
  case R.id.layoutDemo2MenuItem:
   Log.v(getLocalClassName(), "call layoutDemo");
   startActivity(new Intent(this, LayoutDemoActivity2.class));
   break;
  }
  return true;
 }
}
Das ist im Trivialfall schon alles.
Um nun unter Android 4.0 die Einträge des Options Menus in der ActionBar erscheinen zu lassen, wird der entsprechende Eintrag in der XML-Datei einfach mit einem Attribute „android:showAsAction“ versehen. Mögliche Werte sind „never“, „always“, „ifRoom“, „withText“ und „collapseActionView“. Diese können auch – falls sinnvoll – mit „|“ verknüpft werden.
Ansonsten ist das schon alles, die BaseActivity bleibt unverändert.

<?xml version="1.0" encoding="utf-8"?>
<menu xmlns:android="http://schemas.android.com/apk/res/android" >
 <item android:id="@+id/mainMenuItem" android:title="@string/main"
  android:showAsAction="ifRoom|withText" />
    <item android:id="@+id/layoutDemoMenuItem" android:title="@string/layoutDemo"
   android:showAsAction="always" />
    <item android:id="@+id/layoutDemo2MenuItem" android:title="@string/layoutDemo"
  android:showAsAction="ifRoom" />
    <item android:id="@+id/fragmentMenuItem" android:title="@string/fragment"
  android:showAsAction="ifRoom" />
</menu>
Es ist möglich, die „Action-Buttons“ durch kompliziertere Controls zu ersetzen. Die Möglichkeiten sind natürlich immer durch den äußerst geringen Platz begrenzt. Ein ActionProvider ersetzt sogar die komplette Logik. „collapseActionView“ erlaubt dann eine „Kurzdarstellung“, aus der per Klick eine ausführliche Darstellung aufklappt.
Die Navigation im „View-Control“-Bereich der ActionBar ist auch nicht sonderlich kompliziert. Die Entwicklerdokumentation beschreibt das sehr anschaulich (http://developer.android.com/guide/topics/ui/actionbar.html). Dort wird für den Fall, dass die einzelnen Seiten der Navigation als Fragmente realisiert sind, einfach ein ActionBar.TabListener implementiert. Dieser instantiiert bei Bedarf die entsprechenden Fragmente. Jeder „View-Cotrol“-Eintrag der ActionBar wird dann mit dem entsprechenden Listener verknüpft. Schließlich muss nur noch der NavigationMode der ActionBar auf „NAVIGATION_MODE_TABS“ gesetzt werden – in der onCreate-Methode der Activity. Die ContentView der Activity wird nicht gesetzt, hier wird einfach der Default-Container verwendet. Relativ einfach ist es dann auch, statt einer Tab-Navigation einen Spinner zu verwenden. Die Liste der Elemente muss in der entsprechenden Array-Resource abgelegt werden. Und die Auswahl der Elemente wird über einen SpinnerAdapter und einen OnNavigationListener realisiert.

Samstag, 3. März 2012

Use of Fragments in Android

Android-Apps generally should be able to run on several different devices. Especially resolution and orientation (portrait, landscape) of an application havte to be taken into account. In particular the latter is a challenge for the developer of an application. To build an app that looks acceptable horizontally and vertically is not a trivial task - particularly if you want to avoid to much scrolling.
Introduced by Android 3.0 Honeycomb the Fragments might be helpful. Those are parts of an Activity, getting developed independently. Particularly they have a lifecycle for themselves - you find details in the android documentation. Fragments are only usable as part of an Activity.
To show you how to handle Fragments, I would like to introduce a rudimentary use case, that might serve as a base for more general cases.
What will be implemented is a list of values (first fragment) and the detail view of one selected value (second fragment). In the landscape view list and detail shall be shown beside (meaning one Activity). In the portrait view at first only the list will be seen and the selection of an element will fork into the detail view (two Activities).
The code of the base Activity is the same in both cases:

public class FragmentActivity extends Activity {
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.fragment);
    }
}
The layouts have to be seperated. For landscape in /res/layout-land/fragment.xml:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    android:orientation="horizontal" >

    <fragment class="de.kluck.fragment.FragmentList"
        android:id="@+id/fragment_list"
        android:layout_weight="1"
        android:layout_width="match_parent"
        android:layout_height="match_parent" >
    </fragment>

    <fragment class="de.kluck.fragment.FragmentDetail"
        android:id="@+id/fragment_detail"
        android:layout_weight="1"
        android:layout_width="match_parent"
        android:layout_height="match_parent" >
    </fragment>

</LinearLayout>
For portrait in /res/layout-port/fragment.xml:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    android:orientation="horizontal" >

    <fragment class="de.kluck.fragment.FragmentList"
        android:id="@+id/fragment_list"
        android:layout_width="match_parent"
        android:layout_height="match_parent" >
    </fragment>
</LinearLayout>
For the detail view in the portrait mode another layout has to be created (/res/layout-port/fragment_detail_activity.xml):

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical" >

    <fragment class="de.kluck.fragment.FragmentDetail"
        android:id="@+id/fragment_detail"
        android:layout_width="match_parent"
        android:layout_height="match_parent" >
    </fragment>
</LinearLayout>
And the Activity for the detail view has to be coded, too.

public class FragmentDetailActivity extends Activity {
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
		setContentView(R.layout.fragment_detail_activity);
		Bundle extras = getIntent().getExtras();
		if (extras != null) {
			String s = extras.getString("selectedValue");
			TextView view = (TextView) findViewById(R.id.text_detail);
			view.setText(s);
		}
	}
}
The development of the list fragment looks quite simple, since Android already provides a ListFragment class. You just need to subclass this class and set its ListAdapter. A layout is not needed, as far as the standard layout is used for the list entries.
Even in this class the click event for the list entry has to be processed. This is the only place where it is necessary to distinguish the modes the Activity might be in. Depending on this in the landscape mode simply the selected value has to be shown in the detail Fragment and in portrait mode the detail Activity is started via Intent.

public class FragmentList extends ListFragment {
	@Override
	public void onActivityCreated(Bundle savedInstanceState) {
		super.onActivityCreated(savedInstanceState);
		String[] values = new String[] { "One", "Two", "Three", "Four", "Five" };
		ArrayAdapter adapter = new ArrayAdapter(getActivity(),
				android.R.layout.simple_list_item_1, values);
		setListAdapter(adapter);
	}

	@Override
	public void onListItemClick(ListView l, View v, int position, long id) {
		String item = (String) getListAdapter().getItem(position);
		FragmentDetail fragment = (FragmentDetail)getFragmentManager().findFragmentById(R.id.fragment_detail);
		if (fragment != null && fragment.isInLayout()) {
			fragment.setText(item);
		} else {
			Intent intent = new Intent(getActivity().getApplicationContext(), FragmentDetailActivity.class);
			intent.putExtra("selectedValue", item);
			startActivity(intent);

		}
	}    
}
The detail fragment implements a method to set the text.

public class FragmentDetail extends Fragment {
	@Override
	public View onCreateView(LayoutInflater inflater, ViewGroup container,
			Bundle savedInstanceState) {
		View view = inflater.inflate(R.layout.fragment_detail, container, false);
		return view;
	}

	public void setText(String item) {
		TextView view = (TextView) getView().findViewById(R.id.text_detail);
		view.setText(item);
	}
}
The layout for the detail fragment is kept simple in this case (/res/layout/fragment_detail.xml):

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical" >

    <TextView
        android:id="@+id/text_detail"
        android:layout_width="wrap_content"
        android:layout_height="match_parent"
        android:layout_gravity="center_horizontal|center_vertical"
        android:layout_marginTop="20dp"
        android:text="Detail"
        android:textSize="30dp" />
    
</LinearLayout>
What finally misses is the code for the detail Activity, that just needs to fetch the detail text of the Intent at start and set it on the Fragment.

public class FragmentDetailActivity extends Activity {
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
		setContentView(R.layout.fragment_detail_activity);
		Bundle extras = getIntent().getExtras();
		if (extras != null) {
			String s = extras.getString("selectedValue");
			TextView view = (TextView) findViewById(R.id.text_detail);
			view.setText(s);
		}
	}
}
So far, so simple. As you can see, by the use of the Fragments their code is simply reusable. But the developer still has to maintain the layouts for the different modes.
Remark: just like the ListFragment there are PreferenceFragment and DialogFrament classes for the specific use cases.

Verwendung von Fragmenten in Android

Android-Apps erheben generell den Anspruch auf verschiedensten Devices zu laufen. Insbesondere Auflösung und Ausrichtung (Portrait, Landscape) einer Application gilt es zu unterscheiden. Für den Entwickler einer Applikation stellt gerade Letzteres eine Herausforderung dar. Eine Application sowohl horizontal, wie auch vertikal ordentlich aussehen zu lassen ist nicht trivial – insbesondere wenn man dem Nutzer Scroll-Orgien ersparen will.
Eine Hilfe dabei sind die ab Android 3.0 Honeycomb eingeführten Fragments. Dabei handelt es sich um Teile eine Activity, die eigenständig entwickelt werden können. Insbesondere besitzen sie auch einen eigenen Lifecycle – Details dazu in der Android-Doku. Fragments können aber nur im Rahmen einer Activity verwendet werden.
Um den Umgang mit Fragments zu veranschaulichen, werde ich einen rudimentären Anwendungsfall vorstellen, der als Basis für allgemeinere Fälle verwendet werden kann.
Grundlage ist eine Liste mit Werten (Fragment 1) und die Detailansicht eines ausgewählten Wertes (Fragment 2). Während in der Landscape-Sicht Liste und Detail nebeneinander dargestellt werden sollen (also in einer Activity), soll in der Portrait-Sicht zunächst nur die Liste zu sehen sein und die Auswahl eines Elementes in die Detailsicht verzweigen (zwei Activities).
Der Code der Basis-Activity ist in beiden Fällen der gleiche:

public class FragmentActivity extends Activity {
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.fragment);
    }
}
Hingegen müssen die Layouts unterschieden werden. Für Landscape in /res/layout-land/fragment.xml:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    android:orientation="horizontal" >

    <fragment class="de.kluck.fragment.FragmentList"
        android:id="@+id/fragment_list"
        android:layout_weight="1"
        android:layout_width="match_parent"
        android:layout_height="match_parent" >
    </fragment>

    <fragment class="de.kluck.fragment.FragmentDetail"
        android:id="@+id/fragment_detail"
        android:layout_weight="1"
        android:layout_width="match_parent"
        android:layout_height="match_parent" >
    </fragment>

</LinearLayout>
Für Portrait in /res/layout-port/fragment.xml:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    android:orientation="horizontal" >

    <fragment class="de.kluck.fragment.FragmentList"
        android:id="@+id/fragment_list"
        android:layout_width="match_parent"
        android:layout_height="match_parent" >
    </fragment>
</LinearLayout>
Für die Detailansicht im Portrait-Layout muss ein weiteres Layout angelegt werden (/res/layout-port/fragment_detail_activity.xml):

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical" >

    <fragment class="de.kluck.fragment.FragmentDetail"
        android:id="@+id/fragment_detail"
        android:layout_width="match_parent"
        android:layout_height="match_parent" >
    </fragment>
</LinearLayout>
Und die Activity für die Detailansicht muss auch codiert werden:

public class FragmentDetailActivity extends Activity {
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
  setContentView(R.layout.fragment_detail_activity);
  Bundle extras = getIntent().getExtras();
  if (extras != null) {
   String s = extras.getString("selectedValue");
   TextView view = (TextView) findViewById(R.id.text_detail);
   view.setText(s);
  }
 }
}
Die Entwicklung des List-Fragments gestaltet sich ganz einfach, da Android bereits eine entsprechende ListFragment-Klasse zur Verfügung stellt. Es muss nur davon abgeleitet und ein ListAdapter gesetzt werden. Ein Layout wird nicht benötigt, sofern das Standard-Layout für die Listen-Einträge verwendet wird.
Allerdings muss in dieser Klasse auch das Click-Event für den Listen-Eintrag bearbeitet werden und das ist die Stelle, wo tatsächlich geprüft werden muss, in welchem Modus sich die zugeordnete Activity befindet. Abhängig davon wird dann im Landscape-Modus einfach nur der selektierte Wert im Detail-Fragment dargestellt bzw. im Portrait-Modus die Detail-Activity via Intent gestartet.

public class FragmentList extends ListFragment {
 @Override
 public void onActivityCreated(Bundle savedInstanceState) {
  super.onActivityCreated(savedInstanceState);
  String[] values = new String[] { "One", "Two", "Three", "Four", "Five" };
  ArrayAdapter adapter = new ArrayAdapter(getActivity(),
    android.R.layout.simple_list_item_1, values);
  setListAdapter(adapter);
 }

 @Override
 public void onListItemClick(ListView l, View v, int position, long id) {
  String item = (String) getListAdapter().getItem(position);
  FragmentDetail fragment = (FragmentDetail)getFragmentManager().findFragmentById(R.id.fragment_detail);
  if (fragment != null && fragment.isInLayout()) {
   fragment.setText(item);
  } else {
   Intent intent = new Intent(getActivity().getApplicationContext(), FragmentDetailActivity.class);
   intent.putExtra("selectedValue", item);
   startActivity(intent);

  }
 }    
}
Das Detail-Fragment bekommt eine Methode, um den Text zu setzen:

public class FragmentDetail extends Fragment {
 @Override
 public View onCreateView(LayoutInflater inflater, ViewGroup container,
   Bundle savedInstanceState) {
  View view = inflater.inflate(R.layout.fragment_detail, container, false);
  return view;
 }

 public void setText(String item) {
  TextView view = (TextView) getView().findViewById(R.id.text_detail);
  view.setText(item);
 }
}
Das Layout für das Detail-Fragment ist hier auch bewusst einfach gehalten (/res/layout/fragment_detail.xml):

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical" >

    <TextView
        android:id="@+id/text_detail"
        android:layout_width="wrap_content"
        android:layout_height="match_parent"
        android:layout_gravity="center_horizontal|center_vertical"
        android:layout_marginTop="20dp"
        android:text="Detail"
        android:textSize="30dp" />
    
</LinearLayout>
Schließlich fehlt noch der Code für die Detail-Activity, der aber letztendlich nur beim Starten den Detail-Text aus dem Intent holen und dem Fragment übergeben muss.

public class FragmentDetailActivity extends Activity {
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
  setContentView(R.layout.fragment_detail_activity);
  Bundle extras = getIntent().getExtras();
  if (extras != null) {
   String s = extras.getString("selectedValue");
   TextView view = (TextView) findViewById(R.id.text_detail);
   view.setText(s);
  }
 }
}
So weit, so einfach. Es ist gut erkennbar, dass zwar zum einen durch die Fragmente der entsprechende Code sehr schön wiederverwendbar ist, zum anderen aber dem Entwickler nicht die Aufgabe abgenommen wird, die Layouts für die verschiedenen Modus zu pflegen.
Als Anmerkung: ähnlich dem ListFragment gibt es auch PreferenceFragment und DialogFragment Klassen für die entsprechenden Spezialfälle.

Sonntag, 26. Februar 2012

AsyncTask and AsyncTaskLoader

As soon as you develop some larger application based on the android platform, you will soon discover, that the system refuses to execute runtime-extensive tasks in the UI thread. This are accesses via the network, but also to the file system, to preferences and to the database. Depending on the API level it leads to a corresponding message ("application not responding") or even to an exception.

So the relevant topic has to be rolled out to a asynchronous task. Not rarely such a task will have to change the UI after being completed successfully, for instance to show the results. Since it is not possible to access the UI thread from this thread again, the synchronisation is part of the problem.

The familiar approach for a Java developper would be simply to start a java thread. But from this thread it is not possible to access the UI. For this case the android Activity provides a "runOnThread" method. This given a Runnable to process the tasks in the UI thread. Schematically it would look like this:

Thread thread = new Thread(new Runnable() {
   public void run() {
      // ...
      // do long running tasks here
      // …

      // running in Activity context
      runOnUiThread(new Runnable() {
         public void run() {
            // ...
            // update UI here
            // ...
         }
      });
   }
});
thread.start();


A little more elegant and "android like" is the usage of the "AsyncTask<>". It will be subclassed and some methods have to be implemented. The template parameters define the parameters of the "doInBackground" call, the "onProgressUpdate" method and the type of the return value for the "onPostExecute" method. The latter will be called in the context of the UI thread.


public void useTask() {
   new FooTask().execute("param1", "param2");
}

class FooTask extends AsyncTask {
   protected String doInBackground(String... params) {
      int progress = 0;
      String result = params.length > 0 ? params[0] : "";
      // ...
      // do long running tasks here
      // ...
      publishProgress(progress);
      // ...
      // work
      // ...
      return result;
   }
   protected void onProgressUpdate(Integer... progress) {
      // ...
      // propagate progress to UI
      //
   }
   protected void onPostExecute(String result) {
      // ...
      // update UI here
      // ...
   }
}


Another possibility to solve the problem would be to implement a specific service for the task. The communication between service and UI thread would be done via Intents and BroadcastReceiver, making the implementation quite complex and unclear.

All these approaches have the downside, that it has to be reagarded, if the Activity is terminated prematurely. This can soon be the case for instance just by turning the device. The asynchronous task in this case would continue running in its thread. The processing of the results could soon lead to unrequested results.

Since Android 3.0, API-Level 11 another possibility enters the game with the "Loader" concept. By using the V4 support library it is also available for earlier API levels. Loader in Android are managed by a Loader manager, that for instance also should handle the case of premature termination of the Activity. The name implicates that the Loader specifically is destined for such topics where by access of some (external) resource data has to be loaded. For the case described in this post, specifically the "AsyncTaskLoader<>" is relevant.

Again it will be subclassed with the type of the return value of the loading operation as parameter of the template. The class to use the loader should implement the interface "LoaderManger.LoaderCallbacksy<>" that defines the methods for the callback. Additionally there is defined a "onCreateLoader"
method, that has to instatiate the appropriate Loader - depending on its parameter. The proper instance will always and only be requested via the LoaderManager.

The Loader subclass just has to implement the "loadInBackground" method. Parameters may be propagated to the Loader subclass via the constructor.
Schematically it looks like this:

class FooLoader extends AsyncTaskLoader {
   public FooLoader(Context context, Bundle args) {
      super(context);
      // do some initializations here
   }
   public String loadInBackground() {
      String result = "";
      // ...
      // do long running tasks here
      // ...
      return result;
   }
}

class FooLoaderClient implements LoaderManager.LoaderCallbacks {
   Activity context;
   // to be used for support library:
   // FragmentActivity context2;
   public Loader onCreateLoader(int id, Bundle args) {
      // init loader depending on id
      return new FooLoader(context, args);
   }
   public void onLoadFinished(Loader loader, String data) {
      // ...
      // update UI here
      //
   }
   public void onLoaderReset(Loader loader) {
      // ...
   }
   public void useLoader() {
      Bundle args = new Bundle();
      // ...
      // fill in args
      // ...
      Loader loader = 
         context.getLoaderManager().initLoader(0, args, this);
      // with support library: 
      // Loader loader = 
      //    context2.getSupportLoaderManager().initLoader(0, args, this);
      // call forceLoad() to start processing
      loader.forceLoad();
   }
}


Which one of the possibilities described you choose, depends on the specific context. The Loader mechanism might be inflexible in some cases, since it is intended for loading data specifically. Since it uses a general concept of Android, it will surely get more into focus in the future.

Samstag, 18. Februar 2012

AsyncTask und AsyncTaskLoader

Sobald man größere Anwendungen auf der Android-Plattform entwickelt, wird man relativ schnell feststellen, dass sich das System weigert, besonders laufzeitzeit-intensive Aufgaben im UI-Thread abzuarbeiten. Dazu zählen Zugriffe über das Netzwerk, aber auch auf das Filesystem, auf Preferences oder auf die Datenbank. Abhängig vom API-Level führt das zu einer entsprechenden Meldung („Application not responding“) oder sogar zu einer Exception.

Die entsprechende Aufgabe ist also in einen asynchronen Task auszulagern. Nicht selten wird so eine Aufgabe nach erfolgreicher Abarbeitung aber wieder auf das UI zugreifen müssen, beispielsweise um die Ergebnisse darzustellen. Da von diesem Task nicht wieder auf den UI-Thread zugegriffen werden darf, ist die Synchronisation Teil des Problems.

Die für einen Java-Entwickler vertraute Herangehensweise wäre, einfach einen Java-Thread zu starten. Aus diesem Thread kann allerdings nicht auf die UI zugegriffen werden. Dafür stellt die Android-Activity eine „runOnThread“-Methode zur Verfügung. Dieser wird ein Runnable übergeben, dass die Aufgaben im UI-Thread erledigt. Schematisch würde das so aussehen:


Thread thread = new Thread(new Runnable() {
   public void run() {
      // ...
      // do long running tasks here
      // …

      // running in Activity context
      runOnUiThread(new Runnable() {
         public void run() {
            // ...
            // update UI here
            // ...
         }
      });
   }
});
thread.start();


Ein wenig eleganter und mehr „Android-like“ ist die Verwendung des "AsyncTask<>". Davon wird eine Subklasse gebildet und einige Methoden sind zu implementieren. Über die Template-Parameter werden die Parameter des „doInBackground“-Aufrufs, der Parameter der „onProgressUpdate“-Methode und der Typ des Rückgabewertes für die „onPostExecute“-Methode parametriert. Letztere wird dann im Kontext des UI-Threads aufgerufen.


public void useTask() {
   new FooTask().execute("param1", "param2");
}

class FooTask extends AsyncTask {
   protected String doInBackground(String... params) {
      int progress = 0;
      String result = params.length > 0 ? params[0] : "";
      // ...
      // do long running tasks here
      // ...
      publishProgress(progress);
      // ...
      // work
      // ...
      return result;
   }
   protected void onProgressUpdate(Integer... progress) {
      // ...
      // propagate progress to UI
      //
   }
   protected void onPostExecute(String result) {
      // ...
      // update UI here
      // ...
   }
}


Eine weitere Möglichkeit zur Lösung des Problems würde für die Aufgabe einen speziellen Service implementieren. Die Kommunikation zwischen Service und UI-Thread würde dann allerdings über Intents/BroadcastReceiver erfolgen, was die Implementierung recht komplex und unübersichtlich macht.

Alle diese Vorgehensweisen haben den Nachteil, dass berücksichtigt werden muss, ob die Activity vorzeitig beendet wird. Das kann ja beispielsweise schon durch Drehen des Devices schnell mal der Fall sein. Dann würde die ausgelagerte Aufgabe in ihrem Thread weiterlaufen. Die Verarbeitung der Ergebnisse führt dann schnell zu unerwünschten Ergebnissen.

Ab Android 3.0, API-Level 11 kommt mit dem „Loader“-Konzept eine neue Möglichkeit ins Spiel. Unter Verwendung der V4-Support-Library ist das allerdings auch für frühere API-Level verwendbar. Loader werden von Android durch einen Loader-Manager verwaltet, der beispielsweise auch den erwähnten Fall des vorzeitigen Beendens der Activity berücksichtigen soll. Der Name deutet es bereits an, der Loader ist speziell für solche Fälle vorgesehen, wo durch Zugriff auf (externe) Ressourcen Daten geladen werden sollen. Für den beschriebenen Fall ist speziell der "AsyncTaskLoader<>" interessant.

Es wird wieder eine Subklasse gebildet, mit dem Typ des Returnwertes der Ladeoperation als Parameter des Templates. Die verwendende Klasse sollte das Interface "LoaderManager.LoaderCallbacks<>" implementieren, dass auch die Methoden für den Callback definiert. Außerdem ist dort eine „onCreateLoader“-Methode vorgesehen, über die abhängig von einem Parameter der passende Loader instantiiert werden muss. Die eigentliche Instanz wird nur über den LoaderManager erzeugt.

Der eigentliche Loader muss nur die „loadInBackground“-Methode implementieren. Parameter können der Loader-Klasse über den Konstruktor übergeben werden. Schematisch sieht das dann folgendermaßen aus:


class FooLoader extends AsyncTaskLoader {
   public FooLoader(Context context, Bundle args) {
      super(context);
      // do some initializations here
   }
   public String loadInBackground() {
      String result = "";
      // ...
      // do long running tasks here
      // ...
      return result;
   }
}

class FooLoaderClient implements LoaderManager.LoaderCallbacks {
   Activity context;
   // to be used for support library:
   // FragmentActivity context2;
   public Loader onCreateLoader(int id, Bundle args) {
      // init loader depending on id
      return new FooLoader(context, args);
   }
   public void onLoadFinished(Loader loader, String data) {
      // ...
      // update UI here
      //
   }
   public void onLoaderReset(Loader loader) {
      // ...
   }
   public void useLoader() {
      Bundle args = new Bundle();
      // ...
      // fill in args
      // ...
      Loader loader =
         context.getLoaderManager().initLoader(0, args, this);
      // with support library:
      // Loader loader =
      //    context2.getSupportLoaderManager().initLoader(0, args, this);
      // call forceLoad() to start processing
      loader.forceLoad();
   }
}


Welche der beschriebenen Möglichkeiten gewählt wird, hängt natürlich nicht zuletzt vom jeweiligen Kontext ab. Der Loader-Mechanismus ist in einigen Fällen vielleicht zu unflexibel, da er speziell für das Laden von Daten vorgesehen ist. Da er aber auf einem universellen Konzept von Android aufsetzt, wird er sicherlich zukünftig vermehrt in den Fokus rücken.