I, Beacon

iBeacon-Apps auf Android mit dem Estimote SDK

Wolfgang Werner

© Shutterstock / ra2studio

Mögliche Anwendungsfälle und Geschäftsmodelle für Technologien, die standortabhängige Benutzerinteraktion auch im Inneren von Gebäuden ermöglichen, werden derzeit heiß diskutiert. In-Store-Advertising und Rabatte, Mobile-Payments, Navigation, ÖPNV, Lokalisierung in öffentlichen Gebäuden und Museen und Home Automation sind nur die Spitze des Eisbergs, und natürlich das allgegenwärtige Sammeln von Daten – jetzt neu und mit genauer Ortsangabe. Was steckt hinter dem Hype?

Das von Apple entwickelte iBeacon-Protokoll auf Basis von Bluetooth Low Energy wird von einer Vielzahl von Devices unterstützt. Der Artikel erklärt iBeacons und Bluetooth Low Energy und zeigt am Beispiel der Entwicklung einer Android-App für standortabhängige Einkaufslisten die standortabhängige Interaktion einer App mit iBeacons. Die Implementierung basiert auf Estimote Beacons und dem dazugehörigen SDK.

iBeacon, Bluetooth 4.0, BLE, SMART. Wot?

Die Basistechnologie für iBeacon ist Bluetooth. Bluetooth Low Energy (BLE), das häufig auch mit dem Marketinglabel Bluetooth Smart bezeichnet wird, wurde in Version 4.0 des Bluetoothstandards aufgenommen. BLE ist nicht rückwärtskompatibel mit vorhergegangenen Versionen, die als Bluetooth Classic bezeichnet werden. Bluetooth 4.0 spezifiziert, dass standardkonforme Devices eine der beiden oder beide Varianten, also Low Energy oder Classic, implementieren müssen.

BLE ist auf nahezu allen aktuellen Smartphones wie dem iPhone 4+ und dem Samsung Galaxy 3+ implementiert. Ein iPhone kann sowohl als Empfänger von iBeacon-Signalen als auch – im Gegensatz zu Android – als Beacon selbst fungieren. In Android sind BLE-Treiber ab API-Version 18, also Android 4.3 enthalten. Auch aktuelle Computer sind übrigens BLE-fähig. In Windows sind die Treiber allerdings erst ab Windows 8 an Bord und seit etwa Mitte 2011 ist BLE auf Apple-Rechnern verfügbar.

BLE unterstützt weiterhin eine Vielzahl von Peripheriegeräten wie Herzfrequenzmessgeräte und Spielzeughelikopter, Thermometer, Fitnessgeräte und Zahnbürsten, ja, Zahnbürsten und Turnschuhe.

Interessant im Zusammenhang mit iBeacons ist der SensorTag von Texas Instruments, der neben seiner Funktion als iBeacon noch Temperatur, Luftfeuchtigkeit, Druck und Beschleunigung messen kann. Zusätzlich bringt der SensorTag noch ein Gyroskop, ein Magnetometer und zwei Hardwarebuttons mit. Das ideale Gerät, um Präsentationen fernzusteuern und dabei die Feuchtigkeit und Temperatur der Hände des Referenten zu übertragen und anzuzeigen. Ich denke, dass mein nächstes Sandkastenprojekt ein Lampenfieber-O-Mat werden wird. Eine ausführliche Liste von Devices finden Sie auf der offiziellen Bluetooth-Seite.

GATT ready

Das Kommunikationsmodell, über das Devices Daten austauschen, heißt GATT – Generic Attribute Profile. GATT definiert die Rollen Client und Server. Der Client fordert Daten vom Server über Services an. Ein Service gruppiert mehrere atomare Schlüssel-/Wert-Paare, die als Characteristics bezeichnet werden. Sowohl Services als auch Characteristics werden über UUIDs identifiziert und können zusätzlich weitere Beschreibungen enthalten (Abb. 1). Services und ihre Characteristics sind in Form von Profilen katalogisiert; die Spezifikation definiert davon eine ganze Reihe aus den Bereichen Healthcare, Sport und Fitness und – in unserem Fall interessant – Proximity Sensing. Die einzelnen Profile und ihre Services und Characteristics sind im Bluetoothentwicklerportal unter GATT Specifications zu finden.

Abb. 1: GATT – schematische Übersicht

Abb. 1: GATT – schematische Übersicht

Ran an den b(e)acon

Was also sind iBeacons? iBeacon ist eine sehr einfache Technologie (und ein Trademark von Apple, die standortabhängige Interaktion mit Applikationen ermöglicht. Ein Beacon (engl. Leuchtfeuer) sendet dabei ein Signal aus, das mit BLE-fähigen Geräten empfangen und von darauf installierten Applikationen verarbeitet werden kann. Das Signal enthält die Identifikation des Beacons und die Empfangsstärke. iBeacons selbst sind damit also – entgegen ungenauen Aussagen in der Presse – nicht fähig, Inhalte auszuliefern oder Kundenverhalten nachzuverfolgen. Das liegt in der Verantwortung der empfangenden Applikationen und damit bei uns Entwicklern.

iBeacon IRL

Größere Deployments von iBeacons in Deutschland werden wohl noch auf sich warten lassen, jedoch gibt es einige Beispiele aus den USA und auch den Niederlanden. So beispielsweise hat die Major League Baseball 28 Stadien mit iBeacons ausgestattet und nutzt diese unter anderem für Check-ins in der MLB-App „At the Ballpark“.

Im Rubens-Haus in Antwerpen wurde ein Showcase implementiert, der Hintergrundinformationen wie Röntgenaufnahmen von Gemälden und Geocaching-Spiele für Besucher anbietet.

Das Paradebeispiel in Sachen Größe kommt von Apple selbst. Über 250 Apple Stores wurden mit iBeacons ausgestattet. In Kombination mit der Apple-Store-App werden standortabhängige Nachrichten an Einkäufer gesendet, die sich im Laden befinden. Allerdings scheinen die möglichen Interaktionen derzeit noch recht beschränkt zu sein: Erste Reviews berichten von nur zwei unterschiedlichen (und recht generischen) Nachrichten, die sie erhalten hätten. Sonderangebote oder spezifische Informationen zu einzelnen Produkten in der Nähe wurden nicht angeboten.

Funktionsweise

iBeacon verwendet kein separates BLE-Profil, sondern Bluetooth-Advertising-Pakete, also Broadcast-Pakete, die zur Entdeckung von Bluetoothdevices genutzt werden. Wenn Sie der genaue Aufbau des Pakets interessiert, können Sie das zum Beispiel im Blog von Adam Warski nachlesen.

Ein solches Paket wird in regelmäßigen, über GATT konfigurierbaren Intervallen versendet. Es enthält die UUID des Beacons, die typischerweise vom Hersteller vorkonfiguriert ist. So senden alle Beacons von Estimote die gleiche UUID. Für die Identifikation des einzelnen Beacons werden zusätzlich Major- und Minor-IDs verwendet. Dabei können Major-IDs beispielsweise eine Filiale eines Ladens oder ein Restaurant einer Franchisekette darstellen, die Minor-IDs ein einzelnes Regal oder einen Tisch.

Weiterhin ist die Signalstärke im Advertisingpaket enthalten, anhand derer die Entfernung des Empfängers zum Beacon gemessen werden kann. Hohe Genauigkeit können Sie hier aber nicht erwarten, da das Signal durch räumliche Hindernisse wie Möbel oder Personen behindert werden kann.

Zur Interaktion einer App mit dieser Information bietet iBeacon zwei Konzepte: Ranging und Region Monitoring. Beim Ranging wird die Entfernung zum Beacon ermittelt. Aufgrund der oben genannten Ungenauigkeit erfolgt das in lediglich drei Stufen. „Immediate“ ist eine Entfernung von wenigen Zentimetern, „Near“ entspricht wenigen Metern und „Far“ ist eine Entfernung von über zehn Metern. Ranging ist nur möglich, wenn die empfangende App aktiv ist.

Das ist beim Region Monitoring nicht notwendig. In diesem Modus kann auch eine inaktive App beim Eintritt oder dem Verlassen einer durch ein oder mehrere Beacons definierten Region notifiziert werden. Spätestens jetzt wird klar, was diese Technologie für Werbung und den Einzelhandel attraktiv macht. Zusätzlich können bei den meisten Beacons die Sendestärke und das Intervall konfiguriert werden, um die Batterielebensdauer auf die lokalen Gegebenheiten hin zu optimieren.

„Die meisten Beacons“ impliziert, dass es mehr als nur einen Hersteller von iBeacons am Markt gibt. Tatsächlich gibt es eine ganze Reihe: Kontakt.io, Gelo, Estimote und Gimbal by Qualcomm sind wohl die Bekanntesten. Diese Hersteller bieten neben der Hardware auch SDKs und Cloud-Lösungen für das Management von Beacons an. Die Bastler unter uns können mit relativ wenig Aufwand mit Raspberry Pi oder Arduino selbst iBeacon-Transmitter aufbauen.

Die Beispiel-App nutzt Beacons und SDK von Estimote (Abb. 2 und Abb. 3). Das ist jedoch keine Aussage über Qualität im Vergleich zum Wettbewerb, sondern allein der Tatsache geschuldet, dass der Autor ein entsprechendes Preview Developer Kit in die Finger bekam.

Abb. 2: Estimote Beacons (mit freundlicher Genehmigung von Estimote)

Abb. 2: Estimote Beacons (mit freundlicher Genehmigung von Estimote)

Abb. 3: Innenleben eines Estimote Beacons (mit freundlicher Genehmigung von Estimote)

Abb. 3: Innenleben eines Estimote Beacons (mit freundlicher Genehmigung von Estimote)

Blinkenlist

Lassen Sie uns für das Implementierungsbeispiel folgende Situation annehmen: Der Entwickler steht am Samstagvormittag im Supermarkt. Zuhause warten hungrige Kinder und am Nachmittag steht ein Bake Sale in der Schule an. Erst danach wird das Wochenende wirklich anfangen. Gute Gründe also, um sich zu beeilen. Leider ist die Einkaufsliste lang und nicht dem Layout des Supermarkts angepasst. Wäre der Supermarkt mit iBeacons in den verschiedenen Abteilungen ausgestattet, könnte eine Einkaufslisten-App die passenden Einträge hervorheben und den Stresslevel des (natürlich völlig fiktionalen) Entwicklers deutlich senken [1].

Da unsere App mit Bluetooth kommunizieren muss, verlangen wir zunächst im Android-Manifest die Berechtigungen BLUETOOTH und BLUETOOTH_ADMIN (Listing 1). Um den vom Estimote-API angebotenen Service zur Interaktion mit iBeacons nutzen zu können, müssen wir auch diesen bekannt machen und das heruntergeladene API in unserem libs/-Verzeichnis ablegen.

<uses-permission android:name="android.permission.BLUETOOTH" />
  <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />

  <service
    android:name="com.estimote.sdk.service.BeaconService"
    android:exported="false" />

Unser Prototyp besteht aus einer einfachen, vorab befüllten Liste und vordefinierten Regionen [2], sprich Abteilungen in unserem Supermarkt. Ein Listeneintrag weiß dabei, welcher Region er zugeordnet ist. In unserem Beispiel ordnen wir jeder Region nur ein Beacon zu. Es ist aber auch möglich, eine Liste von Beacons zu einer Region zusammenzufassen. Die Main Activity ist für das Erkennen der aktuellen Region verantwortlich und gibt diese Information an einen Adapter weiter, der für die Hervorhebung der Listeneinträge verantwortlich ist. Zusätzlich bauen wir noch die Möglichkeit ein, die aktive Region ohne Beacons auszuwählen, um unser UI auch ohne zusätzliche Hardware testbar zu machen.

In der Methode onCreate() der Activity instanziieren wir einen BeaconManager aus Estimote für unsere App. Diesem setzen wir einen Listener für das Region Monitoring, indem wir unserem Adapter die aktuelle Region bekanntmachen und das Intervall für die Beacon-Scans definieren. Im Beispiel definieren wir, dass eine Sekunde gescannt und dann 250 ms gewartet werden soll. Diese Werte sind relativ aggressiv gewählt, um bei Tests schnelle Ergebnisse zu bekommen. In der Realität ist die schwierige Abwägung von Responsiveness vs. Battery Life zu treffen. Außerdem befüllen wir in diesem Prototyp unsere Einkaufsliste mit Dummywerten. In der onStart() bzw. onStop()Methode der Main Activity starten oder stoppen wir das Monitoring.

  private static final String ESTIMOTE_PROXIMITY_UUID = "B9407F30-F5F8-466E-AFF9-25556B57FE6D";
  public static final Region REGION_NONE = new Region("<nicht erkannt>",
      ESTIMOTE_PROXIMITY_UUID, 999, 999);

  private static final Region REGION_BEER = new Region("Bier",
      ESTIMOTE_PROXIMITY_UUID, 2, 1);
  private static final Region REGION_SWEETS = new Region("Süßkram",
      ESTIMOTE_PROXIMITY_UUID, 3, 1);
  private static final Region REGION_VEG = new Region("Gemüse",
      ESTIMOTE_PROXIMITY_UUID, 1, 1);

  // member fields omitted

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

    beaconManager = new BeaconManager(this);
    beaconManager.setBackgroundScanPeriod(1000, 250);
    beaconManager.setMonitoringListener(new MonitoringListener() {
      @Override
      public void onEnteredRegion(com.estimote.sdk.Region region, java.util.List<com.estimote.sdk.Beacon> list) {
        itemListAdapter.setRegion(region);
        itemListAdapter.notifyDataSetChanged();
      }

      @Override
      public void onExitedRegion(com.estimote.sdk.Region region) {
        itemListAdapter.setRegion(REGION_NONE);
        itemListAdapter.notifyDataSetChanged();
      }
    });

    this.regions = setupRegions();
    this.items = createDummyItems();

    // the code that composes the UI has been omitted for brevity
  }

  @Override
  protected void onStart() {
    super.onStart();
    beaconManager.connect(new BeaconManager.ServiceReadyCallback() {
      @Override
      public void onServiceReady() {
        try {
          beaconManager.startMonitoring(REGION_BEER);
          beaconManager.startMonitoring(REGION_VEG);
          beaconManager.startMonitoring(REGION_SWEETS);
          Log.i(LOGTAG, "Started monitoring.");
        } catch (RemoteException e) {
          Log.e(LOGTAG, "Cannot start monitoring", e);
        }
      }
    });
  }

  @Override
  protected void onStop() {
    // omitted; would call beaconManager.stopMonitoring for all regions
  }

  private List<Region> setupRegions() {
    List<Region> regions = new ArrayList<Region>();
    regions.add(REGION_NONE);
    regions.add(REGION_VEG);
    regions.add(REGION_SWEETS);
    regions.add(REGION_BEER);

    return regions;
  }

  private List<Item> createDummyItems() {
    List<Item> items = new ArrayList<Item>();

    items.add(Item.from("Gurke", REGION_VEG));
    items.add(Item.from("Grüner August", REGION_BEER));
    // add more items here

    return items;
  }

Der ItemListAdapter wird als Ableitung von android.widget.ArrayAdapter implementiert und überschreibt die Methode getView(), die für jede anzuzeigende Zeile aufgerufen wird. In die erste Zeile des im Layout definierten rowViews wird der Titel des Items geschrieben, in die zweite die zugeordnete Region.

Wie in Listing 1 zu sehen, wird dem Adapter im onEnteredRegion() Callback des MonitoringListeners, der unserem BeaconManager zugeordnet ist, die betretene Region übergeben: itemListAdapter.setRegion(region). Dieser prüft beim Aufruf von getView(), ob die Region des Eintrags in der Zeile mit der aktuellen Region übereinstimmt. Sollte das der Fall sein, färbt er den Hintergrund der Zeile ein. Zusätzlich oder alternativ könnte man auch über die Sortierung der Liste die Einträge für die aktuelle Zone an den Anfang stellen.

public class ItemListAdapter extends ArrayAdapter<Item> {
  @Override
  public View getView(int position, View convertView, ViewGroup parent) {
  // get the layout and inflater and set title and region

      if (region == null || currentRegion == null) {
          return rowView;
      }

      String regionId = region.getIdentifier();
      String currentRegionId = currentRegion.getIdentifier();

      if (regionId.equals(currentRegionId)) {
          firstLine.setBackgroundColor(Color.YELLOW);
          secondLine.setBackgroundColor(Color.YELLOW);
      }

      return rowView;
  }

  public void setRegion(Region region) {
      this.currentRegion = region;
  }
}

Der Code der Anwendung ist übersichtlich; es ist nicht viel Implementierungsaufwand nötig, um iBeacon-Signale zu empfangen und in der App zu behandeln. Die iBeacon-Konzepte Ranging und Monitoring sind im Estimote SDK so abgebildet, dass sie intuitiv verwendet werden können. Den vollständigen Sourcecode der App finden Sie auf GitHub.

Abb. 4: Unterwegs in der richtigen Region

Abb. 4: Unterwegs in der richtigen Region

 Fazit und Ausblick

Wir haben gesehen, dass die Interaktion mit iBeacons mithilfe des Estimote SDKs einfach zu bewerkstelligen ist. Größere Hürden erwarte ich also nicht in der Technik der Implementierung, sondern vielmehr im Deployment der Beacons und dem Tuning von Sendeleistung, Advertising- und Scanintervallen. Diese Parameter wirken sich direkt auf die Responsiveness der Applikation bei Standortveränderungen aus. Die Abwägung dürfte also in jedem Fall schwer fallen.

Für besonders interessant, z. B. im Bereich Home Automation, halte ich die Kombination von iBeacons mit Sensoren, wie im oben erwähnten SensorTag von Texas Instruments. Auch Estimote wird mit Estimote Stickers mobile Beacons mit Bewegungs- und Temperatursensor auf den Markt bringen. Die ersten Developer Previews hätten Ende Oktober 2014 ausgeliefert werden sollen, allerdings sind bis Ende 2014 keine Kits versandt worden.

Ob der Anwendungsbereich „Indoor-Navigation“ mit dieser Technologie robust abgebildet werden kann, bleibt abzuwarten. Aufgrund der Anfälligkeit des Bluetoothsignals auf Störfaktoren wäre hierfür eine starke Ausleuchtung mit iBeacon-Signalen des entsprechenden Bereichs und Positionsberechnungen mittels Triangulation/Trilateration in Kombination mit Raumplänen nötig. Entsprechende Lösungen werden von Estimote (Indoor Navigation SDK) und verschiedenen anderen Herstellern wie beispielsweise LabWerk angeboten, jedoch sind dem Autor keine Praxisberichte bekannt.

Mit der Entwicklung einer mit iBeacons interagierenden App sind weiterhin auch Sicherheits- und Datenschutzaspekte zu berücksichtigen. Aufgrund der Einfachheit des Signals ist iBeacon anfällig für Spoofing, was während der Entwicklung nicht vergessen werden darf. Auch Daten wie der aktuelle Standort und das Bewegungsprofil, die aufgrund des Nutzerverhaltens gesammelt werden können, haben einen hohen Schutzbedarf. Aber wir wissen ja: „With great power comes great responsibility“.

Aufmacherbild: Hand holding smartphone via Shutterstock / Urheberrecht: ra2studio

Geschrieben von
Wolfgang Werner

Wolfgang Werner ist Principal IT Consultant bei der msgGillardon AG und leitet dort das Competence Center Software Engineering. Sein Steckenpferd ist der Auf- und Ausbau von Entwicklercommunitys, die neben dem Projektalltag über den Tellerrand schauen.

Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: