Телефонот постојано го губи сигналот. Затоа секоја мобилна SaaS апликација мора да работи и кога мрежата ќе падне. Корисниците и понатаму ги бараат своите податоци. Освен тоа, сакаат да ја завршат задачата пред себе.

Мобилна SaaS апликација може да ги испрати тие промени подоцна, штом сигналот ќе се врати. Како резултат, производот делува сигурно, а не кревко. Тоа ја намалува и фрустрацијата што ја создава слабата мрежа.

За тимовите што градат мобилни SaaS алатки, работата без мрежа не е додаток. Напротив, таа спаѓа во дизајнот од првиот ден.

Што значи офлајн-прв дизајн

Офлајн-првиот дизајн го третира телефонот како вистински дом за податоците. Наместо да го вика серверот при секој допир, апликацијата го чува на уредот тоа што ѝ треба. Прво чита од локалното складиште. Потоа разговара со серверот кога мрежата дозволува.

Ова го превртува вообичаениот однос меѓу апликацијата и нејзиниот бекенд. Серверот останува главен, но уредот може сам да се справи со многу задачи.

Моделот добро ѝ одговара на секоја мобилна SaaS апликација, зашто корисниците живеат со нерамномерен сигнал. На пример, отвораат апликации во воз, во лифт, во подрум или во преполна сала.

Обичната апликација покажува вртелешка штом сигналот ќе умре. Офлајн-првата апликација и понатаму ги прикажува кешираните податоци и прима внес. Таа разлика е важна, зашто луѓето го оценуваат софтверот според неговото однесување во тежок ден.

Зошто мобилниот SaaS има потреба од офлајн работа

Мобилните SaaS алатки носат работа што никој не може да ја одложи. Трговски претставници, возачи, теренски инженери и екипи на градилиште зависат од уредот цел ден. Мртвата зона го прекинува тој тек во најлош момент. Корисниците потоа губат што напишале или повторуваат чекор зашто не го гледаат резултатот.

Офлајн-првиот дизајн го одвојува однесувањето на апликацијата од состојбата на мрежата. Апликацијата ја прима промената сега и ја испраќа подоцна. Се подобрува и брзината, зашто локалните податоци се појавуваат веднаш.

Сепак, моделот носи нови проблеми. Тимовите мора да одлучат кои податоци живеат на уредот, како промените се редат и како тече синхронизацијата. Најтешкото прашање е конфликтот: и телефонот и серверот можат да го изменат истиот запис додека се одвоени.

Локалното складирање е темелот

Локалното складирање е темелот на секоја офлајн-прва мобилна SaaS апликација. Тоа му дозволува на телефонот да држи уредни, типизирани податоци без повик до серверот. За повеќето производи, мала база на податоци победува обично складиште со клуч и вредност. Базата многу ги олеснува прашалниците, индексите, врските меѓу записите и големите множества.

SQLite е вообичаениот избор на телефон. Тоа е мал релациски мотор што седи директно на уредот, а тимот зад него објаснува каде моторот се вклопува и каде не.

Тимовите можат да ги кешираат записите што корисниците ги допираат најмногу. Апликацијата потоа ги чита без ниту едно барање. Локалните запишувања работат на ист начин. Корисникот може да додаде или да измени запис додека е офлајн, а апликацијата ја чува таа промена додека синхронизацијата не тргне.

Избор на тоа што останува на уредот

Офлајн-првиот пристап не значи копирање на целиот бекенд на секој телефон. Тој пристап троши простор и го зголемува ризикот за приватноста.

Наместо тоа, изберете ги податоците што им се навистина потребни на корисниците без врска. Во повеќето апликации тоа се скорешните записи, отворените задачи, основните податоци за сметката и сето што го бара тековната работа.

Политиките за кеш можат да се разликуваат по категорија. На пример, честите записи може да останат со недели, додека ретките брзо испаѓаат. Чувствителните редови бараат дополнително внимание, зашто уредот сега е уште едно место каде што стојат деловни податоци. Старите редови треба да истечат, за да не расте локалното складиште без граница.

Редица за офлајн дејства

Локалните податоци решаваат само половина од проблемот. Апликацијата бара и сигурен начин да ги задржи дејствата направени офлајн. Редицата ја врши таа работа. Наместо веднаш да испука повик до API, апликацијата го запишува дејството во локална листа.

На пример, корисникот менува запис за клиент додека е офлајн. Апликацијата ја зачувува измената и додава ставка за синхронизација во редицата. Потоа, кога сигналот ќе се врати, таа ја обработува листата по ред.

Секоја ставка треба да носи доволно детали за повторно да се изведе дејството: типот, идентификаторот на записот, содржината, времето и уникатен код.

Редицата бара и повторни обиди, зашто краток прекин на мрежата не смее да отфрли дејство на корисникот. Сепак, повторните обиди носат нов ризик. Поточно, истиот повик испратен двапати може да создаде дупликат записи.

Зошто идемпотентните API се важни

Идемпотентниот повик дава ист резултат без оглед колку често се извршува. Тоа својство станува клучно штом уредот ќе почне да повторува.

На пример, замислете мобилна SaaS апликација што создава нарачка додека е офлајн. Таа се поврзува и го испраќа повикот, но врската умира пред да пристигне одговорот. Апликацијата не може да знае дали серверот ја примил нарачката. Затоа мора да проба повторно.

Без заштита, тој повторен обид создава втора нарачка. Со идемпотентна крајна точка, серверот го препознава првиот повик и го враќа истиот резултат. Вообичаената заштита е уникатен идентификатор на дејството од клиентот. Серверот го чува тој код покрај записот што го создал.

HTTP има име за ова својство, а RFC 9110 одредува кои методи го носат. Шаблонот помага далеку над офлајн работата. Освен тоа, ги штити обичните повици на нестабилна врска. Во мобилна SaaS апликација, идемпотентноста спаѓа во дизајнот на API од почеток, а не во подоцнежна закрпа.

Дизајн на циклусот за синхронизација

Синхронизацијата го спојува локалното складиште со вистината на серверот. Таа бара јасни правила за тоа што се случува кога уредот ќе се врати.

Едноставниот циклус почнува кога апликацијата ќе види жива врска. Потоа ги праќа локалните дејства што чекаат, а по тоа повлекува свежи податоци од серверот. Редоследот зависи од деловните правила. Некои тимови прво праќаат, а други прво повлекуваат.

Важно е циклусот да тече на ист начин секој пат. Предвидливиот процес е оној што тимот може да го тестира против многу видови откажување.

Синхронизацијата никогаш не смее да претпоставува стабилна врска. На пример, телефонот може да држи сигнал неколку секунди и пак да го изгуби. Поради тоа, синхронизацијата треба да тече во мали групи. Апликацијата може да ја означи секоја група што пристигнала, а сето што не успеало чека на следниот обид.

Кога клиентот и серверот се судираат

Најтешкиот дел од офлајн-првиот пристап се појавува кога две копии од ист запис се менуваат одвоено.

На пример, замислете теренски инженер и менаџер во канцеларија. Инженерот менува телефонски број на клиент додека е офлајн. Во меѓувреме менаџерот го менува истиот број во веб апликацијата. Двете измени се валидни, но системот мора да избере исход при синхронизација.

Тоа е конфликт, а правилата за него спаѓаат во дизајнот пред лансирање. Наједноставното правило е дека последното запишување победува: најновата измена по часовник или по верзија го зема записот. Лесно се сфаќа, но вистински измени можат да исчезнат.

Спојувањето на ниво на поле е поблаго. Ако едниот корисник го менува телефонскиот број, а другиот адресата, апликацијата може да ги задржи двете. Некои текови наместо тоа бараат човек. На пример, апликацијата може да ги прикаже двете верзии и да остави доверлив корисник да избере.

Ниту едно правило не одговара на секој мобилен SaaS производ. Точното правило го следи деловниот процес, па затоа прво мапирајте го тој процес.

Верзии и следење на промените

Броевите на верзии ја прават синхронизацијата многу полесна за разбирање. Секој запис на серверот носи верзија што се менува при секоја измена. Клиентот ја испраќа верзијата што ја видел последна. Серверот потоа проверува дали таа верзија е уште тековна.

Ако двете се совпаѓаат, запишувањето продолжува. Ако се разликуваат, серверот знае дека прво пристигнала друга измена. Оваа заштита спречува тивко пребришување.

Друга корисна техника е да се следат поединечни промени наместо цели записи. Клиентот го праќа дејството, а не целиот објект. Затоа се намалува шансата да прегази измени што никогаш не ги видел. Остава и јасна трага за тоа што се обидел да направи секој уред.

Дизајн за слаб сигнал

Офлајн-првиот пристап не е само за мртва врска. Повеќето корисници трпат слаб сигнал многу почесто отколку целосно отсуство на мрежа.

Телефонот може цел ден да скока меѓу Wi-Fi и мобилен интернет. Врската може и да одговори, но многу бавно. Затоа мобилна SaaS апликација треба да избегнува блокирање на екранот при секој повик. Тука се важни временските ограничувања, зашто ниту едно барање не смее да го замрзне погледот додека апликацијата чека.

Интерфејсот треба да ја каже состојбата на синхронизацијата со прости зборови. Корисниците треба да знаат дали апликацијата држи измена на уредот, дали чека во редицата или добила потврда од серверот. Јасната состојба ги спречува луѓето да го притискаат истото копче одново и одново.

И мрежните знаменца се слаб извор на вистина. Уредот може да тврди дека врската е жива додека серверот останува недостапен. MDN токму на тоа предупредува во своите белешки за својството online. Поради тоа, вистинскиот одговор од API сметајте го за посилен сигнал.

Кога синхронизацијата паѓа

Синхронизацијата може да падне од многу причини. Серверот може да одбие дејство. Врската може да умре. Податоците може веќе да не одговараат на тековните правила.

Не заслужува секое паѓање ист одговор. Кратката мрежна грешка може да остане во редицата. Сепак, трајната грешка бара друго постапување. На пример, серверот може да одбие измена зашто корисникот го изгубил правото врз тој запис. Вечното повторување на тој повик не помага никому. Апликацијата треба да го означи и да го објасни со прости зборови.

И делумната синхронизација заслужува размисла. Ако десет дејства чекаат, а седмото падне, апликацијата треба да ја знае состојбата на секое од нив. Состојбата по дејство ја спречува редицата да стане една голема непознаница.

SQLite, WatermelonDB и мотор за синхронизација

SQLite останува солиден избор за типизирани локални податоци. Неговиот релациски модел одговара на записи, врски, прашалници и безбедни запишувања. Тимот може да гради слој за синхронизација директно врз него. Тој пристап дава целосна контрола, но и става повеќе работа врз тимот.

WatermelonDB е друга опција за React Native апликации што сакаат побогат локален слој. Таа цели кон локално-прво однесување и реактивно читање, а проектот живее отворено на GitHub.

Ниту една база на податоци сама не создава офлајн-прв дизајн. На тимовите и понатаму им требаат правила за синхронизација, редица, справување со конфликти и точно однесување на API.

Како што расте апликацијата, синхронизацијата често заслужува свој слој. Моторот за синхронизација ги следи дејствата што чекаат и одлучува кога тие се извршуваат. Тој ги држи и повторните обиди, проверките на верзии и одговорите при конфликт. Држете го одвоен од поединечните екрани, зашто инаку секоја функција ќе добие своја копија. Еден мотор е полесен за тестирање, зашто тимот може да симулира прекинати врски, повторени повици и конфликти.

Тестирање и следење

Офлајн однесувањето во мобилна SaaS апликација бара тестови што го имитираат вистинскиот живот. На пример, прекинете ја врската среде синхронизација. Испратете го истото дејство двапати. Изменете еден запис на две места. Затворете ја апликацијата додека редицата е полна.

Овие тестови откриваат дефекти што онлајн тестирањето ретко ги покажува. Освен тоа, градат доверба дека апликацијата ќе издржи на терен.

По лансирањето, тимот и понатаму треба да ја гледа синхронизацијата. Корисни мерки се стапката на успех, бројот на повторни обиди, големината на редицата, стапката на конфликти и времето на синхронизација. Редица што расте може да покаже дека паднал бекендот или дека има бубачка во синхронизацијата. Слично, скок во конфликтите може да открие промена во начинот на кој луѓето работат. Записниците треба да носат доволно детали за да се следи паѓање, но да изостават лични податоци.

Чести грешки

Честа грешка е офлајн работата да се третира како проблем со кеш. Кешот може да прикаже стари податоци, но не прима запишувања.

Друга грешка е праќање цели записи при синхронизација, што ги гази измените направени на друго место. Трета е повторување без никаква идемпотентност. Четврта е доверба во часовниците на уредите, зашто тие се разминуваат и не се согласуваат.

Конечно, многу тимови за мобилен SaaS ја прикачуваат офлајн поддршката на крајот. Дотогаш логиката на апликацијата зависи од живи повици насекаде. Раното планирање на офлајн однесувањето го држи дизајнот чист и го намалува подоцнежното преработување.

Како Square гради мобилен SaaS

Square Software гради сопствени софтверски производи и презема аутсорсинг работа за тимови на кои им треба сигурна мобилна SaaS апликација. Нашите цени се движат од 35 до 55 EUR на час. Истите правила важат низ целиот стек: локално складирање, дизајн на API, тек на синхронизација и справување со конфликти.

Партнер може да помогне да се постави темелот пред офлајн работата да стане тешка за додавање. Накратко, тоа значи избор на локалното складиште, обликување отпорни API, скицирање на циклусот за синхронизација и договор за правилата при конфликт. Можете да пресметате цена за изработка или да стапите во контакт за да разговараме.

Заклучок

Офлајн-првиот дизајн ја држи мобилната SaaS апликација корисна кога мрежата паѓа. Тој спојува локално складирање, редица, идемпотентни API, циклус за синхронизација и јасни правила за конфликти.

SQLite и WatermelonDB го даваат локалниот темел. Редиците ги држат дејствата на корисникот додека серверот не стане достапен. Идемпотентните крајни точки спречуваат повторните обиди да ги удвојат записите. Конечно, верзиите и правилата за спојување ги враќаат двете страни во склад.

Резултатот е повеќе од офлајн режим. Тоа е мобилен SaaS производ граден за начинот на кој навистина се однесуваат мобилните мрежи. За бизнисот, таа сигурност се гледа како доверба и како работа што никогаш не се губи.

Офлајн-прв дизајн во мобилна SaaS апликација: синхронизација и конфликти