Writing/Bluetooth
Aparatul care n-a fost niciodată în cameră
Am construit o aplicație pentru un espressor fără să am espressorul. Constrângerea s-a dovedit cea mai utilă decizie din proiect.
CoffeeBrew se împerechează cu un espressor prin Bluetooth, citește cât mai are apă și boabe, îi dă rețeaua ta Wi-Fi ca să meargă și când telefonul e în altă parte și prepară după un program. Am construit tot, fără să am vreodată aparatul.
Sună a limitare și a fost cea mai utilă constrângere din proiect, pentru că a forțat din prima zi o decizie pe care majoritatea aplicațiilor pentru hardware o amână până devine scumpă.
Scurtătura care strică baza de cod
Mișcarea tentantă e să presari un indicator de demonstrație prin fluxul de conectare. Merge imediat, arată bine la prezentare și nu mai poate fi descurcată după aceea, pentru că purtarea reală și cea falsă ajung amestecate în aceleași funcții. Când hardware-ul chiar apare, nu integrezi, ci sapi.
“Presari indicatoare de demonstrație prin fluxul de conectare și purtarea reală și cea falsă ajung amestecate în aceleași funcții.”
Un protocol cu șase metode
Așa că dispozitivul e o interfață: scanează, citește senzorii, listează rețelele, configurează Wi-Fi, trimite o comandă de preparare. Aparatul simulat e o implementare a ei, cu întârzieri, o putere de semnal care variază, patru rețele false și valori de senzori care alunecă așa cum o fac cele reale. Fluxul de conectare nu știe niciodată cu care implementare vorbește, pentru că nu poate vedea dincolo de interfață.
export interface CoffeeMakerProtocol { getScanFilter(): ScanFilter readSensors(id): Promise<SensorData> readAvailableWifiNetworks(id) provisionWifi(id, credentials) sendBrewCommand(id, command)} // one implementation today, two tomorrowÎnlocuirea cu un aparat real e un fișier. Asta e toată afirmația și se poate verifica: nu există nicăieri în aplicație o ramură care să întrebe dacă dispozitivul e real.
Partea care e reală oricum
Tot ce e deasupra interfeței e construit ca lumea, pentru că nimic din el nu depinde de existența hardware-ului: fluxul de împerechere cu toate stările lui de eșec, backendul, plata pentru boabe și preparările programate.
Ultima merită o notă separată. O preparare programată nu valorează nimic dacă memento-ul are nevoie ca aplicația să fie deschisă, iar un cronometru în client e exact asta, pentru că moare odată cu procesul, iar sistemul de operare o să omoare procesul. Așa că programul stă în baza de date și un cron din interiorul bazei de date trimite notificarea. Telefonul e client al programului, niciodată proprietarul lui, ceea ce e adevărat indiferent dacă există sau nu un aparat la celălalt capăt.
