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);

Förslag:

• Går det att avbryta enbart en operation? En idé kan vara att man returnerar en Cancellable från sense/open exempelvis som kan användas för att avbryta operationen, och har kvar cancel()-metoden på Bluetooth för att avbryta allt vid behov
• Namngivning kanske kan anpassas till Java-standard, jag tänker på liten bokstav för funktionsnamn. Så t ex bluetooth.open(...), public void onResult(...) etc.
• Bluetooth är kanske inte det mest beskrivande namnet för vad objektet representerar. Förslag QlocxInterface, BluetoothLock, ...

Fråga:

• "skickas till Qlocx system" - jag gissar detta ska upp till er backend alltså?
• Vad är anledningen till att använda typen JSONArray? Om vi på klientsidan inte är intresserade av att läsa innehållet (utan bara passa vidare till er backend) undrar jag om det inte är bättre att använda en annan typ än JSONArray (t ex en byteström eller dylikt). Om det å andra sidan är så att vi vill läsa ut någon data från resultatet så hade jag föredragit väldefinierade typer (t ex List<BluetoothResult> eller vad det nu kan vara). Dock - om det är så att ni läser ut det som JSONArray från låset t ex och är den typ ni använder inne i SDK:t så kan det vara motiverat att behålla den typen för att slippa extra konvertering, så det beror på hur er implementation ser ut. Har ni åsikter om detta?

Jag tycker att dina föreslag är bra, jag har implementerat dem!
Förslag 1: Cancellable tror jag blir överflödig då bara en av handlingarna open eller sense kan köras per gång.

Anledningar till Exception:

• En handling (open/sense) körs.
• Fel på payload (antagligen gammal, time to live är expirerad)
• Enhet(lås) hittades inte
• Anslutning till enhet bröts
• BluetoothAdaptern är inte enabled

Fråga 1: Japp den avser det som ska upp till vår backend.
Fråga 2: Jag gjorde den till JSON för att det är så den mottags hos backend:en, då slipper ni tänka på hur ni ska formatera datan ö.h.t och bara skicka vidare den till oss / Sesam. Jag tillgodoser gärna dina behov i denna fråga, säg vad du vill ha så får du det! :)

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.