Wie schon angeschlagen im letzten Post, heute geht es um die ListView Optimierung in Android. In einem sehr interessanten Webcast von Google I/O 2010 gab es schon einiges sehr sinnvolles zu ListViews und auch wieder einiges was ich dazu gelernt habe.

Für alle die es interessiert: The World of ListView

Hier noch das Tutorial bzw. HowTo zu dem Video. Wozu ViewHandler gebraucht werden und wie man Speicherschonend die ListViews befüllt. Anschließend noch ein kleiner Ausschnitt wie man ListViews aktualisiert mit notifyDataSetChanged().

Ich gehe davon aus das jeder weiß wie man eine ListView in der Layout.xml definiert, daher fangen wir sofort an mit der implementierung der View im Code.

Step 1

ListView in der Activity aufrufen.

import java.util.ArrayList;
import java.util.ArrayList;
import java.util.List;

import android.app.Activity;
import android.content.Context;
import android.os.Bundle;
import android.os.Handler;
import android.widget.ListView;

public class ListActivity extends Activity {

	private Context ctx;
	private ListView liste;
	private ListeItemAdapter adapter;

	@Override
	protected void onCreate(Bundle savedInstanceState) {
		super.onCreate(savedInstanceState);

		setContentView(R.layout.liste);
		this.ctx = this;

		Listitems = new ArrayList();
		for(int i=0;i<100;i++) {
			items.add(new ListeItemAdapter().randomText);
		}

		adapter = new ListeItemAdapter(this, R.layout.liste_item, items);
		liste = (ListView) findViewById(R.id.liste);
		liste.setAdapter(adapter);
	}
}

Der Adapter und somit das Herzstück des Tutorials. Wie definiere ich einen ViewHolder zum speichern der statischen Views für eine sinnvolle Speicherwiedernutzung.

import java.util.List;
import java.util.Random;

import android.content.Context;
import android.view.LayoutInflater;
import android.view.View;
import android.view.ViewGroup;
import android.widget.BaseAdapter;
import android.widget.ImageView;
import android.widget.TextView;

public class ListeItemAdapter extends BaseAdapter {

	private Context ctx;
	private int rowResID;
	private List itemList;
	private LayoutInflater layoutInflater;
	public String randomText = myRandomText();

	private static class ViewHolder {
		public static TextView text1;
		public static TextView text2;
		public static TextView text3;
		public static ImageView status;
	}

	public ListeItemAdapter() { }

	public ListeItemAdapter(final Context ctx, final int rowResID, final List itemList) {
		this.ctx = ctx;
		this.rowResID = rowResID;
		this.itemList = itemList; 

		layoutInflater = (LayoutInflater) ctx.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
	}

	public int getCount() {
		return this.itemList.size();
	}

	public Object getItem(int position) {
		return this.itemList.get(position);
	}

	public long getItemId(int position) {
		// TODO Auto-generated method stub
		return position;
	}

	public void setItemList(List itemList) {
		this.itemList = itemList;
	}

	public View getView(int position, View v, ViewGroup vg) {
		ViewHolder holder;

		// prüfen ob eine view bereits existiert
		if(v == null || v.getTag() == null) {
			holder = new ViewHolder();
			v = layoutInflater.inflate(rowResID, null); // inflate the item layout!
			holder.text1 = (TextView) v.findViewById(R.id.text1);
			holder.text2 = (TextView)v.findViewById(R.id.text2);
			holder.text3 = (TextView)v.findViewById(R.id.text3);
			holder.status = (ImageView) v.findViewById(R.id.status);
			v.setTag(holder); // viewholder setzen
		} else {
		// laden der Views über den ViewHolder
			holder = (ViewHolder) v.getTag();
		}

		// get item value
		String item = itemList.get(position);

		// Views füllen
		holder.text1.setText(item);
		holder.text2.setText(myRandomText());
		holder.text3.setText(myRandomText());
		holder.status.setImageResource(myRandomImage());

        return v;
	}

	/**
	 * get random String value
	 * @return String
	 */
	public String myRandomText() {
		String[] values = new String[] { "Hase","Hund","Katze","Maus","Schwein","Pferd","Esel","Kuh","Henne","Hahn","Vogel","Affe","Giraffe","Schlange" };
		Random generator = new Random();
		return values[generator.nextInt(values.length)];
	}
	/**
	 * get random Image Resource
	 * @return int
	 */
	private int myRandomImage() {
		int[] values = new int[] { R.drawable.tick_green_00, R.drawable.tick_green_01, R.drawable.tick_green_02, R.drawable.tick_green_03 };
		Random generator = new Random();
		return values[generator.nextInt(values.length)];
	}

}

Somit wäre eigentlich alles geklärt. Es ist fast selbst beschreibend für die, die sich schon mit ListViews auseinander gesetzt haben.
Wir werden jetzt mit einem Handler in der MainActivity noch ein delayed Handler aufrufen indem wir die Werte der Listview ändern.
Hier die veränderte Activity.

PART 2

Step1

import java.util.ArrayList;
import java.util.List;

import android.app.Activity;
import android.content.Context;
import android.os.Bundle;
import android.os.Handler;
import android.widget.ListView;

public class ListActivity extends Activity {

	private Context ctx;
	private ListView liste;
	private ListeItemAdapter adapter;
	private Handler handler;

	@Override
	protected void onCreate(Bundle savedInstanceState) {
		super.onCreate(savedInstanceState);

		setContentView(R.layout.liste);
		this.ctx = this;
		handler = new Handler();

		Listitems = new ArrayList();
		for(int i=0;i<100;i++) {
			items.add(new ListeItemAdapter().randomText);
		}

		adapter = new ListeItemAdapter(this, R.layout.liste_item, items);
		liste = (ListView) findViewById(R.id.liste);
		liste.setAdapter(adapter);

		Thread updateListViewThread = new Thread() {
			@Override
			public void run() {
				super.run();

				final Listitems = new ArrayList();
				for(int i=0;i<100;i++) {
					items.add(new ListeItemAdapter().randomText);
				}

				handler.postDelayed(new Runnable() {
					@Override
					public void run() {
						adapter.setItemList(items);
						adapter.notifyDataSetChanged();
					}
				}, 5000);

			}
		};
		updateListViewThread.start();

	}

}

AIDL Prozesse oder Services sind Schnittstellen zur Kommunikation und Automatisierung außerhalb der App. Wenn deine App für Widgets oder auch für länger laufende Prozesse einiges an Ressourcen benötigt und vor allem auch nach dem schließen der Applikation weiter arbeiten soll. z.B. Streamen von Musik oder Aktualisieren von Daten bei Newsfeed’s etc. sind sogenannte Remote Services sinnvoll.

Remoteservices werden mit einer .aidl file spezifiziert, dieses beinhaltet eine Interfaceklasse die die Struktur des späteren Services erzeugt. Vieles zur Kommunikation mit dem System erzeugt Eclipse wieder von alleine, um das wir uns nicht kümmern müssen. Einmal verstanden ist es halb so schwer.

Mein Mainpackage z.B. de.jkoeber.testapp darin erstelle ich eine .aidl file mit dem Namen MyRemoteService.aidl

package de.jkoeber.testapp;/** service interface */
interface MyRemoteService{
void startUpate();
void stopUpdate();
boolean isUpdating();
}

Aus dieser AIDL File erstellt der Builder von Eclipse in den Ordner gen die Java Klasse zur Kommunikation mit dem Systemen.

Im nächsten Step registrieren wir den Service in der App. Andernfalls kann das ganze Programm nicht mit der File umgehen. Also fügen wir z.B. folgendes in die AndroidManifest.xml ein.

Jetzt zur Erklärung. Ein Remoteservice wird über die Interfacefile erzeugt. Dem Remoteservice hängt aber eine Klasse an, die die angegebenen Funktionen im Interface ausführt. das wäre dann in der Zeile: android:name=”.remoteservices.MyRemoteService” Das heißt, ich hab ein neues Packages erstellt das .remoteservices heißt und hab darin die Klasse MyRemoteService erzeugt. Per Intent Filter wird anschließend die Interface .aidl Datei angegeben.

Jetzt erzeugen wir noch die Klasse zur AIDL. Es ist wie bei jedem Interface, das es einer Klasse zu Grunde liegt.

package de.jkoeber.testapp.remoteservices;

import java.util.ArrayList;
import java.util.List;

import de.jkoeber.testapp.MyRemoteService;

public class MyRemoteService extends Service {
    private Handler handler = new Handler();

    @Override
    public void onCreate() {
        super.onCreate();
        ctx= this;
    }

    @Override
    public IBinder onBind(Intent intent) {
        // Return the interface
        return mBinder;
    }

    private final MyRemoteService.Stub mBinder = new MyRemoteService.Stub() {
		@Override
		public void startUpate() throws RemoteException {
		    // start update
		}

		/**
		 * stop updating service
		 */
		@Override
		public void stopUpdate() throws RemoteException {
                    // stop service
		}

		/**
		 * check if update is running
		 */
		@Override
		public boolean isUpdating() throws RemoteException {
                   // check if service is running
                }
    };

}

Wer den Fehler: unknown option: – please use -help for a list of valid options steht erstmal vor einem Rätsel. Es ist aber ziemlich einfach. Da Android eher von Google kommt und damit auch eher die Unix und Mac Programmierer ansprechen will stellt man sich dem dummen Windows Nutzer quer und baut schnell mal seinen AVD Manager um.

Seit der aktuelle Version des SDK und AVD Managers ist es nicht mehr gestattet mit Leerstellen im Pfad zum AVD Manager zu arbeiten.
Wer voher einen ähnlichen Pfad wie ich hatte mit Leerstelle. zum Beispiel: c:\Program Files\Android\SDK-Manager\ wird jetzt ziemlich schnell enttäuscht und man erhält den Fehler: unknown option: – please use -help for a list of valid options

Typischerweise gibt es kein Logging und somit beginnt eine dreitägige Tour der Suche in den endlosen Weiten der Updates und Reinstallationen um einen solch banalen Fehler zu finden. Für alle anderen die den Fehler auch haben und sich Emulatoren nicht mehr vernünftig starten lassen. Ladet euren SDK Manager in ein Verzeichnis ohne Leerstellen: c:\android\sdk-manager\ und schon funktoiniert es wie gehabt.

Heute geht es um die Orientation im Android. Alle oder so gut wie alle aktuellen Smartphonehandys haben einen Sensor um die Ausrichtung des Handybildschirms zu bestimmen. Landscape oder Portrait heißen diese 2 Varianten. Mit diesen beiden Möglichkeiten lässt sich viel anstellen. Man kann seine Apps den größen der Monitore etc. anpassen. Eine super Sache. Aber wie stelle ich am geschicktesten die Orientation fest um vernünftig meine Programmdaten zu übergeben.

Eines ist mir aufgefallen. Pads und Handys sind zwei paar Schuhe, das aber auch die Hersteller an sich nicht an die Standards halten finde ich unverschämt. So gibt das Acer Iconia Tab andere Daten als das HTC Desire HD zurück um seine Orientation Punkte zu merken. Zur Erinnerung in der Google bzw. Android Dokumentation:

“unspecified“	The default value. The system chooses the orientation. The policy it uses, and therefore the choices made in specific contexts, may differ from device to device.
“landscape“	Landscape orientation (the display is wider than it is tall).
“portrait“	Portrait orientation (the display is taller than it is wide).
“user“	The user’s current preferred orientation.
“behind“	The same orientation as the activity that’s immediately beneath it in the activity stack.
“sensor“	The orientation determined by a physical orientation sensor. The orientation of the display depends on how the user is holding the device; it changes when the user rotates the device.
“nosensor“	An orientation determined without reference to a physical orientation sensor. The sensor is ignored, so the display will not rotate based on how the user moves the device. Except for this distinction, the system chooses the orientation using the same policy as for the “unspecified” setting.

Jeder der einzelnen Werte wird über eindeute Integer zugeordnet. Aber bei Herstellern, wie ich feststellen musste gibt es diesen Standard nicht und sie übergeben was sie wollen. Im normalen Verfahren, kann man die Position bzw. Orientierung des Displays mit diesem Befehl feststellen und dem entsprechen darauf reagieren:

 Display display = ((WindowManager) getSystemService(WINDOW_SERVICE)).getDefaultDisplay();
 int orientation = display.getOrientation();

Anschließend könnte man den übergebenen Wert per ActivityInfo verlgeichen und den dementsprechenden Content laden. Zum Beispiel so:

switch (orientation) {
  case ActivityInfo.SCREEN_ORIENTATION_LANDSCAPE:
      ... do anything ...
  break;
  case ActivityInfo.SCREEN_ORIENTATION_PORTRAIT:
      ... do anything else ...
  break;
}

Aber das funktioniert nur bedingt. Für Tablet, z.B. dem Iconia von Acer gilt der Landscape und Portrait Bereich nicht, da Acer als Tab sich den Portrait Bereich im Querformat vorstellt und somit die Variable für Landscape und Portrait vertauscht. Somit bekommt man ein 0 für Landscape und 1 für Portrait was nicht sein dürfte.
Für mich ist der Landscape Modus das Querformat des Monitors und nicht die Hochkanvariante. Somit prüfe ich folgendes ab:

setContentView(R.layout.demo) // Für alle Ansichten muss der selbe Name verwendet werden
LinearLayout contentLand = (LinearLayout) findViewId(R.id.content);
LinearLayout contentPortrait = (LinearLayout) findViewId(R.id.content);

if(contentLand != null) { // check if Orientation == Landscape
  ... do whatever u want ...
} else if(contentPortrait != null ) { // check if Orientation == Portrait
  ... do whatever u want ...
}

Mein Beispiel ist kurz und knapp, ich verwende keine Mühe mehr daran den Sensor zu ermitteln wie er gerade steht sondern überlass es dem System. Ich prüfe lediglich ab welche View existiert und arbeite damit weiter. Wenn die jeweilige View ansprechbar ist bzw. in meinem Fall not null erhalte ich das selbe, für mich sogar bessere Ergebnis als wenn ich umständlich mit den Orientation Funktionen arbeite.

Ich hoffe es hilf einigen von euch die sich damit erst beschäftigen werden.

Seit knapp einer woche bin ich stolzer Besitzer eines Iconia w500 Tablets. Im großen und ganzen bin ich damit zufrieden. Ich habe ein paar Testberichte gelesen in denen das Iconia besser bewertet wurde als das Xoom von Motorola. Leider habe ich nicht den direkten Vergleich. Von der Hardware nehmen sich die Hersteller nicht viel. Auch das Iconia gibt es mitv3g Modul.

Zur Android Version
Vorhanden ist eine Android 3.0.1 Version, die kommenden Mittwoch auf Android 3.1 geupgradet werden kann. Das Vorinstallierte Acer Themen ist gut gelungen und alles ancseinem Platz. Aber auch ein paar kleine Nachteile gibt es, was man Acer aber nicht in die Schuhe schieben kann. Beim installieren von Apps kann es vorkommen das sich der Marktplace verabschiedet.

Hardware
Dem Iconia ist eine hohe Aulösung von über 1000Pixeln gegen worden. Ein großer Pluspunkt.   Viele Seiten können somit ohne zoom gelesen werden. Ein USB Anschluss für eine zusätzliche Tastaur ist auch vorhanden. Sehr schön. Was mich aber atört ist ein kleiner Verarbeitungsfehler am Display.  Durch die Anschlussmöglichkeit der Acer Docking ist ein zusätzlicher Slot integriert hinter dem anscheinend ein Chip eingebaut ist. Daher wird das Display auf der Seite um einen Millimeter nach oben gedrückt und somit eine unschöne Kante am unteren Ende sichtbar und fühlbar.

Wenn mir noch was einfällt und ich noch etwas Zeit habe werde ich den Beitrag ergänzen.

Ich schau mir gerade die Google I/O Podcast über Youtube an und muss sagen, das ich recht begeistert bin. Verkaufszahlen und Aktivierungen von Android Geräten, natürlich sehr spektakulär aufgemacht aber auch gute Zahlen. Über 100 Millionen aktivierte Geräte mit dem beliebten OS. Viele neue Pläne und Features werden vorgestellt. Ein kleiner Ausschnitt:

- 3D und Camera z.B. Automatisiertes visieren des Sprecher über Videotelefonie

-  Google TV bekommt den Android Market

- Es können, wie auch schon im Appstore möglich direkt über den Store Videos gemietet werden

- Google Music (sehr interresant)

Ich werde mir jetzt die restlichen Stunden Google I/O reinziehen, morgen wieder zu spät auf Arbeit aufkreuzen aber dafür umso mehr Wissen und Ideen mit ins Bett nehmen die ich mir im Schlaf doch alle mal durchdenken kann. Wozu ist auch sonst die Nacht gut… Dann Allen einen schönen Abend und bis Morgen!

Für alle anderen die schon mal vom Android Desire HD per App2SD oder auch über die Anwendungsverwaltung Apps auf die SD Karte verschoben haben und anschließend überraschend feststellen mussten das sich die Apps nicht mehr Updaten lassen gibt es hier die Lösung.

HTC hat anscheinend in der HD Variante des Desire eine kleine Sperre auf die SD Karte eingebaut das man nicht so einfach die Apps updaten kann wie man mag sobald diese auf der SD Karte gespeichert werden.

• Verbinden des Handys mit eurem PC per USB Kabel, anschließend wählt Ihr Festplatte als Verbindungseinstellung
• Öffnet den Explorer und geht in den Ordner .android_secure
• Hier befindet sich eine File mit dem Namen: smdl2tmp1.asec
• Bennent diese File um oder löscht sie und schön könnt ihr Updates und Installationen auf der SD Karte tätigen

Mir ist dieser kleine Trick sehr hilfreich gewesen bei der Installation eines kleinen Spiels das unbedingt auf die SD Karte speichern wollte.

Schon lang lang ist es her. Noch zur Affäre von zu Guttenberg hatte ich Zeit einen kurzen Blogeintrag zu verfassen und jetzt stecke ich von Kopf bis Fuß in einem neuen Projekt. Es wird ein Mobile Projekt und hierbei habe ich wieder viel lernen können.

Deshalb habe ich mich entschlossen mein neues angelerntes Wissen nicht für mich zu behalten und will euch das ein oder andere Tutorial noch schreiben. Aber vorerst eine Kurse Übersicht was es geben wird.

• Manipulation Tabbar und Positionierung
• Zugriff auf Parent Objekte
• Threads und Handler
• Manipulation von Progressbar für Horizontale Ansicht
• Bilder nachladen

Ich werde in den kommenden Tagen die Tutorials online stellen und auch auf diesem “Artikel” verlinken. Aber zuerst einmal noch einen schönen Abend und bis demnächst.

Es gibt zig Einträge in Foren oder Blogs. Stellenanzeigen und Leistungsübersichten in denen ich immer wieder von Migrationen lese.
Dabei habe ich mir selbst die Frage gestellt ob es Sinn macht und auch gut ist Apps von iOS auf Android im 1to1 Verfahren zu kopieren.
Meine eindeutige Antwort darauf ist: nein.
Der Ansatz von Android und IPhone ist verschieden. Sowohl was die wählbaren Tasten angeht bis hin zu den Touchevents die man auslesen kann.
Ich kenne kein iPhone App das mir ein Contextmenu (längerer Druck auf ein Item) ermöglicht. Aber ich kenne auch nur wenige Android Apps die wirklich die iPhone-Bottom-Menustruktur imitieren. Was, für mein Verständnis eine totale Themaverfehlung wäre, wenn ein Android Entwickler diese Menuform extra einprogrammiert.

Warum macht eine Direktkopie Sinn? Es gibt nur eine Ausrede, die Kosten. Entwicklungszeit kostet Geld und Menschen die gut darin sind lassen es sich gut bezahlen. Daher kostet eine Neuentwicklung mehr Geld als die Kopie.

Vorteile der angepassten App zum jeweiligen System sind ganz klar. Passende Grafiken, es gibt doch fast nichts schlimmeres als wenn die Grafiken aussehen wie Kraut und Rüben. Neben zusätzlichen Features. Auf dem Android zum Beispiel die Integration von Widgets. Angepasste Menüs und Suchfunktionen. Auch Fehleranalysen und Debugging spielen dabei die ein oder andere Rolle.

Fazit: Für mich persönlich macht es wenig Sinn echte Applikationen, ich rede nicht von Spielen einer Kopiermaßnahme zu unterziehen und damit eine identische Version auf mehreren total unterschiedlichsten Systemen zu publizieren.

Immer wenn ich eine Ratingbar anlege ist dies zu groß. In der Landscape- Ansicht würde es funktionieren und der Nutzer ohne Probleme das Rating vornehmen können, um aber das Rating sinnvoll auf ein standard Portrait View zu erzeugen muss ich einen Umweg gehen. RatingBar Items können wir 3 verschiedene Zustände zuordnen.

larger indicator-only    -    style=”?android:attr/ratingBarStyleIndicator”
smaller RatingBar     -    style=”?android:attr/ratingBarStyleSmall”
Default            -    style=”?android:attr/ratingBarStyle”

Jeder dieser Zustände hat seine Eigenschaften. Zum Beispiel können bei lager indicator als auch bei der smaller RatingBar keine Werte direkt vergeben werden. Das heißt der Nutzer kann hier keine Interaktion mit der RatingBar eingehen. In der Default Variante kann es zu Layoutschwierigkeiten kommen. Wie auch in meinem Fall.

Folgender Fehler habe ich nun gefunden, der im Simulator ohne Probleme läuft. Das Rendern der Stars wird nicht korrekt vorgenommen solange man nicht eine Anpassung in der Manifest.xml macht. Erst nach ändern der XML wurden die Ratingsterne richtig dargestellt.

<supports-screens android:smallScreens="true" android:normalScreens="true" android:largeScreens="true" android:anyDensity="true" />

<uses-sdk android:minSdkVersion="3" android:targetSdkVersion="4" />