Poslovna aplikacija može da radi bez interneta ako unapred sačuva potrebne podatke na uređaju i ima dogovorena pravila za unos i kasnije slanje. Zaposleni tada može da popuni izveštaj ili pregleda preuzete naloge. Promene ulaze u zajedničku evidenciju tek kada ih server prihvati. Zato treba odrediti koje radnje rade offline i kako korisnik vidi da nešto još nije poslato.
To je korisno, recimo, serviseru koji ulazi u podrum bez signala. Zaposleni treba da sačuva izveštaj tokom pregleda, a zatim da ga pošalje kada dobije vezu. Za odluku o samoj vrsti aplikacije pogledajte poređenje PWA i nativne aplikacije. Ovde razrađujemo ponašanje jednog poslovnog zadatka kada veza nestane.
Koje funkcije mogu da rade bez interneta?
Počnite spiskom podataka potrebnih za jednu smenu: dodeljeni nalozi, uputstvo za rad i obrazac izveštaja. Dogovorite šta aplikacija preuzima dok ima vezu i kako pokazuje vreme poslednjeg osvežavanja. Nalog koji nije preuzet neće postati dostupan samo zato što aplikacija ima offline režim.
Pregled sačuvanog naloga i unos beleške mogu da rade lokalno. Za proveru trenutne zalihe u zajedničkom magacinu potrebna je veza sa sistemom koji vodi stanje. Bez nje se može prikazati poslednja poznata količina, jasno označena vremenom, ili sačuvati zahtev koji čeka proveru.
Android smernice za offline aplikacije odvojeno razmatraju čitanje i upis podataka. Aplikacija koja otvara ranije preuzet sadržaj ne mora automatski da podržava i unos bez interneta. To treba navesti po funkciji u ponudi i specifikaciji.
Primer: serviser popunjava nalog bez signala
Sledeći tok je izmišljen primer za razradu zahteva. Ne predstavlja rezultat testa niti opis postojećeg klijentskog proizvoda. Ana pre polaska preuzima nalog SV-104, verziju 7, za pregled uređaja. U podrumu gubi vezu, unosi „Filter zamenjen”, označava stanje „Spreman za rad” i dodaje fotografiju.
Predložena aplikacija prvo proverava obavezna polja i završava upis na uređaju. Tek tada prikazuje potvrdu lokalnog čuvanja. Ako nema dovoljno prostora za fotografiju, prijavljuje da prilog nije sačuvan i ne prikazuje ceo izveštaj kao uspešno sačuvan. Ana treba da zna koji deo posla mora da ponovi.
Pomerite tabelu levo ili desno da vidite sve kolone.
| Poruka korisniku | Šta je potvrđeno | Šta sledi |
|---|---|---|
| Sačuvano na uređaju | Podaci i obavezan prilog upisani su u lokalno skladište. | Izveštaj još nije potvrđen na serveru. |
| Čeka slanje | Izveštaj je u redu za slanje; nema potvrde prijema. | Pokušaj kada je veza dostupna, uz vidljiv broj neposlatih izveštaja. |
| Potvrđeno na serveru | Server je prihvatio ceo izveštaj i obavezan prilog. | Prikaz vremena potvrde i nove verzije naloga. |
| Potrebna odluka | Izmena se razlikuje od novije zajedničke verzije. | Pregled razlike i odluka ovlašćene osobe pre završetka sinhronizacije. |
Kada se veza vrati, aplikacija šalje izveštaj. Ako važeća verzija i prava pristupa odgovaraju, server ga prihvata kao verziju 8. Ana vidi potvrdu, a koordinator može da otvori prihvaćene podatke. Sama oznaka Wi-Fi veze nije potvrda da je server primio izveštaj.
Kako sprečiti duplikate pri ponovnom slanju?
Veza može da se prekine nakon čuvanja na serveru, pre nego što telefon primi odgovor. Korisnik i dalje vidi „Čeka slanje”, iako je prijem završen. Sledeći pokušaj zato mora da prepozna istu radnju.
U našem predloženom toku aplikacija dodeljuje jedinstvenu oznaku predaji izveštaja i čuva je uz podatke. Automatski pokušaj i dugme „Pokušaj ponovo” koriste tu istu oznaku i isti sadržaj. Server proverava da li je već obradio predaju i vraća njen rezultat. Ponovljeni prijem ne stvara drugi izveštaj niti ponovo pokreće isto obaveštenje.
Server odbija istu oznaku sa drugačijim sadržajem. Nova namerna izmena dobija novu oznaku i vezu sa prethodnom verzijom. Tako se razlikuje ponovljeni prenos od novog rada. Ovakva obrada zove se idempotentna: ponavljanje iste radnje ima isti poslovni efekat. HTTP standard opisuje zašto bezbedno ponavljanje zahteva mora biti unapred poznato. Broj klikova u interfejsu sam po sebi ne rešava duplikate.
Šta ako dve osobe promene isti podatak?
U zasebnoj varijanti primera, dok Ana radi offline na verziji 7, koordinator menja stanje uređaja u „Van upotrebe”. Ana na telefonu beleži „Spreman za rad”. Pri povratku veze njena starija verzija ne sme prećutno da pregazi upozorenje koordinatora.
Predloženo pravilo je da aplikacija sačuva Anin unos, prikaže obe vrednosti sa autorima i zatraži odluku koordinatora. On proverava stanje, bira važeću vrednost i upisuje razlog. Istorija čuva prethodne izmene. Do tada izveštaj ostaje označen kao nerešen.
Za različita, nezavisna polja može biti dozvoljeno automatsko spajanje. Za isto polje dogovorite pravilo prema posledici greške. Prepisivanje prema vremenu poslednje izmene može biti neprihvatljivo za odobrenja ili stanje opreme. Ko odlučuje i šta se prikazuje zaposlenom treba zapisati pre razvoja.
Da li se podaci šalju kada zatvorim aplikaciju?
To zavisi od operativnog sistema, pregledača i izabranog načina rada. Za web aplikacije Workbox dokumentacija opisuje Background Sync i rezervni postupak. Tamo gde taj API nije podržan, Workbox pokušava slanje kada se service worker ponovo pokrene. Vreme slanja zato proverite za podržane uređaje, uključujući stanje kada je aplikacija zatvorena.
Dogovorite postupak koji korisnik može da završi dok je aplikacija otvorena: pregled neposlatih stavki, ponovno slanje i jasna poruka o ishodu. Posebno proverite zaključavanje ekrana, štednju baterije i ponovno otvaranje aplikacije na uređajima koje tim stvarno koristi.
Lokalna kopija takođe zahteva plan. WebKit opisuje ograničenja prostora i mogućnost uklanjanja podataka iz skladišta pregledača. Brisanje podataka sajta, gubitak telefona ili deinstalacija mogu dovesti do gubitka pristupa neposlatim unosima. Korisnik zato treba da vidi šta još postoji samo na tom uređaju i kome prijavljuje neuspešno slanje.
Šta sa osetljivim podacima i isteklom prijavom?
Na telefon preuzimajte samo podatke potrebne za dogovoreni zadatak. Odredite koliko dugo ostaju dostupni, kako se štite i šta se dešava pri promeni korisnika. OWASP upozorava da lokalno skladište pregledača samo po sebi ne štiti poverljivost. Za osetljive podatke potrebna je procena pristupa uređaju, zaštite aplikacije i upravljanja ključevima.
Ako je prijava istekla, u predloženom toku slanje staje i traži novu prijavu istog korisnika. Unos ostaje vezan za njegov nalog i ne prenosi se na osobu koja se sledeća prijavi. Server ponovo proverava ovlašćenja pre prihvatanja. Kada je uređaj offline, ukidanje pristupa na serveru ne može odmah postati poznato telefonu; zato unapred odredite dozvoljeno trajanje lokalnog pristupa.
Šta proveriti pre prihvatanja offline funkcije?
Za probu pripremite test naloge i izmišljene podatke. Svaki scenario počinje iz poznatog stanja. Beležite verziju aplikacije, uređaj, sistem i rezultat; sledeća lista je plan provere, a ne tvrdnja da je proba već izvedena.
- Preuzmite nalog, isključite vezu, popunite izveštaj i ponovo otvorite aplikaciju. Proverite da podaci i obavezan prilog ostaju dostupni.
- Prekinite odgovor nakon serverskog prihvatanja. Ponovite slanje istom oznakom i proverite da postoji jedan prihvaćen izveštaj.
- Promenite isto polje sa drugog naloga. Proverite poruku o sukobu, sačuvan unos i odluku ovlašćene osobe.
- Isprobajte istek prijave, promenu korisnika i ukidanje prava. Neposlati izveštaj ne sme postati vidljiv drugom nalogu.
- Proverite neuspešno čuvanje priloga i nedostatak prostora. Poruka treba da pokaže šta nije sačuvano.
- Vratite vezu posle zaključavanja ekrana i ponovnog otvaranja. Proverite red za slanje i potvrdu celog izveštaja.
Ova pravila unesite u specifikaciju softvera. Za izradu mobilne aplikacije pošaljite primer jednog terenskog zadatka, uređaje koje koristite i podatke koji moraju biti dostupni bez veze. U zahtevu za procenu projekta navedite koliko dugo tim obično radi bez signala, da bismo razradili potreban obim i proveru.