-
-
Save qlocx/9e62025c8bc1db290ab5bdd38a45f479 to your computer and use it in GitHub Desktop.
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); |
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.
Förslag:
Cancellable
frånsense
/open
exempelvis som kan användas för att avbryta operationen, och har kvarcancel()
-metoden påBluetooth
för att avbryta allt vid behovbluetooth.open(...)
,public void onResult(...)
etc.Bluetooth
är kanske inte det mest beskrivande namnet för vad objektet representerar. FörslagQlocxInterface
,BluetoothLock
, ...Fråga:
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 exList<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?