Eddystone: új Bluetooth-bója szabvány indul
Nem akar beidulni a Bluetooth LE szabványra épülő bóják (beacon) piaca. Ugyan az Apple már évekkel ezelőtt bejelentette saját (platformspecifikus) megoldását, egyelőre nagyon lassan mozdulnak a fejlesztők és a potenciális vásárlók. Az Eddystone nyílt szabvány, amely végre beindíthatja a területet.
A Google újra megpróbálja. Miután a The Physical Web projekt nem aratott érdemi sikert, a keresőóriás most egy új szabvánnyal igyekszik felkavarni a Bluetooth beacon-ök (bóják) lassan iszaposodó állóvizét. Az ígéretes új szabvány az Eddystone világítótoronyról kapta a nevét, a Google tervei szerint pedig platformfüggetlen, nyílt szabványként hódítaná meg a világot.
Gyors ismétlés: a Bluetooth LE (low energy) szabvány lehetővé tett egy egészen újfajta kommunikációt, az azt támogató eszközök működhetnek beaconként (bójaként), ilyenkor alacsony energiafelvétel mellett sugároznak a nagyvilágba, ezt az adást pedig más, szintén Bluetooth LE-kompatibilis eszközök tudják venni. Az új technológia abban hoz újdonságot, hogy mind a bója, mind a vevőeszköz fogyasztása minimális, így folyamatosan bekapcsolva maradhat.
A szabványt (egyik) úttörőként az Apple implementálta saját, iPhone-exkluzív megoldásában, ez lett az iBeacon, amely erős iOS-es integrációval rendelkező marketingeszköz lett. Ennek megfelelően ezt elsősorban kereskedők felé, a QR-kódok és NFC-s megoldások kiváltójaként célozta a cég. Az iPhone azonban még az Egyesült Államokban is csak a piac felét teszi ki, máshol részesedése jóval 20 százalék alatt van, így nem volt elegendő az áttörés eléréséhez.
Felmerül a kérdés, hogy ha ott a Bluetooth szabvány, akkor mi szükség van arra, hogy az Apple vagy a Google saját alszabvánnyal bonyolítsa tovább az életet. A kulcs a szoftverben rejlik: alapesetben a vevők (okostelefonok) még bekapcsolt Bluetooth mellett is süketek, a beérkező adatot eldobják, ha azt nem várja kimondottan egy futó alkalmazás. Hiányzik tehát egy lépcsőfok, a rendszerszintű integráció, amely a megfelelő üzenetre képes értesítést megjeleníteni, alkalmazást elindítani vagy másképp reagálni a beérkező adásra, mindezt pedig a felhasználó által szabályozható, nem idegesítő módon.
Megoldás van, de mi is a probléma?
Az Eddystone és az iBeacon is olyan technológiának tűnik első látásra, ami érdekesen hangzik, a való életben azonban nem használható. Ugyanez a sors már utolérte a QR-kódokat és az NFC-t is: fontosnak hangzik, elképzelhető olyan forgatókönyv, amiben használni is érdemes, de végül képtelen áttörést elérni, mivel használata problémás, elterjedtsége csapnivaló és igazából nincs is olyan probléma, amelyre megoldás kínálna.
Pedig létezik egy nagyon fontos probléma, amelyet a mobiltechnológia még nem oldott meg, és a rendelkezésre álló eszközökkel nem is tud megoldani. Sarkosan fogalmazva: belépett az ügyfél a boltba, vagy csak elsétált előtte? Sem GPS, sem Wi-Fi alapon nem adható erre elfogadható pontosságú válasz, márpedig ahhoz, hogy a kereskedő vagy szolgáltató meg tudja a telefonon keresztül közelíteni a potenciális vásárlót, ez elengedhetetlen. De ugyanez a biztos közelség kell ahhoz, hogy a buszmegállóban jelezzen a telefon, hogy mikor indul a következő járat, és ne az utca túloldalán lévő, ellenkező irányú járatot jelezze ki.
BKV-menetrend, értesítésként, kizárólag buszmegállóban állva?
Keresztplatformos és rugalmas
A Google két fontos ígéretet tett az Eddystone kapcsán. Az egyik, hogy a bóják jelei mind iOS, mind Android rendszerről foghatóak és feldolgozhatóak lesznek, vagyis ezzel a szabvánnyal teljesen kiváltható az iBeacon is, nem lesz szükség két párhuzamos bójaszett fenntartására. Ez logikus is, hiszen mindegyik szabvány a Bluetooth LE egyik speciális esetét jelenti. Az alkalmazásokba való beépítéshez rendelkezésre áll majd egy speciális iOS könyvtár, Androidon pedig a Play Services részét képező Nearby API szolgálja ki.
A Gitlab mint DevSecOps platform (x) Gyere el Radovan Baćović (Gitlab, Data Engineer) előadására a november 7-i DevOps Natives meetupon.
A rugalmasságot az biztosítja, hogy a bóják többféle információt képesek sugározni. Ez fontos változás, az Apple-féle iBeacon ugyanis csak a saját azonosítóját, a Google előző kezdeményezése, a Physical Web pedig csak URL-eket kürtölte világgá. Ezzel szemben az Eddystone eszközök az egyedi azonosító (UUID, univerzálisan egyedi azonosító) és URL frame-ek mellett úgynevezett EID (ephemeral identifier) sugárzására is képesek. Ez egy olyan biztonságos adatformátum, amelyet csak a jogosult felhasználók tudnak dekódolni. Ezeken felül a szabvány egy diagnosztikai formátumot is ismer, amelynek az üzemeltetésben lehet szerepe és kiolvasható belőle például az elemek töltöttsége vagy a meghibásodásra utaló hibakódok.
Lesz belőle ökoszisztéma?
Ahhoz, hogy az Eddystone beváltsa a hozzá fűzött reményeket, az kell, hogy széles körű fejlesztői és hardvergyártói tamogatás is legyen mögötte. A Google ezt nyilván tudja, így első körben gyártópartnerekkel és fejlesztőkkel is felvette a kapcsolatot, hogy a szabványt támogató megoldások minél hamarabb piacra kerülhessenek. Az Android oldalán a támogatás automatikus lesz, a Play Services révén ugyanis gyakorlatilag minden, Android 2.3 és későbbi telefon automatikusan támogatni fogja a szabványt, gyártói szoftverfrissítés nélkül. A Google egyébként rövid időn belül minden releváns alkalmazásába beépíti majd az Eddystone támogatását, a Google Now-tól a Mapsen keresztül számtalan appba kerül majd be a képesség.
Az üzemeltetőknek is szolgáltatást épít majd a cég, a Proximity Beacon API-n keresztül lehet majd regisztrálni bójákat a rendszerbe és párosítani hozzájuk a megfelelő interakciókat és viselkedési mintákat.
A Google Developer oldal itt, a szabvány Github-oldala pedig itt található.