Nutzerinteraktion mit Screen-Off-Ereignissen mit Beacons

Question

Wir möchten die Beacon-Technologie in unsere Apps integrieren, um die Interaktion mit Screen-Off-Ereignissen zu ermöglichen.

Im vorliegenden Anwendungsfall gehen wir davon aus, dass sich der Endbenutzer in ständiger Bewegung befindet.

Bisher haben wir zwei verschiedene Ansätze getestet.

• Kontakt SDK/Android Beacon Bibliothek, um ständig für Baken Scannen zu werden. Mithilfe der UUID (vorausgesetzt, wir verwenden Eddystone) können wir sie einer zwischengespeicherten Nachricht zuordnen, die wir für unser Back-End abgerufen haben. Dies kostet jedoch viel Batterie.
• Dies hatte Potenzial, da es ein Beacon Dashboard zur einfachen Konfiguration der Anhänge auf jedem Beacon hat und es die "gleiche" Implementierung sowohl auf iOS als auch auf Android hat. Nach dem Lesen der Dokumentation und nach zahlreichen Tests konnten wir jedoch keine Beacon-Anhänge abrufen, wenn der Bildschirm ausgeschaltet war. Der einzige mögliche Weg war, dass der Benutzer sich noch 3 Minuten vor dem Beacon aufhält (abhängig von den Smartphone- und Energieeinstellungen) und es widerspricht unserer Prämisse, dass der Benutzer ständig in Bewegung ist, so dass der Scan ausgelöst werden könnte wenn der Benutzer nicht in der Nähe der Bake ist.

auch: mit Nachrichten auf iOS hatten wir das gewünschte Verhalten: Die App die Baken entdecken würde, wenn die Nachrichten mit, wenn sowohl die App und die API für Hintergrund-Nutzung konfiguriert wurde.

So fragen wir:

• Gibt es eine Möglichkeit der Nähe API mit Bildschirm-off-Veranstaltungen zu bedienen? Wie einen Scan ständig planen?
• Welche anderen Alternativen haben wir, die plattformübergreifend zwischen iOS und Android genutzt werden können? (So ​​dass wir versuchen können, ein ähnliches Verhalten zwischen den Plattformen zu gewährleisten)

EDIT: Bei der weiteren Lektüre, kamen wir zu dem Schluss, dass BLE Beacon Scannen auf der Batterie nur minimale Auswirkungen verursacht, wenn sie richtig verwendet (Schwerpunkt die korrekte, wir müssen die Heuristiken auf unserer Seite ändern), siehe: this. Die Frage bleibt dann: Warum können wir nicht Hintergrundscans in der Nähe haben ai ohneIn der Nähe Nachrichten eigene Benachrichtigungen, so dass wir behaupten können, dass der Benutzer in der Nähe eines Beacons übergeben? Was uns faszinierte, ist, dass dies problemlos auf iOS funktioniert ...

Answer 1

Die Nearby-API scannt nach einem Zeitplan ihrer Wahl, einschließlich Bildschirm auf Ereignisse. Sie können die Suchkriterien in der Nähe für Ihre App nicht anpassen, da es sich um einen Dienst handelt, der für alle Apps auf dem Telefon ausgeführt wird. Wenn Sie "In der Nähe" verwenden, müssen Sie diese Einschränkung akzeptieren.

Die Android Beacon Library ist Open Source und ermöglicht flexible Konfigurationen beim Scannen. Wenn Sie feststellen, dass Ihre Konfiguration zu viel Akku für Ihren Anwendungsfall verwendet, können Sie dies anpassen. Die Standardeinstellungen wurden für einen guten Kompromiss zwischen Stromverbrauch und schneller Erkennung entwickelt, daher werden diese empfohlen.Wenn Sie feststellen, dass die Standardeinstellungen für Sie nicht funktionieren, gibt es viele verschiedene Möglichkeiten, wie Sie sie einrichten können. Der einfachste Weg besteht darin, seine scanPeriod und scanPeriod für den Hintergrund anzupassen. Es gibt jedoch viele andere Möglichkeiten, das Scanverhalten anzupassen.

Sie sollten jedoch beachten, dass eine "ständige Planung eines Scans" (wie in Ihrer Frage erwähnt) im Low-Latency-Modus viel Strom verbraucht. Die Android Beacon-Bibliothek wird standardmäßig im Low-Power-Modus kontinuierlich gescannt, wenn sich die App im Hintergrund befindet und keine Beacons vorhanden sind. Bei den meisten Geräten führt dies zu Erkennungen innerhalb von 5 Sekunden und zu einem angemessenen Stromverbrauch, ähnlich dem Standby-Modus.

Es ist schwierig, weitere Vorschläge zu machen, ohne die Konfiguration der Android Beacon Library, die Testbedingungen und den Stromverbrauch zu kennen. Wenn Sie diese Informationen bereitstellen können, kann ich möglicherweise mehr helfen.

Volle Offenlegung: Ich bin der Hauptentwickler auf der Open Source-Projekt Android Beacon Library.