bluetooth.java

final String payload = "ce815a358bed057c3bdb5032a6246b6d5cb6113e705611cb81afe60aa2490126.f2a2b89f3eb8e17d2b612f2cafec30e5672a500cda8b81f21ff44489ececa885010f010b10112713011510110125000a00.13b2c3b7bafb1cb6be4aa252e2b2b7b853d7ae2ce9ae5dbb1834bf4f9d9ea3180201"; 

//hämta adapter och skapa Qlocx-SDK
BluetoothAdapter adapter = BluetoothAdapter.getDefaultAdapter();
final QlocxInterface qlocxInterface = new QlocxInterface(adapter);

//öppna lås med payload från Sesam
qlocxInterface.open(payload, new QlocxInterface.Callback() {
        @Override
        public void openResult(byte[] result) {
                
        }
        
        @Override
        public void senseResult(byte[] result, boolean isOpen) {}

        @Override
        public void error(QlocxException e) {
                Log.e("QlocxException", e.toString());
        }
});

//känn av dörrstatus med payload från Sesam
qlocxInterface.sense(payload, new QlocxInterface.Callback() {
        @Override
        public void result(byte[] result) {}
        
        @Override
        public void senseResult(byte[] result, boolean isOpen) {
                
        }

        @Override
        public void error(QlocxException e) {
                Log.e("QlocxException", e.toString());
        }
});

//avbryt pågående handling
qlocxInterface.cancel();

//kolla om payloaden innehåller ett sense-kommando
qlocxInterface.senseAvailable(payload);

OK, låter rimligt - vi konsumenter får helt enkelt synkronisera för att se till att vi bara gör en operation åt gången.

Felhanteringen vid konstruktorn: vad är det som kan gå fel där? Hade det varit möjligt att vänta med att rapportera fel tills att man anropat open/sense, så att man kan få det i callbacken? Det känns som att det alltid bör vara möjligt att skapa själva låsinterfacet men att man kanske inte lyckas med några operationer om det är något som gått snett.

Jag tror att det kommer vara enklast att skicka alla fel till callbacken, så slipper man ha hantering på två ställen (dvs callback + catch). Med andra ord, SDK:t kastar aldrig något rakt ut, åtminstone inte för fel som går att förutse (typ sådana du listat).

Gällande frågorna:
Det låter väl rimligt - min tanke var att vi kunde undvika overhead med själva wrappningen av objekten som JSONArray då det ända ska serialiseras ned när det ska upp till er server. Om det bara ska passas vidare kan man tänka sig att man bara tar emot en byteström som representerar den payload som ska upp (typ [{"foo":"bar"},"42"]). Men jag gissar att det är enklare för er att konstruera dem på det sätt ni gör, så det är helt OK med mig! Låt oss köra på JSONArray.

Jag fimpar att man kan få Exception i konstruktorn, kom på att anledningen att ha den där inte är bra ändå.

Nu kommer alla Exceptions via callbacken istället.

Det är enklare för mig att låta det vara en byteström, om du vill ha det, det är så jag tar emot datan via blåtanden.

Är det så tycker jag att vi kan låta det vara en byteström, för jag gissar att klienten ändå inte har något behov av att läsa ut någon data. Då kan vi bara hantera det som ett opakt värde som ska upp till backend utan några egentliga antaganden om innehåll eller format.

Det låter som att vi har fått ihop något som låter rimligt då, maila gärna när det finns uppdateringar.

QlocxException's:
Blåtands-adaptern är ej aktiverad: Bluetooth adapter not enabled
En annan handling körs: Another action is currently running
Blåtands-enheten hittades ej: Peripheral not found
Anslutningen till blåtands-enheten avbröts: Something happened to the bluetooth connection, disconnected
Nyckeln/payloaden skickad till SDK't innehåller inte en 'sense'-payload*: The payload does not contain a sense action

• På mötet hos er med Robin och PostNord kom vi fram till att Qlocx skickar en enda lång payload till Sesam som sedan appen tar del av. Som det ser ut i dag har jag skilt varje action med en punkt.
  Du får även en metod i SDK't som heter senseAvailable(payload) returnerar en boolean.