Berechtigungen

Damit das Beispiel auch läuft, müssen die erforderlichen Berechtigung gesetzt sein. Aus Sicherheitsgründen erfordert der Zugriff auf Kalenderdaten entsprechende »uses-permission« -Einträge in der Datei »AndroidManifest.xml« . Für reinen Lesezugriff ist die Berechtigung »android.permission.READ_CALENDAR« erforderlich. Falls das Programm den Kalender auch modifizieren soll, braucht es die Berechtigung »android.permission.WRITE_CALENDAR« .

Der Anwender wird beim Herunterladen der App aus dem Market auf die angeforderten Berechtigungen aufmerksam gemacht, fehlen diese, würde die App eine Exception werfen. Des Weiteren sei noch angemerkt, dass Google empfiehlt, den Zugriff auf Content-Provider asynchron zu machen, also nicht im Hauptthread laufen zu lassen. Das erreicht man zum Beispiel mit »AsyncTask« oder noch besser mit Loadern, die seit Version 3.0 Bestandteil von Android sind.

Im Zusammenhang mit Content-Providern stehen auch Erweiterungen der Kontaktdatenbank. Erstmals kann sich der Anwender selbst mittels eines eigenen Profils in der Kontaktapplikation verwalten. Andere Anwendungen dürfen diese Daten auslesen und sogar ändern, vorausgesetzt sie besitzen die dafür erforderlichen Berechtigungen. Das kleine Codebeispiel in Listing 4 nutzt die neue Klasse »ContactsContract.Profile« zum Auslesen der Profil-Informationen.

01 Cursor cursor = resolver.query(Profile.CONTENT_URI, null, null, null, null);
02 DatabaseUtils.dumpCursor(cursor);

P2P mit Wi-Fi Direct

Eine weitere interessante Neuerung in Android 4.0 ist die Unterstützung des Funkstandards Wi-Fi Direct. Damit lassen sich Peer-to-Peer-Verbindungen zwischen Android-Geräten über WLAN aufgebauen. Das funktioniert unabhängig von einer Internetverbindung, einem Server oder Router. Der neue Standard überträgt auch große Datenmengen mit geringer Latenz und über wesentlich weitere Strecken als Bluetooth.

Die zentrale Anlaufstelle des Wi-Fi-Direct-API ist die Klasse »WifiP2pManager« [3] aus dem neuen Package »android.net.wifi.p2p« . Listing 5 setzt eine einfache Klasse namens »MinimalWiFiDirect« um, die mit dem API eine Liste der in Reichweite befindlichen Peers ausgibt. Die »init()« -Methode registriert zunächst die Klasse als »BroadcastReceiver« . Danach muss das Programm Wi-Fi Direct initialisieren. Dazu erzeugt es ein »WifiP2pManager« -Objekt und ruft die Methode »initialize()« auf (Zeile 12). Das zurückgegebene »Channel« -Objekt dient als Handle für weitere API-Aufrufe.

01 public class MinimalWiFiDirect extends BroadcastReceiver implements PeerListListener {
02
03     private WifiP2pManager manager;
04     private Channel channel;
05
06     public void init(Context context) {
07         IntentFilter intentFilter = new IntentFilter();
08         intentFilter.addAction(WifiP2pManager.WIFI_P2P_PEERS_CHANGED_ACTION);
09         context.registerReceiver(this, intentFilter);
10
11         manager = (WifiP2pManager) context.getSystemService(Context.WIFI_P2P_SERVICE);
12         channel = manager.initialize(context, context.getMainLooper(), null);
13         manager.discoverPeers(channel, null);
14         Log.i("My", "Warte auf Wi-Fi Direct Broadcasts...");
15     }
16
17     @Override
18     public void onReceive(Context context, Intent intent) {
19         String action = intent.getAction();
20         if (WifiP2pManager.WIFI_P2P_PEERS_CHANGED_ACTION.equals(action)) {
21             Log.i("My", "Wi-Fi Direct Peers haben sich veraendert");
22             manager.requestPeers(channel, this);
23         }
24     }
25
26     @Override
27     public void onPeersAvailable(WifiP2pDeviceList wifiP2pDeviceList) {
28         Collection<WifiP2pDevice> deviceList = wifiP2pDeviceList.getDeviceList();
29         for (WifiP2pDevice device : deviceList) {
30             Log.i("My", "Wi-Fi Direct Device: " + device.deviceName + ", " + device.deviceAddress);
31         }
32     }
33 }

In Zeile 13 startet »discoverPeers()« die Suche nach Geräten, die sich in Reichweite befinden. Da dies asynchron passiert, empfiehlt es sich, einen »ActionListener« als zweiten Parameter zu übergeben, auf den das Beispiel aber aus Platzgründen verzichtet. Der Listener besteht aus zwei Callback-Methoden, von denen nur eine aufgerufen wird, je nachdem, ob die Suche erfolgreich gestartet ist (»onSuccess« ) oder nicht (»onFailure« ).

Zum Zeitpunkt des Callback ist der Suchvorgang erst gestartet, auf das Ergebnis muss das Programm also anders reagieren. Hier kommt der »BroadcastListener« ins Spiel. Einer der vom System abgeschickten Broadcasts ist »WIFI_P2P_PEERS_CHANGED_ACTION« , er gibt an, dass sich die Liste der gefundenen Geräte geändert hat. In der zum »BroadcastReceiver« gehörenden Methode »onReceive« prüft die App, ob es sich um den entsprechenden Broadcast handelt.

Aber auch damit ist die Aufgabe noch nicht ganz erledigt. Erst nach dem Aufruf von »requestPeers()« wird die Klasse über das Interface »PeerListListener« asynchron aufgerufen. Dieser Listener besteht aus der Methode »onPeersAvailable()« , welche die Beispielklasse direkt implementiert. Nun kann das Programm endlich auf die Liste der verfügbaren Geräte zugreifen.