Aplikacione mobile offline nuk janë luks, sepse telefoni e humbet sinjalin vazhdimisht. Një aplikacion SaaS duhet të punojë edhe kur rrjeti bie. Përdoruesit kanë nevojë për të dhënat e tyre. Për më tepër, ata duan ta mbarojnë punën që kanë përpara.

Aplikacioni mund t'i dërgojë ato ndryshime më vonë, sapo sinjali të kthehet. Si rrjedhojë, produkti duket i besueshëm dhe jo i brishtë. Gjithashtu ul zhgënjimin që krijon një rrjet i dobët.

Për ekipet që ndërtojnë vegla SaaS, puna offline nuk është veçori shtesë. Përkundrazi, ajo i takon dizajnit që nga dita e parë. Aplikacione mobile të mira e nisin këtë punë herët.

Çfarë do të thotë offline-first

Dizajni offline-first e trajton telefonin si një shtëpi të vërtetë për të dhënat. Në vend që të thërrasë serverin në çdo prekje, aplikacioni mban në pajisje atë që i duhet. Ai lexon fillimisht nga ruajtja lokale. Pastaj flet me serverin kur rrjeti e lejon.

Kjo e përmbys marrëdhënien e zakonshme mes një aplikacioni dhe backend-it të tij. Serveri mbetet në komandë, por pajisja qëndron vetë për shumë detyra.

Modeli u shkon mirë aplikacioneve mobile SaaS, sepse përdoruesit mobile jetojnë me sinjal të copëtuar. Për shembull, ata hapin aplikacione në tren, në ashensor, në bodrum ose në një sallë plot.

Një aplikacion i zakonshëm shfaq një ikonë ngarkimi sapo bie sinjali. Një aplikacion offline vazhdon të shfaqë të dhënat e ruajtura dhe pranon ende hyrje. Ky dallim ka rëndësi, sepse njerëzit e gjykojnë softuerin nga sjellja në një ditë të vështirë.

Pse aplikacione mobile SaaS duan punë offline

Veglat SaaS mbajnë punë që askush nuk e shtyn dot. Agjentët e shitjes, shoferët, inxhinierët në terren dhe skuadrat e kantierit varen nga pajisja gjithë ditën. Një zonë pa sinjal e thyen rrjedhën në çastin më të keq. Përdoruesit humbin atë që shkruan, ose përsërisin një hap sepse nuk e shohin rezultatin.

Dizajni offline-first e ndan sjelljen e aplikacionit nga gjendja e rrjetit. Aplikacioni e pranon ndryshimin tani dhe e dërgon më vonë. Edhe shpejtësia përmirësohet, sepse të dhënat lokale shfaqen menjëherë.

Megjithatë, modeli sjell probleme të reja. Ekipet duhet të vendosin cilat të dhëna rrinë në pajisje, si radhiten ndryshimet dhe si ecën sinkronizimi. Pyetja më e vështirë është konflikti. Telefoni dhe serveri mund ta ndryshojnë të njëjtin regjistrim ndërsa janë të ndarë.

Ruajtja lokale është themeli

Ruajtja lokale është themeli i çdo aplikacioni offline. Ajo e lejon telefonin të mbajë të dhëna të pastra dhe të tipizuara pa asnjë thirrje te serveri. Për shumicën e produkteve, një bazë e vogël të dhënash ia kalon një depoje të thjeshtë çelës-vlerë. Një bazë të dhënash i lehtëson kërkesat, indekset, lidhjet mes regjistrimeve dhe grupet e mëdha.

SQLite është zgjedhja e zakonshme në pajisje mobile. Është një motor i vogël relacional që rri drejt e në pajisje, dhe ekipi pas tij shpjegon qartë ku i shkon motori dhe ku jo.

Ekipet mund të ruajnë lokalisht regjistrimet që përdoruesit prekin më shpesh. Aplikacioni pastaj i lexon pa asnjë kërkesë. Shkrimet lokale punojnë njësoj. Një përdorues shton ose ndryshon një regjistrim kur është offline, dhe aplikacioni e mban atë ndryshim derisa sinkronizimi të nisë.

Si zgjidhet çfarë mbahet në pajisje

Offline-first nuk do të thotë kopjim i gjithë backend-it në çdo telefon. Ajo rrugë harxhon hapësirë dhe rrit rrezikun për privatësinë.

Përkundrazi, zgjidhni të dhënat që përdoruesit duan vërtet kur janë pa lidhje. Në shumicën e aplikacioneve kjo do të thotë regjistrime të fundit, detyra të hapura, të dhëna bazë të llogarisë dhe çdo gjë që kërkon puna e çastit.

Politikat e ruajtjes ndryshojnë sipas kategorisë. Për shembull, regjistrimet e nxehta rrinë me javë, ndërsa ato të rralla bien shpejt. Rreshtat e ndjeshëm duan kujdes shtesë, sepse pajisja tani është edhe një vend ku rrinë të dhëna biznesi. Rreshtat e vjetër duhet të skadojnë gjithashtu, që ruajtja lokale të mos rritet pa kufi.

Një radhë për veprimet offline

Të dhënat lokale e zgjidhin vetëm gjysmën e problemit. Aplikacioni kërkon edhe një mënyrë të sigurt për të mbajtur veprimet e bëra offline. Radha e bën këtë punë. Në vend që të nisë menjëherë një thirrje API, aplikacioni e shkruan veprimin në një listë lokale.

Për shembull, një përdorues ndryshon regjistrimin e një klienti kur është offline. Aplikacioni e ruan ndryshimin dhe shton një zë sinkronizimi në radhë. Pastaj, kur sinjali kthehet, ai e përpunon listën me radhë.

Çdo zë duhet të mbajë detaje të mjaftueshme për ta riluajtur veprimin. Aty hyjnë lloji, identifikuesi i regjistrimit, ngarkesa, vula kohore dhe një id unike.

Radha kërkon edhe ripërpjekje, sepse një ndërprerje e shkurtër e rrjetit nuk duhet ta humbasë një veprim. Megjithatë ripërpjekjet ngrenë një rrezik të ri. Konkretisht, e njëjta thirrje e dërguar dy herë krijon regjistrime të dyfishta.

Pse kanë rëndësi API-të idempotente

Një thirrje idempotente jep të njëjtin rezultat sado herë të ekzekutohet. Kjo veti bëhet jetike sapo një pajisje nis ripërpjekjet.

Për shembull, merrni një aplikacion që krijon një porosi kur është offline. Ai rilidhet dhe dërgon thirrjen, por lidhja bie para se të vijë përgjigjja. Aplikacioni nuk e di nëse serveri e mori porosinë. Prandaj duhet të provojë sërish.

Pa mbrojtje, ajo ripërpjekje krijon një porosi të dytë. Me një pikë fundore idempotente, serveri e njeh thirrjen e parë dhe kthen të njëjtin rezultat. Mbrojtja e zakonshme është një identifikues unik veprimi nga klienti. Serveri e ruan atë id pranë regjistrimit që krijoi.

HTTP e ka një emër për këtë veti, dhe RFC 9110 përcakton cilat metoda e mbajnë. Modeli ndihmon shumë përtej punës offline. Për më tepër, mbron thirrjet e zakonshme në një lidhje të paqëndrueshme. Për aplikacione mobile SaaS, idempotenca i takon dizajnit të API-t që në fillim, jo një arne të mëvonshme.

Si dizajnohet një cikël sinkronizimi

Sinkronizimi e lidh depon lokale me të vërtetën në server. Ai kërkon politika të qarta për atë që ndodh kur një pajisje kthehet online.

Një cikël i thjeshtë nis kur aplikacioni sheh një lidhje të gjallë. Pastaj shtyn veprimet lokale në pritje dhe më pas tërheq të dhëna të freskëta nga serveri. Radha varet nga rregullat e biznesit. Disa ekipe shtyjnë të parat, ndërsa të tjera tërheqin të parat.

Ajo që ka rëndësi është që cikli të ecë njësoj çdo herë. Një ekip mund ta testojë një proces të parashikueshëm kundër shumë mënyrave të dështimit.

Sinkronizimi nuk duhet të supozojë kurrë një lidhje të qëndrueshme. Për shembull, një telefon e mban sinjalin pak sekonda dhe pastaj e humbet sërish. Për këtë arsye, sinkronizimi duhet të ecë në grupe të vogla. Aplikacioni shënon çdo grup që mbërrin, dhe çdo gjë që dështon pret përpjekjen tjetër.

Kur klienti dhe serveri bien në konflikt

Pjesa më e vështirë e offline-first shfaqet kur dy kopje të një regjistrimi ndryshojnë veç e veç.

Për shembull, merrni një inxhinier në terren dhe një menaxher zyre. Inxhinieri ndryshon numrin e telefonit të një klienti kur është offline. Ndërkohë menaxheri ndryshon të njëjtin numër në aplikacionin web. Të dy ndryshimet janë të vlefshme, por sistemi duhet të zgjedhë një përfundim gjatë sinkronizimit.

Ky është një konflikt, dhe rregullat për të i takojnë dizajnit para nisjes. Politika më e thjeshtë është fiton shkrimi i fundit. Ndryshimi më i ri sipas orës ose versionit e merr regjistrimin. Kuptohet lehtë, por ndryshime të vërteta mund të zhduken.

Një bashkim në nivel fushe është më i butë. Nëse një përdorues ndryshon numrin e telefonit dhe tjetri adresën, aplikacioni i mban të dyja. Disa rrjedha duan një njeri në vend të kësaj. Për shembull, aplikacioni shfaq të dyja versionet dhe e lë një përdorues të besuar të zgjedhë.

Asnjë politikë e vetme nuk u shkon të gjitha produkteve SaaS. E sakta ndjek procesin e biznesit, prandaj hartojeni fillimisht atë proces.

Versionet dhe gjurmimi i ndryshimeve

Numrat e versionit e bëjnë sinkronizimin shumë më të lehtë për t'u arsyetuar. Çdo regjistrim në server mban një version që lëviz në çdo ndryshim. Klienti dërgon versionin që pa i fundit. Serveri pastaj kontrollon nëse ai version është ende i çastit.

Nëse të dy përputhen, shkrimi vazhdon. Nëse ndryshojnë, serveri e di se një ndryshim tjetër mbërriti i pari. Kjo mbrojtje i ndalon mbishkrimet e heshtura.

Një teknikë tjetër e dobishme është gjurmimi i ndryshimeve të veçanta në vend të regjistrimeve të plota. Klienti dërgon veprimin, jo gjithë objektin. Kështu ul gjasat për të shkelur mbi ndryshime që nuk i pa kurrë. Gjithashtu lë një gjurmë të qartë se çfarë provoi të bënte çdo pajisje.

Si dizajnohet për një sinjal të dobët

Offline-first nuk ka të bëjë vetëm me një lidhje të vdekur. Shumica e përdoruesve vuajnë sinjal të dobët shumë më shpesh sesa mungesë të plotë.

Një telefon kërcen mes Wi-Fi dhe të dhënave mobile gjithë ditën. Lidhja mund të përgjigjet, por shumë ngadalë. Prandaj aplikacione mobile nuk duhet ta bllokojnë ekranin në çdo thirrje. Afatet e pritjes kanë rëndësi këtu, sepse asnjë kërkesë nuk duhet ta ngrijë pamjen ndërsa aplikacioni pret.

Ndërfaqja duhet ta thotë gjendjen e sinkronizimit me fjalë të thjeshta. Përdoruesit duan të dinë nëse aplikacioni e mban ndryshimin në pajisje, e pret në radhë apo mori miratimin e serverit. Një gjendje e qartë i ndalon njerëzit të shtypin të njëjtin buton sërish e sërish.

Edhe flamujt e rrjetit janë burim i dobët i së vërtetës. Një pajisje pretendon lidhje të gjallë ndërsa serveri mbetet i paarritshëm. MDN e shënon pikërisht këtë kufizim në shënimet e veta për vetinë online. Për këtë arsye, trajtojeni një përgjigje të vërtetë API si sinjalin më të fortë.

Kur sinkronizimi dështon

Sinkronizimi dështon për shumë arsye. Serveri refuzon një veprim. Lidhja bie. Të dhënat nuk u përgjigjen më rregullave të çastit.

Jo çdo dështim meriton të njëjtën përgjigje. Një gabim i shkurtër rrjeti rri në radhë. Megjithatë, një gabim i përhershëm do trajtim tjetër. Për shembull, serveri refuzon një ndryshim sepse përdoruesi humbi të drejtën mbi atë regjistrim. Ripërpjekja pa fund e asaj thirrjeje nuk ndihmon askënd. Aplikacioni duhet ta shënojë dhe ta shpjegojë me fjalë të thjeshta.

Edhe sinkronizimi i pjesshëm meriton mendim. Nëse presin dhjetë veprime dhe i shtati dështon, aplikacioni duhet ta dijë gjendjen e secilit. Gjendja për çdo veprim e pengon radhën të kthehet në një panjohur të madhe.

SQLite, WatermelonDB dhe një motor sinkronizimi

SQLite mbetet zgjedhje e fortë për të dhëna lokale të tipizuara. Modeli i tij relacional u shkon regjistrimeve, lidhjeve, kërkesave dhe shkrimeve të sigurta. Një ekip ndërton një shtresë sinkronizimi drejt mbi të. Ajo rrugë jep kontroll të plotë, por i ngarkon ekipit më shumë punë.

WatermelonDB është një mundësi tjetër për aplikacione mobile React Native që duan një shtresë lokale më të pasur. Ai synon sjellje local-first dhe lexime reaktive, dhe projekti rron i hapur në GitHub.

Asnjë bazë të dhënash nuk e krijon vetë një dizajn offline-first. Ekipet duan ende rregulla sinkronizimi, një radhë, trajtim konfliktesh dhe sjelljen e duhur të API-t.

Ndërsa një aplikacion rritet, sinkronizimi meriton shpesh një shtresë të vetën. Një motor sinkronizimi ndjek veprimet në pritje dhe vendos kur ato nisin. Ai zotëron edhe ripërpjekjet, kontrollet e versionit dhe përgjigjet ndaj konflikteve. Mbajeni larg ekraneve të veçanta, sepse përndryshe çdo veçori rrit kopjen e vet. Një motor i vetëm testohet më lehtë, sepse ekipi simulon lidhje të rëna, thirrje të përsëritura dhe konflikte.

Testimi dhe monitorimi

Sjellja offline në aplikacione mobile SaaS do teste që imitojnë jetën reale. Për shembull, prisni lidhjen në mes të sinkronizimit. Dërgoni të njëjtin veprim dy herë. Ndryshoni një regjistrim në dy vende. Mbyllni me forcë aplikacionin kur radha është plot.

Këto teste nxjerrin defekte që testimi online i tregon rrallë. Për më tepër, ato ndërtojnë besim se aplikacioni do të mbajë në terren.

Pas nisjes, ekipi duhet ta ketë ende syrin te sinkronizimi. Matje të dobishme janë shkalla e suksesit, numri i ripërpjekjeve, madhësia e radhës, shkalla e konflikteve dhe koha e sinkronizimit. Një radhë që rritet tregon një dështim të backend-it ose një defekt sinkronizimi. Po ashtu, një kërcim i konflikteve zbulon një ndryshim në mënyrën si punojnë njerëzit. Regjistrat duhet të mbajnë detaje të mjaftueshme për të gjurmuar një dështim, por të lënë jashtë të dhënat personale.

Gabime të zakonshme

Një gabim i zakonshëm është trajtimi i punës offline si problem cache-i. Një cache shfaq të dhëna të vjetra, por nuk pranon shkrime.

Një tjetër është dërgimi i regjistrimeve të plota gjatë sinkronizimit, që shkel mbi ndryshime të bëra gjetiu. I treti është ripërpjekja pa asnjë idempotencë. I katërti është besimi te orët e pajisjeve, sepse ato zhvendosen dhe nuk pajtohen.

Së fundi, shumë ekipe që ndërtojnë aplikacione mobile e ngjisin mbështetjen offline në fund. Deri atëherë logjika e aplikacionit varet nga thirrje të gjalla kudo. Planifikimi i hershëm i sjelljes offline e mban dizajnin të pastër dhe ul rishkrimin e mëvonshëm.

Si i ndërton Square aplikacione mobile

Square Software ndërton produktet e veta softuerike dhe merr përsipër punë outsourcing për ekipe që duan aplikacione mobile SaaS të besueshme. Tarifat tona shkojnë 35-55 EUR/orë. Të njëjtat rregulla vlejnë në gjithë stekën. Aty hyjnë ruajtja lokale, dizajni i API-t, rrjedha e sinkronizimit dhe trajtimi i konflikteve.

Një partner ndihmon ta vërë themelin para se puna offline të bëhet e vështirë për t'u shtuar. Me pak fjalë, kjo do të thotë zgjedhja e depos lokale, formësimi i API-ve të qëndrueshme, hartimi i ciklit të sinkronizimit dhe rënia dakord për politikat e konfliktit. Mund të vlerësoni çmimin e një ndërtimi ose të na shkruani për ta biseduar.

Përfundim

Dizajni offline-first i mban aplikacione mobile SaaS të përdorshme kur rrjeti dështon. Ai ndërthur ruajtjen lokale, një radhë, API idempotente, një cikël sinkronizimi dhe rregulla të qarta konflikti.

SQLite dhe WatermelonDB japin themelin lokal. Radhët mbajnë veprimet e përdoruesve derisa serveri të bëhet i arritshëm. Pikat fundore idempotente i ndalin ripërpjekjet të dyfishojnë regjistrimet. Së fundi, versionet dhe politikat e bashkimit i sjellin të dyja anët në një vijë.

Rezultati është më shumë se një mënyrë offline. Është një produkt SaaS i ndërtuar për mënyrën si sillen vërtet rrjetet mobile. Për një biznes, ajo besueshmëri shfaqet si besim dhe si punë që nuk humbet kurrë.

Arkitektura offline-first në aplikacione mobile SaaS: sinkronizimi, konfliktet dhe sinjali i dobët