Vývoj mobilných aplikácií: Synchronizácia so serverom. Vývoj back-endu mobilných aplikácií Vytvorenie back-endu aplikácie

Offline v minulosti, byť online dnes je nevyhnutnosťou. Aspoň pre moderný svet podnikania. Prezentácie produktov a služieb značiek, online objednávanie a doručovanie, udržiavanie zákazníckej základne, komunikácia so zákazníkmi a mnoho iného - to všetko je jednoducho nemožné bez prítomnosti na internete. Ak potrebujete aplikáciu, musíte mať front-end (webové rozhranie) aj back-end (serverová strana vašej aplikácie). A ak chcete mať možnosť upravovať obsah svojej aplikácie bez účasti vývojárov, potrebujete dobrý admin panel.

Kým Front-end v guli mobilné aplikácie vytvorený pomocou technológií ako X-Code a Java, Back-end, kde bude uložená databáza a celá aplikačná logika, si vyžaduje profesionálne znalosti programovacieho jazyka na strane servera. dobrý príklad je PHP, čo je snáď najpopulárnejší programovací jazyk, ktorý sa používa na vývoj takmer akéhokoľvek back-endu. Toto je nesporný vodca.

Aplikácií pre PHP je veľa: statické a dynamické webové stránky + redakčné systémy na mieru, sociálne siete, špecializované CRM systémy, softvér pre elektronický obchod a mnohé ďalšie. Samozrejmosťou sú bezplatné alebo lacné serverové diely a ovládacie panely. V mnohých prípadoch však neposkytujú potrebnú úroveň pohodlia, prispôsobenia a upgradovateľnosti.

Naši programátori pracujú s technológiami, ktoré nám umožňujú implementovať široké spektrum riešení pre rôzne obchodné ciele, potreby a požiadavky. Analyzujeme Požiadavky na systém pre každý projekt individuálne a používame rôzny špecializovaný serverový softvér pre optimálny výkon vašej mobilnej aplikácie.

Ak hľadáte tím, ktorý vás dovedie k najinteligentnejšiemu a najefektívnejšiemu riešeniu na vytvorenie aplikácie od začiatku alebo na obnovenie existujúcej aplikácie pre dokonalý používateľský zážitok, už nehľadajte. Appsmob je pripravený pomôcť vám nájsť najlepšie riešenie Pre teba.

Vývoj serverovej časti aplikácie klient-server začína návrhom architektúry. Veľa závisí od architektúry: od rozšíriteľnosti aplikácie až po jej výkon a jednoduchosť podpory/údržby.

V prvom rade by ste si mali určiť, ako budú dáta umiestnené na serveri a ako budú spracovávané požiadavky prichádzajúce od klienta. Je tiež potrebné myslieť na organizáciu ukladania údajov do vyrovnávacej pamäte na strane servera.

Je potrebné rozhodnúť o protokoloch výmeny údajov a formátoch prenosu údajov.

API (application programming interface) - aplikačné programovacie rozhranie. V zrozumiteľnejšom jazyku ide o súbor požiadaviek na server, ktorému server rozumie a môže dať správnu odpoveď. Rozhranie API definuje funkčnosť serverovej logiky, zatiaľ čo rozhranie API vám umožňuje abstrahovať, ako je táto funkcia implementovaná. Inými slovami, API je nevyhnutnou súčasťou celkovej infraštruktúry klient-server.

Porovnajte JSON a XML. Uveďte príklad protokolov v závislosti od typu aplikácie.

Multithreading

Jedným z kľúčových aspektov moderného programovania je multithreading. Pomocou multithreadingu môžeme v aplikácii oddeliť niekoľko vlákien, ktoré budú vykonávať rôzne úlohy súčasne.

Multithreading je vlastnosť platformy (napríklad operačného systému, virtuálneho stroja atď.) alebo aplikácie, v ktorej proces vytvorený v operačnom systéme môže pozostávať z niekoľkých vlákien vykonávajúcich „paralelne“, teda bez predpísaného objednať v priebehu času.

Podstatou multithreadingu je kvázi-multitasking na úrovni jedného spustiteľného procesu, to znamená, že všetky vlákna sú vykonávané v adresnom priestore procesu. Okrem toho všetky vlákna procesu majú nielen spoločný adresný priestor, ale aj spoločné deskriptory súborov. Bežiaci proces má aspoň jedno (hlavné) vlákno.

Multithreading (ako programovacia doktrína) by sa nemal zamieňať s multitaskingom alebo multiprocessingom, aj keď operačné systémy, ktoré implementujú multitasking, majú tendenciu implementovať aj multithreading.

Medzi výhody multithreadingu v programovaní patria:

Zjednodušenie programu v niektorých prípadoch použitím spoločného adresného priestoru.

Menej času stráveného vytváraním vlákna v porovnaní s procesom.

Zlepšenie výkonu procesov paralelizáciou výpočtov procesora a I/O operácií.

Prietok(vlákno) je riadená jednotka spustiteľného kódu. V prostredí multitaskingu na báze vlákien majú všetky spustené procesy nevyhnutne hlavné vlákno, ale môže ich byť viac. To znamená, že jeden program môže asynchrónne spúšťať viacero úloh. Napríklad úprava textu v textovom editore počas tlače, pretože tieto dve úlohy sa vykonávajú v rôznych vláknach.

Na bežnom procesore sa o správu vlákien stará operačný systém. Vlákno sa vykonáva, kým nedôjde k hardvérovému prerušeniu, systémové volanie alebo do uplynutia času, ktorý na to operačný systém prideľuje. Potom sa procesor prepne na kód operačného systému, ktorý uloží stav vlákna (jeho kontext) alebo sa prepne do stavu iného vlákna, ktorému je tiež pridelený čas na vykonanie. Pri takomto multithreadingu to stačí veľké množstvo Cykly CPU sa vynakladajú na kód operačného systému, ktorý prepína kontexty. Ak je podpora vlákien implementovaná v hardvéri, potom samotný procesor bude môcť prepínať medzi vláknami a v ideálnom prípade vykonávať niekoľko vlákien súčasne pre každý cyklus hodín.

- Dočasné multithreading (jedno vlákno)

– Simultánne multithreading (viac vlákien súčasne)

Multithreading, ako rozšírený model programovania a vykonávania kódu, umožňuje beh viacerých vlákien v rámci jedného procesu. Tieto vlákna vykonávania zdieľajú prostriedky procesu, ale môžu bežať aj samostatne. Viacvláknový programovací model poskytuje vývojárom pohodlnú abstrakciu paralelného vykonávania. Asi najzaujímavejšia aplikácia technológie je však tá, keď je aplikovaná na jeden proces, čo umožňuje jej paralelné vykonávanie na viacprocesorovom systéme.

Táto výhoda viacvláknového programu mu umožňuje bežať rýchlejšie počítačové systémy, ktoré majú viacero procesorov, procesor s viacerými jadrami alebo na klastri strojov – vďaka tomu, že vlákna vykonávania programov sa prirodzene hodia na skutočne paralelné vykonávanie procesov. V tomto prípade musí byť programátor veľmi opatrný, aby sa vyhol rasovým podmienkam a inému neintuitívnemu správaniu. Aby bolo možné správne manipulovať s údajmi, vlákna vykonávania musia často prejsť postupom stretnutia, aby sa údaje spracovali v správnom poradí. Vlákna vykonávania môžu tiež potrebovať mutexy (ktoré sa často implementujú pomocou semaforov), aby sa zabránilo tomu, že zdieľané údaje budú súčasne modifikované alebo čítané počas procesu modifikácie. Neopatrné používanie takýchto primitív môže viesť k patovej situácii.

Ďalším využitím multithreadingu, dokonca aj pre jednoprocesorové systémy, je schopnosť aplikácie reagovať na vstup. Ak je v jednovláknových programoch vykonávanie hlavného vlákna zablokované vykonávaním dlho trvajúcej úlohy, celá aplikácia môže byť v zmrazenom stave. Presunutím takýchto dlhotrvajúcich úloh do pracovného vlákna, ktoré beží paralelne s hlavným vláknom, je možné, aby aplikácie naďalej reagovali na vstup používateľa, kým sú úlohy spustené pozadie. Na druhej strane, vo väčšine prípadov multithreading nie je jediným spôsobom, ako udržať program responzívny. To isté možno dosiahnuť prostredníctvom asynchrónnych I/O alebo signálov v systéme UNIX.

Existujú dva typy multitaskingu: procesne založené A založené na prúde. Rozdiely medzi multitaskingom založeným na procesoch a multitaskingom na báze vlákien sú nasledovné: multitasking založený na procesoch je organizovaný na paralelné vykonávanie programov a multitasking na báze vlákien je na paralelné vykonávanie jednotlivých častí jedného programu.

Existujú dva typy streamov:

Vlákna v popredí alebo popredie. Štandardne sa každé vlákno vytvorené pomocou metódy Thread.Start() automaticky stane vláknom v popredí. Tento typ vlákna poskytuje ochranu aktuálnej aplikácie pred ukončením. Spoločný jazykový modul runtime nezastaví aplikáciu, kým sa nedokončia všetky vlákna v popredí.

Vlákna pozadia. Tento typ vlákna, tiež známe ako vlákna démonov, sú modulom spoločného jazyka spracovávané ako rozšíriteľné cesty vykonávania, ktoré možno kedykoľvek ignorovať. Ak sa teda ukončia všetky vlákna na popredí, všetky vlákna na pozadí sa automaticky zastavia, keď sa uvoľní doména aplikácie. Ak chcete vytvoriť vlákna na pozadí, musíte nastaviť vlastnosť IsBackground na hodnotu true.

Povedzte o stavoch vlákien: bežiace, pozastavené, bežiace, ale na niečo čakajúce.

Problém so synchronizáciou vlákna a zdieľané zdroje.

Interakcia vlákna

V prostredí s viacerými vláknami sa často vyskytujú problémy spojené s používaním rovnakých údajov alebo zariadení paralelne vykonávanými vláknami. Pre riešenia podobné problémy používajú sa metódy interakcie vlákien, ako sú mutexy, semafory, kritické sekcie a udalosti

Mutex je synchronizačný objekt, ktorý je nastavený do špeciálneho signalizovaného stavu, keď nie je obsadený žiadnym vláknom. V každom okamihu vlastní tento objekt iba jedno vlákno, odtiaľ názov takýchto objektov (z angl. mutually exclusive access – vzájomne exkluzívny prístup) – simultánny prístup k zdieľanému zdroju je vylúčený. Po všetkých potrebných akciách sa mutex uvoľní, čím sa ostatným vláknam poskytne prístup k zdieľanému prostriedku. Objekt môže podporovať rekurzívne zachytenie druhýkrát tým istým vláknom, čím sa zvýši počítadlo bez zablokovania vlákna a potom sa vyžaduje viac vydaní. Taká je napríklad kritická časť vo Win32. Existujú však niektoré implementácie, ktoré to nepodporujú a spôsobujú uviaznutie vlákna pri pokuse o rekurzívne zachytenie. Toto je FAST_MUTEX v jadre Windows.

semafory predstavujú dostupné zdroje, ktoré je možné získať viacerými vláknami súčasne, kým sa fond zdrojov nevyprázdni. Potom musia ďalšie vlákna čakať, kým nebude opäť dostupné požadované množstvo zdrojov. Semafory sú veľmi efektívne, pretože umožňujú súbežný prístup k zdrojom.

Vývoj. Objekt, ktorý uchováva 1 bit informácie „signalizovaný alebo nie“, na ktorom sú definované operácie „signál“, „reset do nesignalizovaného stavu“ a „čakanie“. Čakanie na signalizovanú udalosť je absencia operácie s okamžitým pokračovaním vykonávania vlákna. Čakanie na nesignalizovanú udalosť spôsobí pozastavenie vykonávania vlákna, kým iné vlákno (alebo druhá fáza obsluhy prerušenia v jadre OS) túto udalosť nesignalizuje. V režime „akýkoľvek“ alebo „všetky“ je možné čakať na niekoľko udalostí. Je tiež možné vytvoriť udalosť, ktorá sa po prebudení prvého - a jediného - čakajúceho vlákna automaticky prestaví do nesignalizovaného stavu (takýto objekt sa používa ako základ pre implementáciu objektu "kritická sekcia"). Aktívne sa používa v MS Windows, v užívateľskom režime aj v režime jadra. V jadre Linuxu existuje podobný objekt s názvom kwait_queue.

Kritické úseky poskytujú synchronizáciu ako mutexy, okrem toho, že objekty predstavujúce kritické sekcie sú prístupné v rámci toho istého procesu. Udalosti, mutexy a semafory možno použiť aj v jednoprocesovej aplikácii, avšak implementácia kritických sekcií v niektorých operačných systémoch (napríklad Windows NT) poskytuje rýchlejší a efektívnejší mechanizmus vzájomne sa vylučujúcej synchronizácie – získavanie a uvoľňovanie operácie na kritickej sekcii sú optimalizované pre prípad jediného vlákna (bez sporu), aby sa predišlo systémovým volaniam vedúcim k jadru OS. Podobne ako mutexy, aj objekt predstavujúci kritickú sekciu môže súčasne používať iba jedno vlákno, vďaka čomu sú mimoriadne užitočné pri obmedzovaní prístupu k zdieľaným zdrojom.

Podmienkové premenné(condvars). Podobne ako udalosti, ale nie sú to objekty, ktoré zaberajú pamäť – používa sa len adresa premennej, pojem „obsah premennej“ neexistuje, ako podmienková premenná sa dá použiť adresa ľubovoľného objektu. Na rozdiel od udalostí nastavenie premennej podmienky na signalizovaný stav nemá žiadne dôsledky, ak na premennú momentálne nečakajú žiadne vlákna. Nastavenie udalosti v podobnom prípade znamená uloženie „signalizovaného“ stavu v samotnej udalosti, po ktorom nasledujúce vlákna, ktoré chcú čakať na udalosť, pokračujú v vykonávaní okamžite bez zastavenia. Na plné využitie takéhoto objektu je potrebná aj operácia „uvoľnite mutex a počkajte na premennú podmienky atomicky“. Aktívne sa používa v operačných systémoch podobných UNIX. Diskusie o výhodách a nevýhodách udalostí a stavových premenných sú významnou súčasťou diskusií o výhodách a nevýhodách Windows a UNIX.

Port na dokončenie I/O(port dokončenia IO, IOCP). Implementovaný v jadre OS a prístupný prostredníctvom systémových volaní, objekt „front“ s operáciami „umiestniť štruktúru na koniec frontu“ a „vziať ďalšiu štruktúru z hlavy frontu“ – posledné volanie pozastaví vykonávanie vlákna, ak je front prázdny, a kým žiadne iné vlákno nezavolá put. Najdôležitejšou vlastnosťou IOCP je, že štruktúry do neho môžu byť umiestnené nielen explicitným systémovým volaním z užívateľského režimu, ale aj implicitne vo vnútri jadra OS v dôsledku dokončenia asynchrónnej I/O operácie na jednom zo súborov. deskriptory. Na dosiahnutie tohto efektu musíte použiť systémové volanie „priradiť deskriptor súboru k IOCP“. V tomto prípade štruktúra umiestnená vo fronte obsahuje kód chyby I/O operácie av prípade úspechu tejto operácie aj počet skutočne zadaných alebo výstupných bajtov. Implementácia dokončovacieho portu tiež obmedzuje počet vlákien vykonávaných na jednom procesore/jadre po prijatí štruktúry z frontu. Objekt je špecifický pre MS Windows a umožňuje spracovanie prichádzajúcich požiadaviek na pripojenie a dátových blokov v serverovom softvéri v architektúre, kde počet vlákien môže byť menší ako počet klientov (neexistuje požiadavka na vytvorenie samostatného vlákna so zdrojom náklady na každého nového klienta).

Závitový bazén

Povedzte o fonde vlákien

Naša spoločnosť ponúka služby pre tvorbu serverovej časti mobilných biznis aplikácií a klientskych webových služieb pracujúcich vo vysoko zaťažených prostrediach. Pri vývoji každého projektu sa snažíme uplatňovať individuálny prístup tak, aby sa výsledný produkt stal čo najviac optimálne riešenie konkrétne ciele zákazníkov.

Ak používate komplexnú aplikáciu, ktorá ukladá a/alebo spracováva dáta na serveri, potom je podporovaná Back-endom – softvérovým balíkom hosteným na webovom serveri a pracujúcim s aplikáciou, ktorá sa v tomto prípade nazýva Front- koniec. Aplikácia hosťovaná na serveri môže pracovať súčasne s veľkým počtom klientov, čo kladie požiadavky na vysokú rýchlosť a bezpečnosť jej prevádzky.

Často je napísaná serverová strana aplikácie jazyk PHP, ako najobľúbenejšie pre takéto riešenia. Na implementáciu jednoduchých serverových úloh možno použiť štandardné systémy, ale pre konkrétnejšie je už potrebné vyvinúť vlastné riešenie alebo nadstavby nad štandardné systémy.

Princípy vývoja servera pre mobilnú aplikáciu

Naši programátori pracujú s technológiami, ktoré umožňujú implementáciu veľký rozsah riešenia pre akékoľvek, aj veľmi vysoké zaťaženie a rôzne smery. Pre jednotlivé úlohy vytvárame aj samostatné serverové riešenia.

Organizačná kontrola

Každý projekt vytvára samostatná skupina špecialistov zodpovedných za všetky fázy vývoja a dodanie projektu načas.

Programovanie

Návrh architektúry servera je najdôležitejším krokom, počas ktorého sa vytvárajú databázy a vytvárajú potrebné algoritmy.

Testovanie

Softvérová časť by mala fungovať bez chýb a zlyhaní. Za to zodpovedajú testeri, ktorí vykonávajú overovanie systému.

Technická podpora

Naši zamestnanci vykonávajú plnohodnotnú technickú podporu programov, ktorá umožňuje rýchle odstraňovanie nedostatkov a vykonávanie aktualizácií.

Funkcie vývoja

Na kompetentný vývoj serverovej časti aplikácie sú potrebné určité zručnosti a znalosti programovacieho jazyka používaného na serveri. Ako ukazuje prax, klient serverové aplikácie vytvorený v PHP. Je nesporným lídrom v tejto oblasti. Viac ako polovica stránok na svete je napísaná v PHP, je to pohodlné pre vývoj a podporu.

rámec

Táto softvérová platforma vám umožňuje urobiť projekt škálovateľnejším a flexibilnejším. Napriek tomu by mal byť rámec zvolený čo najsprávnejšie, preto je potrebná hĺbková analýza pracovnej dokumentácie projektu, ktorá následne pomôže vyvinúť vysokokvalitný produkt.

Na vývoj back-endu sa používajú aj iné jazyky. Napríklad serverové aplikácie vytvorené v Prostredie Delphi. Vďaka tomu program zlepšil ladenie. Navyše sa ľahšie rozvíja unikátne programy, poskytuje vizuálnu tvorbu. To všetko vám umožňuje vytvoriť jasné a pohodlné rozhranie.

Serverové aplikácie Java nie sú o nič menej populárne. Ľahko sa dopĺňajú, ľahko sa vykonávajú na rôznych platformách a majú vysokú úroveň zabezpečenia.

Ďalší bežne používaný jazyk. S ním sa serverové aplikácie vytvárajú jednoducho, rýchlo a bez ďalších nákladov.

Takmer všetky moderné spoločnosti majú svoje virtuálne sídla. Webová stránka môže byť buď vizitka, prípadne portál či online katalóg s možnosťou zadávania objednávok.

Obchodné procesy v tomto prípade závisia od webových serverov, konkrétne od ich schopnosti odolávať útokom, pokusom o hackerstvo a externých negatívne dopady, ako aj výkon dostatočný na mnohé simultánne požiadavky.

Etapy vývoja webových služieb

Pri vytváraní aplikácií pre rôzne segmenty trhu organizujeme našu prácu podľa jediného princípu – rozdeľujeme celý proces jednotlivé kroky, o ktorých priebehu a výsledkoch sú informovaní zákazníci. Server pre mobilnú aplikáciu je teda vyvíjaný rovnakým spôsobom.

1. Vývoj nápadu

Do 2 týždňov

V tejto fáze sa vytvára základ, ktorý dáva predstavu o tom, čo bude stanovené a akým smerom sa bude rozvíjať.

2. Hodnotenie projektu

2-3 týždne

Naši odborníci vyhodnotia čas a cenu prác, následne sa vypracuje predbežný návrh rozvoja.

3. Podmienky a zmluvné podmienky

Do 2 týždňov

Po prerokovaní všetkých nuancií procesu so zákazníkom a vypracovaní podrobného TOR sa pripraví a podpíše zmluva.

4. Vývoj rozhrania

2-3 týždne

Dizajnéri sú zodpovední za vytváranie rozhraní potrebných pri písaní programových modulov.

6. Testovanie

2-3 týždne

Komplexné overovanie prijatých softvérové riešenie vytvorené testermi prostredníctvom súboru vhodných nástrojov.

7. Dokončenie projektu

Do 2 týždňov

V dohodnutom termíne je zákazníkovi odovzdaná hotová, dôkladne otestovaná webová služba.

náš tím

Prostredníctvom analýzy obchodných aktivít a potrieb našich zákazníkov vytvárame reálne produkty, ktoré pomáhajú riešiť celý rad obchodných problémov. Použitie moderné technológie poskytuje široké možnosti implementácie serverového softvéru, ktorý zaručuje vysoký výkon príslušných mobilných aplikácií. Náš tím reprezentujú:

Projektoví manažéri

Títo zamestnanci komunikujú s klientmi aj vývojármi a zabezpečujú medzi nimi komunikáciu. Monitorujú implementáciu už plánovaných akcií a potrebných zlepšení.

Dizajnéri

Pri svojej práci naši špecialisti zohľadňujú požiadavky na budovanie rozhraní pre operačné systémy iOS a Android, takže vydané aplikácie fungujú správne na rôznych zariadeniach.

Vývojári

Aby sa optimalizoval výkon mobilných aplikácií, programátori analyzujú ich systémové požiadavky a vytvárajú špecializovaný serverový softvér.

Testeri

Dôkladné testovanie je zárukou kvality hotového výrobku a zárukou bezpečnosti uchovávaných a spracovávaných údajov. Títo špecialisti používajú rôzne nástroje a efektívnu metodiku.

Aké služby vytvárame

Keďže ide o softvér zabudovaný do stránky alebo nezávislý program, webová služba sa používa na vykonávanie úloh súvisiacich s reklamou, analýzou, obchodným plánovaním a propagáciou. V tejto súvislosti je potrebné rozhodnúť, aký typ zdroja bude najlepším riešením.

Informačné projekty

Navrhnuté tak, aby vyhovovali rôznorodému obsahu.

Tematické stránky

Takmer všetky ich stránky sú venované jednej téme. Dopyt po nich je stále dosť vysoký.

spravodajské stránky

Informujú o rôznych novinkách v rámci jednej alebo viacerých tém, reflektujúcich hlavné oblasti života.

Blogy

Úroveň popularity týchto zdrojov neustále rastie. Podobne ako spravodajské stránky sprostredkúvajú internetovej komunite tú či onú informáciu, no v tomto prípade autori vyjadrujú svoj osobný názor.

Sociálne projekty

Patria sem špecializované sociálne siete, komunity, fóra atď.

fóra

Vytvorené na diskusiu o rôznych novinkách, produktoch / službách atď. Môžu byť úzko zamerané a rôznorodé.

Sociálne médiá

Tieto zdroje majú mnohomiliónové publikum. Ich hlavnou úlohou je poskytnúť používateľom internetu možnosť komunikovať online prostredníctvom textových / hlasové správy a video komunikácie.

Rôzne webové služby

Prijaté dnes široké využitie, sú rozdelené do niekoľkých typov.

Katalógy

Poštové služby

Poskytnite používateľom všetky funkcie a výhody Email vrátane prezerania, odosielania, úpravy listov a dokumentov atď.

Vyhľadávače

Používajú sa na vyhľadávanie stránok a rôznych informácií o konkrétnych požiadavkách.

Nástenky

Ide o webové zdroje, kde používatelia siete umiestňujú svoje inzeráty na predaj a nákup služieb v rámci rôznych tém.

Hosting stránok

Určené na dočasné ukladanie súborov. Niektoré z nich poskytujú možnosť zoznámiť sa s údajmi pred stiahnutím.

FAQ

Nižšie ponúkame odpovede na otázky, ktoré často kladú naši špecialisti. Ak tu nenájdete informácie, ktoré hľadáte, zverejnite svoju otázku tu. formulár a my na to určite odpovieme.

Ako dlho môže trvať vytvorenie aplikácie a webového servera?

V priemere táto práca trvá od 9 do 20 týždňov. Všetko závisí od zložitosti vykonávanej úlohy.

ZÁLOHY

Prečo sú potrebné zálohy na mobilnej platforme

Odborníci vedia, aké nespoľahlivé sú niekedy mobilné aplikácie 1C: kedykoľvek sa môžu vyskytnúť chyby, v dôsledku ktorých sa používateľské základne jednoducho zrútia. Zároveň sa stretávame s nespoľahlivosťou samotných zariadení: môžu sa rozbiť, stratiť, ukradnúť a používatelia si chcú svoje dáta ponechať. A až do verzie 8.3.9 sme nemali mechanizmus zálohovania platformy.

Keďže používatelia predtým nemali tlačidlo „uložiť kópiu“, vývojári aplikácie Boss museli zálohovať sami. ako sa nám to podarilo?

Databázové údaje ukladáme vo forme XML.

Odporúča sa ponúknuť používateľovi niekoľko možností na ukladanie kópií - v prvom rade je to výhodné pre zákazníkov, môžu si vybrať najlepšiu možnosť pre seba: nahrať do cloudu, odoslať na poštu, uložiť do zariadenia.

Vývojári sa tak dodatočne poisťujú. Ak sa niečo pokazilo a mechanizmus vytvárania kópií na Disku Google alebo na disku Yandex sa náhle pokazil, vždy môžete používateľovi povedať, že vývojár momentálne rieši chybu, ale zatiaľ môže údaje uložiť alternatívnym spôsobom. A používatelia sú spokojní, pretože môžu byť pokojní ohľadom svojich údajov.

Nevyhnutne zamerať sa na cloudové služby, pretože ak dôjde k strate alebo poškodeniu zariadenia a používateľ uloží kópiu na tom istom zariadení, údaje sa stratia.

Aj my nezabudnite používateľovi pripomenúť potrebu vytvárať zálohy.

Ako uložiť kópie, ak sa konfigurácia zmení?

Keď hovoríme o masovom riešení, o aplikácii, ktorá sa neustále mení, vyvíja a zdokonaľuje, musíme brať do úvahy správanie zákazníkov. Používateľ môže chcieť obnoviť zálohu uloženú v stará verziažiadosti, kde neboli žiadne podrobnosti. A potom vyvstáva úloha: načítať údaje, následne vyplniť údaje podľa logiky aktualizácie zo starej verzie aplikácie. Ako to spraviť? Okrem údajov si uložte aj samotnú štruktúru údajov, aby ste ich neskôr vedeli čítať.

Existuje niekoľko možností na uloženie tejto dátovej štruktúry, vrátane uloženia v samotnej konfigurácii. To znamená, že pri vydaní každej novej verzie uložte štruktúru metadát predchádzajúcej verzie v rozložení v konfigurácii.

Nezabudnite, že v mobilnej aplikácii by konfigurácia nemala rásť len tak, musíme si vážiť miesto v nej, musíme ju urobiť čo najkompaktnejšou. Ale aplikácia sa vyvíja a takýchto rozložení bude veľa a časom ich bude stále viac.

Preto je v prípade mobilnej aplikácie vhodnejší iný spôsob - uložiť štruktúru metadát priamo v dátovom súbore. Na výstupe dostaneme taký súbor, kde si najprv uložíme nejaké pomocné dáta - verziu konfigurácie, konfiguračnú schému, hranice sekvencie a následne zapíšeme samotné užívateľské dáta vo formáte XML. Okrem toho v sekcii súboru "Auxiliary data" môžete uložiť aj ďalšie dôležité údaje, ktoré z nejakého dôvodu nebolo možné zapísať do XML.

Zoberieme dátovú schému, ktorá bola uložená do súboru, a na základe nej zostavíme balík XDTO na čítanie súboru. V databáze vytvoríme podobný objekt, vyplníme ho, vykonáme dokončovacie spracovanie pri aktualizácii a hotový objekt uložíme do databázy.

Nižšie na obrázku môžete vidieť nápovedu, ako krásne napísať XDTO model týchto konfigurácií. Spoločnosť, ktorá vydala aplikáciu Boss, s tým experimentovala, našla niekoľko spôsobov, ale rozhodla sa len pre túto možnosť zápisu schémy metadát. Keď sa otvorí samotný dátový súbor, môžete vidieť obvyklé štruktúrované XML, čitateľné, v ktorom sú uvedené všetky metadáta aplikácie.

// Zápis konfiguračnej schémy XDTO Model = XDTO Factory.XDTO Model Export("http://v8.1c.ru/8.1/data/enterprise/current-config"); FactoryXDTO.WriteXML(Nahranie súboru, ModelXDTO); // Čítanie konfiguračnej schémy ModelXDTO = FactoryXDTO.ReadXML(ReadingXML, FactoryXDTO.Type("http://v8.1c.ru/8.1/xdto","Model")); Unload Factory = Nová továreň XDTO (model XDTO);

Pre ochranu používateľa je potrebné sa ho znova opýtať, či potrebuje obnoviť zálohu. Možno len experimentoval a klikal na tlačidlá na všetkom v aplikácii :) A teraz môžu prísť o jeho aktuálne dáta. Preto si pri vykonávaní potenciálne „nebezpečných“ akcií vždy ujasníme, či to naozaj chce a ako sa to má stať. Používateľ si musí byť vedomý svojich činov.

Musí existovať mechanizmus na vytváranie záloh, keď hovoríme o offline riešení, keď má používateľ všetky dáta uložené výlučne v mobilnom zariadení: používateľ môže prísť o svoje zariadenie a následne o dáta príde. A zdalo by sa, že ak aplikácia nefunguje offline, ale je pripojená k centrálnemu serveru, používateľ by nemal mať takýto problém, pretože v prípade straty zariadenia sa pripojí k serveru a dostane všetky svoje údaje od server znova a všetko bude v poriadku.

Nie vždy však užívatelia využívajú zálohy tak, ako od nich očakávame :) Veľmi často ich využívajú na to, aby dáta jednoducho „vrátili späť“. Ide naozaj o veľmi zvláštne správanie, no používatelia mobilných aplikácií sú príliš leniví na to, aby prišli na to, kde by mohli pri zadávaní údajov urobiť chybu, a jednoducho údaje vrátia späť a znova spustia údaje pre aktuálny deň. Po rozbore štatistík práce s aplikáciou Boss sme si uvedomili, že ide o bežnú prax a takéto správanie používateľov je bežnejšie, ako by sme si vedeli predstaviť.

A ak používate synchronizáciu s inými zariadeniami, musíte to spracovať. Tu je niekoľko riešení:

prerušte spojenie so serverom a uveďte, že údaje na ňom zostanú tak, ako boli, a kópia sa obnoví iba na zariadení používateľa;
pre používateľa je lepšie nechať ho obnoviť kópiu na všetkých zariadeniach naraz, keď predtým predpísal takéto mechanizmy.

Je tu ešte jeden bod. Doteraz sme si zálohy ukladali sami, kontrolovali celý proces, zachytávali akcie používateľa priamo v kóde, keď klikol na tlačidlo „uložiť kópiu“. To všetko sa dá spracovať neskôr. V platforme 8.3.9 bolo možné ukladať zálohy pomocou nástrojov platformy. A používateľ to robí bez nášho vedomia. Ak sa použije synchronizácia s centrálnou databázou, potom je potrebné takýto scenár spracovať. Na našom serveri musíme nejako zistiť, že používateľ obnovil predtým uloženú kópiu a musíme mu dať nejaké rozhodnutie. Nemôžeme si dovoliť nechať dáta nesynchronizovať.

VÝMENA

Keď hovoríme o súkromnom riešení na mobilnej platforme, väčšinou máme zákazníka, ktorý chce napríklad pre svojich obchodných zástupcov využiť mobilnú platformu a nechať si vymieňať dáta s centrálnou databázou. Všetko je tu jednoduché: jedna databáza, niekoľko zariadení, zdvihnete server, nastavíte komunikáciu s ním. Takže problém výmeny medzi zariadeniami je vyriešený jednoducho.

Ak sa ale bavíme o masovej aplikácii, kde je veľa databáz, z ktorých každá má veľa používateľov, situácia sa komplikuje. Používatelia si stiahli aplikáciu z trhu a chcú sa navzájom synchronizovať. Napríklad manžel si stiahol aplikáciu osobných financií a teraz chce, aby sa pripojila aj jeho manželka, aby mohli spolupracovať na rovnakej aplikácii. Existuje veľa používateľov, aplikácia sa vyvíja, rastie a je potrebný veľký, veľmi veľký počet databáz. Ako to všetko zorganizovať? Používatelia nebudú osobne kontaktovať vývojárov, aby im vytvorili samostatnú databázu a umožnili synchronizáciu. Chcú stlačiť tlačidlo a všetko hneď funguje. V ten istý moment.

Ako postupovať? Tu prichádza na pomoc mechanizmus separácie údajov. Umožňuje organizovať jednu databázu, kde je jedna spoločná konfigurácia, no zároveň je v rámci jednej spoločnej databázy uložený neobmedzený počet užívateľských databáz.

Najlepšie na tom je, že používateľov môžete pridávať dynamicky, programovo, bez našej účasti. V skutočnosti používatelia jednoducho kliknú na tlačidlo „zaregistrovať sa na server“ a všetko sa stane samo: na serveri sa mu vytvorí osobná databáza a môže v nej okamžite začať pracovať.

Ako to spraviť? Prvým a najjednoduchším riešením je napísať si vlastnú databázu servera s týmto mechanizmom. Keď naša spoločnosť začala robiť aplikáciu Boss a výmeny v nej, v prvej verzii sme urobili práve to: vytvorili sme serverovú databázu s mechanizmom zdieľania údajov. Všetko fungovalo, najmä preto, že nebolo nič zložité - základný oddeľovač je bežným atribútom.

Ale potom sme si uvedomili, že sme znovu vynašli koleso :) V skutočnosti už existujú riešenie na kľúč, a to už zohľadňuje momenty, na ktoré sme ani nepomysleli. Toto je 1C: Fresh.

Je tu premyslená škálovateľnosť služby: čo robiť, keď je veľa údajov a databáz, ako s tým všetkým rásť. Je tu chvíľa o tvorení zálohy dátové oblasti: to znamená, že nezálohujeme len jednu spoločnú databázu, ale vytvárame kópie konkrétneho používateľa. Navyše je tam mechanizmus taký, že kópie sa robia len vtedy, keď sú naozaj potrebné. Ak sa používateľ týždeň neprihlásil do databázy, tak mu kópie nerobíme, pretože sa tam nič nezmenilo. Ďalšou vlastnosťou Fresh je, že služba má mechanizmus na zníženie zaťaženia servera, čo je veľmi dôležité, keď máte veľa databáz.

Vo všeobecnosti je Fresh pre nás niečo nové a zaujímavé. Pomaly sa na to snažíme prísť, ale väčšinou sme s jeho prácou spokojní.

Prenos dát. Ako to implementovať na zdieľanie medzi zariadeniami

Platforma poskytuje dva mechanizmy – SOAP a http služby. Existujú nuansy, ako pristupovať k týmto službám, keď je povolený mechanizmus zdieľania údajov. Predovšetkým musíte pridať parametre, ktoré označujú konkrétne číslo sféry, do ktorej pristupujete, pretože platforma nedokáže určiť, do ktorej databázy má pristupovať z používateľského mena. Okrem toho môže ten istý používateľ pracovať s viacerými databázami v rámci jednej databázy (pozri obrázok).

Čo sa týka služieb, implementuje aplikácia Boss okamžitá výmena: Jeden používateľ zadáva údaje a druhý ich prijíma. Používatelia mobilných aplikácií sú zvyknutí, že všetko sa deje okamžite, preto sme rozmýšľali ako lepšie služby použiť - SOAP alebo http. Rýchlosť pripojenia hrala kľúčovú úlohu. V http je rýchlosť pripojenia oveľa vyššia a pri pripojení cez SOAP dostaneme popis služby, ktorý je ťažký a dlho sa načítava. Platforma má spôsob, ako uložiť popis služby, ale kvôli parametrom, ktoré pridávame dynamicky, nemôžeme použiť odkazy WS. Okrem toho je podľa našich skúseností prístup k službám http pohodlnejší a flexibilnejší.

Naším cieľom je teda implementovať výmenu v reálnom čase. To znamená, že sa snažíme, aby to nebolo tak, že používateľ musí niekam ísť, kliknúť na nejaké tlačidlo, premýšľať o tom, aké aktuálne sú jeho údaje, či ich má aktualizovať... Používatelia by mali mať údaje vždy aktuálne. randiť. Sú tak zvyknutí pracovať v messengeroch – jeden dáta odoslal, druhý ich hneď prijal. Všetko sa deje okamžite. To isté platí pre aplikácie súvisiace s obchodom: jeden predajca vystavil predaj, druhý by mal okamžite vidieť aktuálnu situáciu bez toho, aby podnikol akékoľvek kroky.

Preto aplikácia Boss využíva úlohy na pozadí na výmeny. Po každom zadaní údajov do databázy sa spustí úloha na pozadí, ktorá spustí výmenu. Prvou časťou je odoslanie údajov na server. Ostatné zariadenia potom potrebujú vedieť, že existujú nové údaje. Na tento účel používame upozornenia PUSH. Táto schéma už funguje a funguje dostatočne rýchlo.

Chceli sme však ešte rýchlejšie, pretože pracujeme v reálnom čase a zvyčajne máme málo dát. Máme malý XML, ale zároveň posielame správu s týmito údajmi z prvého zariadenia na server, server pošle PUSH ďalšiemu zariadeniu a druhé zariadenie po prijatí PUSH iniciuje výmenu zo svojej strany, pristúpi na server a vyžiada si údaje, prijme tieto údaje a následne odošle odpoveď, že údaje boli prijaté. Je to dlhá doba, ale samotných údajov bolo veľmi málo.

Rozmýšľali sme, ako sa dá tento proces urýchliť.

Aby sme to urobili, prišli sme na to, čo PUSH obsahuje, ako sa dá ešte použiť. Ukázalo sa, že PUSH obsahuje polia ako dáta a text. Dokumentácia pre iOS a Android uvádza limity veľkosti PUSH správ, no zdalo sa nám to málo a chceli sme na to prísť sami. A skontrolovali sme, že pre iOS je súčet povolených znakov 981 znakov a pre Android je to 3832 znakov. V druhom prípade je celkom možné použiť obmedzenie, do takého objemu je možné vložiť jeden alebo niekoľko základných objektov. A potom vývojári spoločnosti trochu zmenili schému. Keď nie je veľa dát, pošleme ich z jedného zariadenia, prijmeme na server, zabalíme do PUSH a pošleme priamo do iného zariadenia. Schéma sa skrátila a výmena ešte rýchlejšia :)

Dôležitým bodom používania PUSH je, že neobťažuje používateľov.

Je veľmi jednoduché zbaviť sa tejto situácie: jednoducho neposielajte používateľovi veľa PUSH správ :) Ak práve pracuje v aplikácii, môžete posielať veľa správ. Keď je platforma spustená, používateľ nevidí PUSH, všetko sa mu deje automaticky. Ale keď je aplikácia uzavretá, klient má veľa neprečítané správy. Preto v žiadnom prípade neposielajte ďalšie PUSH, kým zo zariadenia nedostanete odpoveď, že aplikácia je spustená, aktívna a predchádzajúce PUSH už bolo spracované.

Ďalšou nuansou výmeny je práca cez web. Musíme čo najviac využívať asynchrónnosť. Nemôžete pracovať ako zvyčajne - písať kód - volať funkciu - čakať na jej vykonanie - dostať odpoveď - a všetko je v poriadku. Ak pracujete cez web, stále budete narážať na určité obmedzenia, ako je nestabilný internet, časové limity pri vykonávaní dlhých operácií. Preto je potrebné vopred premyslieť architektúru.

Pozrime sa na príklade registrácie zariadenia, čo sa deje v aplikácii, keď sa chce používateľ zaregistrovať. Chvíľu si vedie evidenciu, zadal množstvo údajov, no potom chce, aby s touto databázou pracoval aj predajca. Používateľ klikne na tlačidlo „zaregistrovať sa“. Spočiatku bolo všetko veľmi jednoduché: vzali jeho údaje, zaznamenali ich na server a môžete, prosím, pracovať a spájať používateľov. Potom sme sa však dostali do situácie, že niektorým používateľom sa databázy na zariadení už v čase registrácie značne rozrástli. A táto schéma už nefungovala, pretože. počas nahrávania celej databázy na server sa spustil časový limit pripojenia alebo sa jednoducho prerušil internet. Preto sme jeden synchrónny hovor nahradili mnohými krátkymi. Údaje sa teraz zdieľajú a nie sú prenášané naraz. V žiadnom prípade nečakáme, kým server spracuje a zapíše dáta. Poslali sme údaje, dostali odpoveď, že údaje boli prijaté, ukončili sme spojenie. Periodicky je potrebné dotazovať server, čo sa tam deje a ako a medzitým na serveri beží úloha na pozadí, ktorá zapisuje prijaté dáta. To spôsobuje veľa volaní servera, ale máme záruku, že všetko pôjde dobre. A ani časové limity, ani nestabilita internetu vám nezabránia nahrať všetky dáta na server.

AKTUALIZÁCIE

Zdieľanie medzi zariadeniami s rôznymi verziami aplikácie

Keďže hovoríme o hromadnej aplikácii, ktorá sa uvoľňuje na trhy, je potrebné vziať do úvahy niektoré vlastnosti procesu aktualizácie a výmeny údajov.

Ak ste uvoľnili aplikáciu pre jeden podnik a rozhodli ste sa ju aktualizovať, zvyčajne len vydáte príkaz, aby všetci zamestnanci jednomyseľne nainštalovali novú aplikáciu. S používateľmi, ktorí si stiahli aplikáciu z trhu, to nie je možné. Vôbec im nemôžete prikázať, čo majú robiť. Napríklad pracujú v aplikácii a nechcú ju aktualizovať teraz ani nikdy. Nemajú automatickú aktualizáciu, takže je celkom bežné, že do centrálnej databázy je pripojených viacero zariadení a všetky s rôznymi verziami. Ďalším dôvodom tohto javu je čas zverejnenia na trhoch: je iný pre iOS a Android. Často implementujeme kľúčové veci, ako je oprava kritických chýb, a nechceme čakať dva týždne na kontrolu systému iOS Nová verzia, chceme aspoň len pre Android, no aktualizáciu vydáme už teraz.

Nemáme právo rozkazovať používateľom. Ak chcú, aktualizujú sa a ak nie, nerobia nič. Obrázok ukazuje pomer inštalácií aplikácie Boss podľa verzií v GooglePlay, ako aj štatistiky z nášho servera – skutočný pomer verzií aplikácie, ktoré sú nainštalované na zariadeniach, ktoré si vymieňali dáta so serverom za posledný týždeň. Tu je sada, s ktorou sa dá pracovať. Ide o rôzne verzie a rôzne metadáta. A zároveň musíme zorganizovať normálnu výmenu :)

Vývojári čelia nasledujúcim úlohám:

Všetko musí fungovať. Používatelia by sa nemali cítiť zle, keď zabudli aktualizovať. Vôbec by si to nemali všímať. Aktualizované - stalo sa lepšie, dobre, dobre.
Musíme zabezpečiť bezpečnosť údajov. Napríklad jeden používateľ má adresár a nový atribút, zatiaľ čo iný ho ešte nemá. Navyše, ak používateľ, ktorý nemá nové podrobnosti, niečo na svojom zariadení zmení, údaje na iných zariadeniach by sa nemali stratiť.
Pri prechode na novú verziu je potrebné zabezpečiť aktualizáciu údajov. Keď sa používateľ rozhodne, že je pripravený na upgrade, mal by mať automaticky všetky nové informácie, ktoré nemal len preto, že mal starú verziu.

ako sa nám to podarilo?

1. Na serveri používame 2 výmenné plány. Prvý slúži na zdieľanie medzi zariadeniami a druhý na aktualizácie. Používateľovi sme napríklad poslali adresár, ktorý však nemá merné jednotky, teda neúplné údaje. Toto si musíme pamätať. A keď je aktualizovaný, musíme mu poslať všetky informácie, ktoré nemal. Na to je potrebný druhý plán výmeny.

2. Na zápis a čítanie objektov používame rovnaký mechanizmus, aký sa používa pri zálohovaní, teda ukladáme verziu metadát. V tomto prípade pracujeme so serverom a môžeme si dovoliť pridať čokoľvek, čo chceme, priamo do konfigurácie, takže do konfigurácie jednoducho pridávame schémy metadát vo forme rozložení podľa vývoja aplikácie.

Ako sledovať masívne chyby na burze a na serveri

Najprv musíte kontrolovať dostupnosť samotného servera. So servermi sa to stáva - padajú. Nevymysleli sme nič špeciálne na monitorovanie, ale jednoducho sme našli robota v telegrame, ktorý kričí, ak niečo nie je v poriadku. Každú minútu kontroluje výkon servera a ak je zrazu server nedostupný, začne kričať, admini to vidia a zdvihnú server.

Z denníka zhromažďujeme aj protokol o chybách. Tiež nič nadprirodzené - každé tri hodiny zhromažďujeme protokol o chybách, posielame ich e-mailom, pravidelne ich kontrolujeme. Pomáha to vidieť bežné problémy a niektoré výnimočné situácie. Nie je ťažké prezerať poštu, sledovať a rýchlo opravovať chyby. To vám však umožňuje rýchlo identifikovať a riešiť problémy, ktoré môžu rásť s rastom databáz.

Ešte dôležitý bod- nezabudnite dať používateľovi možnosť „sťažovať sa“. To zlepšuje náš stav v ich očiach a zachraňuje nás. Sú užívatelia, ako ich voláme, „hysterici“, ktorí nám pri najmenšom omyle začnú poštou posielať kopu správ, že nič nefunguje, databáza sa nenačítava, všetko je strašne zlé. Ale niekedy nás naozaj zachránia, pretože niekedy nájdu chyby, ktoré zvyšok ešte zázračne neobjavil, vážne chyby.

Používateľ by sa nemal báť. Žiadne desivé správy, nič iné. Potrebujú všetko krásne vysvetliť a ponúknuť sťažnosť. A sľubujeme, že všetko vyriešime. Vtedy sú užívatelia spokojní, lebo vidia, že je o nich postarané a hneď veria, že im bude pomožené :)

Tento článok bol napísaný na základe výsledkov správy prečítanej na konferencii INFOSTART EVENT 2016 DEVELOPER. Dá sa prečítať viac článkov.

V roku 2020 pozývame všetkých, aby sa zúčastnili na 7 regionálnych stretnutiach, ako aj na jubilejnom INFOSTART EVENT 2020 v Moskve.

Významná súčasť moderného aplikácie pre mobilné platformy(iOS, Android atď.) funguje v tandeme so serverom. Aplikácia so zastaranými dátami stráca svoju užitočnosť. Preto je dôležité zabezpečiť, aby sa údaje zo servera do zariadenia neustále aktualizovali. Týka sa to offline aplikácií, ktoré by mali fungovať bez internetu. Za plne online aplikácie, ktoré bez internetu nefungujú (alebo sú zbytočné) (napríklad Foursquare, Facebook) majú svoje špecifiká, ktoré sú nad rámec aktuálneho článku.

Na príklade jednej z našich offline aplikácií vám poviem, aké prístupy sme použili na synchronizáciu údajov. V prvých verziách vyvinuli sme jednoduché algoritmy a v budúcnosti sme ich na základe skúseností zlepšili. Podobná postupnosť je uvedená v článku - od jednoduchých zrejmých praktík po zložitejšie.

Malo by sa objasniť, že článok sa zaoberá prenosom údajov iba jedným smerom: zo servera do zariadenia. Zdrojom údajov je tu server.

Všeobecné ustanovenia pre všetky prístupy

Napríklad zvážime prenesenie adresára jedál („jedál“) do zariadenia. Budeme predpokladať, že zariadenie zadá požiadavku na url “/service/disches/update”, výmena prebieha cez http protokol vo formáte JSON ( www.json.org). Server má tabuľku „jedla“ s nasledujúcimi poľami: id (identifikátor záznamu), meno (názov jedla), aktualizované (čas aktualizácie jedla, je lepšie okamžite podporovať časové pásmo, „RRRR-MM-DDThh:mm:ssTZD“, napríklad „1997 -07-16T19:20:30+01:00“), is_deleted (znak vymazaného záznamu).

Poznámka týkajúca sa prítomnosti posledného poľa. Štandardne je jeho hodnota 0. V aplikácii, kde sú entity synchronizované medzi klientom a serverom, sa neodporúča fyzicky mazať dáta zo servera (aby nedošlo k chybám). Preto je pre vymazané riady nastavené is_deleted = 1. Keď do zariadenia dorazí entita s is_deleted = 1, je zo zariadenia vymazaná.

Pri oboch prístupoch, o ktorých sa bude diskutovať nižšie, server vráti pole objektov do zariadení JSON (môže byť prázdne):

[
(id: ,názov: .aktualizované: ,isDeleted: },…
]

Príklad odpovede servera:

[
(id: 5625,name: "Chlieb",aktualizované: "2013-01-06 06:23:12",isDeleted: 0),
(id: 23,name: "Varená krupica",aktualizované: "2013-02-01 14:44:21",isDeleted: 0),(

názov: "Rybia polievka",

aktualizované: "2013-08-02 07:05:19",

Zásady aktualizácie údajov na zariadení

Ak prišiel prvok, ktorý je na zariadení a je odstránený = 0, aktualizuje sa
Ak prišiel prvok, ktorý nie je na zariadení, a isDeleted = 0, potom sa pridá
Ak prišiel prvok, ktorý je na zariadení a je Deleted = 1, potom sa odstráni
Ak príde prvok, ktorý sa nenachádza v zariadení a isDeleted = 1, nič sa nerobí

Prístup 1: Vždy synchronizujte všetko

Toto je najjednoduchší spôsob. Zariadenie si vyžiada zoznam jedál zo servera a server odošle celý zoznam. Celý zoznam sa objaví zakaždým. Netriedené.

Príklad žiadosti: null alebo "()"

výhody:

Logika na serveri je jednoduchá - vždy dávame všetko
logika na zariadení je jednoduchá – vždy všetko prepíšeme

Nevýhody:

ak si zoznam vyžiadate často (každých 10 minút), bude to mať veľký internetový prenos
ak si zoznam vyžiadate zriedka (raz denne), bude porušená relevantnosť údajov

Oblasť použitia:

pre aplikácie s nízkou prevádzkou
prenos veľmi zriedkavo sa meniacich údajov (zoznam miest, kategórie)
preniesť nastavenia aplikácie
na začiatku projektu úplne prvého prototypu mobilnej aplikácie

Prístup 2: Len aktualizované

Zariadenie si vyžiada zoznam jedál aktualizovaný z predchádzajúcej synchronizácie. Zoznam je zoradený podľa „aktualizovaných“ vo vzostupnom poradí (voliteľné, ale praktické). Zariadenie uloží „aktualizovanú“ hodnotu pre naposledy odoslanú misku a odošle ju na server v parametri „lastUpdated“ pri ďalšej požiadavke. Server odošle zoznam jedál, ktoré sú novšie ako "lastUpdated" (aktualizované > lastUpdated). Pri prvej požiadavke na server „lastUpdated“ = null.

Príklad žiadosti: ( posledná aktualizácia: “2013-01-01 00:00:00” )

V diagrame: „last_updated“ je hodnota, ktorá je uložená v zariadení. Zvyčajne sa na zariadení vytvorí samostatná tabuľka na uloženie týchto „posledných_aktualizovaných“ hodnôt pre každú entitu (jedlá, mestá, organizácie atď.)

Tento prístup je vhodný na synchronizáciu jednoduchých lineárnych zoznamov, ktoré majú rovnaké pravidlá príchodu pre zariadenie pre všetky zariadenia. Pre selektívnejšiu synchronizáciu si pozrite Prístup 5: Synchronizácia s vedomím toho, čo už je na zariadení.

Tento prístup zvyčajne pokrýva väčšinu potrieb. Do zariadenia prichádzajú iba nové údaje, môžete synchronizovať aspoň každú minútu - prevádzka bude malá. S obmedzeniami sú však spojené problémy. mobilné zariadenia. Sú to pamäť a procesor.

Prístup 3: Synchronizácia po častiach

Mobilné zariadenia majú málo Náhodný vstup do pamäťe. Ak je v adresári 3 000 riadkov, potom analýza veľkého reťazca json zo servera do objektov v zariadení môže spôsobiť nedostatok pamäte. V takom prípade aplikácia buď spadne, alebo tých 3000 riadov neuloží. Ale aj keby zariadenie dokázalo stráviť takýto reťazec, potom bude výkon aplikácie v momentoch synchronizácie na pozadí nízky (oneskorenie rozhrania, neplynulé posúvanie atď.). Preto je potrebné požiadať o zoznam v menších častiach.

Na tento účel zariadenie odovzdá ďalší parameter („množstvo“), ktorý určuje veľkosť porcie. Zoznam sa odosiela nevyhnutne zoradený podľa poľa „aktualizované“ vo vzostupnom poradí. Zariadenie si podobne ako v predchádzajúcom prístupe zapamätá „aktualizovanú“ hodnotu poslednej odoslanej entity a odovzdá ju do poľa „lastUpdated“. Ak server odoslal presne rovnaký počet entít, zariadenie pokračuje v synchronizácii a znova odošle požiadavku, ale s aktualizovaným „lastUpdated“. Ak server odoslal menej entít, znamená to, že už nemá žiadne nové údaje a synchronizácia končí.

V diagrame: „last_updated“ a „amount“ sú hodnoty, ktoré sú uložené mobilná aplikácia. „posledná_položka“ – posledná entita (jedlo) odoslaná zo servera. Je novšia ako táto hodnota, bude sa vyžadovať ďalší zoznam.

Príklad žiadosti: ( posledná aktualizácia: “2013-01-01 00:00:00”, množstvo: 100 )

výhody:

Zariadenie prijíma toľko údajov, koľko dokáže naraz spracovať. Veľkosť porcie určená praktickými skúškami. Jednoduché entity je možné synchronizovať 1000 naraz. Stáva sa však aj to, že entity s veľkým počtom polí a zložitou logikou spracovania ukladania sa bežne synchronizujú nie viac ako 5 kusov.

Nevýhody:

Ak existuje 250 jedál s rovnakou aktualizáciou, potom s množstvom = 100 nebude posledných 150 doručených do zariadení. Táto situácia je celkom reálna a je opísaná v nasledujúcom prístupe.

Prístup 4: Správne načasovanie kúskov

V predchádzajúcom prístupe je možné, že ak je v tabuľke 250 jedál s rovnakou „aktualizáciou“ (napríklad „2013-01-10 12:34:56“) a veľkosť porcie je 100, potom príde prvých 100 záznamov. Zvyšných 150 bude odrezaných v dôsledku tvrdého stavu (aktualizované > naposledy aktualizované). Prečo sa to stane? Pri dotazovaní na prvých 100 záznamov sa lastUpdated nastaví na „2013-01-10 12:34:56“ a nasledujúci dotaz bude mať podmienku (aktualizované > „2013-01-10 12:34:56“). Nepomôže ani zmäkčenie stavu (aktualizované >= “2013-01-10 12:34:56”), pretože zariadenie si potom donekonečna vyžiada prvých 100 záznamov.

Situácia s rovnakou „aktualizáciou“ nie je taká zriedkavá. Napríklad pri importe údajov z textový súbor pole "aktualizované" bolo nastavené na NOW(). Import súboru s tisíckami riadkov môže trvať menej ako sekundu. Môže sa tiež stať, že celý adresár bude mať rovnako „aktualizovaný“.

Aby ste to napravili, musíte použiť nejaké pole paraboly, ktoré by bolo jedinečné aspoň v jednom okamihu („aktualizované“). Pole „id“ je jedinečné v celej tabuľke, takže by ste ho mali dodatočne použiť pri synchronizácii.

Stručne povedané, implementácia tohto prístupu vyzerá takto. Server vráti zoznam zoradený podľa „updated“ a „id“ a zariadenia požadujú údaje pomocou „lastUpdated“ a nového parametra „lastId“. Pre server je podmienka výberu komplikovanejšia: ((aktualizované > lastUpdated) ALEBO (aktualizované = lastUpdated a id > lastId)).

V diagrame: „last_updated“, „last_id“ a „amount“ sú hodnoty, ktoré sú uložené v mobilnej aplikácii. „posledná_položka“ – posledná entita (jedlo) odoslaná zo servera. Je novšia ako táto hodnota, bude sa vyžadovať ďalší zoznam.

Prístup 5: Synchronizácia so znalosťou toho, čo už je v zariadení

Predchádzajúce prístupy neberú do úvahy skutočnosť, že server skutočne nevie, ako úspešne boli dáta uložené v zariadení. Zariadenie jednoducho nedokázalo uložiť niektoré údaje kvôli nevysvetliteľným chybám. Preto by bolo pekné dostať zo zariadenia potvrdenie, že všetky (alebo nie všetky) jedlá sa zachovali.

Používateľ aplikácie si navyše môže nakonfigurovať aplikáciu tak, že potrebuje len časť údajov. Používateľ chce napríklad synchronizovať jedlá len z 2 miest z 10. To sa nedá dosiahnuť vyššie popísanými synchronizáciami.

Myšlienka prístupu je nasledovná. Server ukladá (v samostatnej tabuľke „zoznam_uložených_položiek“) informácie o tom, aké jedlá sú na zariadení. Môže to byť len zoznam párov „id – aktualizované“. V tejto tabuľke sú uložené všetky zoznamy „id – aktualizované“ párov tanierov pre všetky zariadenia.

Zariadenie odošle na server informácie o jedlách dostupných v zariadení (zoznam párov „id – aktualizované“) spolu s požiadavkou na synchronizáciu. Na požiadanie server skontroluje, ktoré jedlá by mali byť na zariadení a ktoré sú momentálne dostupné. Potom sa rozdiel odošle do zariadenia.

Ako server určí, ktoré jedlá by mali byť na zariadení? V najjednoduchšom prípade server odošle požiadavku, ktorá vráti zoznam „id - aktualizované“ párov všetkých jedál (napríklad SELECT id, aktualizované FROM pokrmy). V diagrame sa to robí metódou „WhatShouldBeOnDeviceMethod()“. Toto je nevýhoda tohto prístupu - server musí vypočítať (niekedy robí ťažké sql dotazy), čo by malo byť na zariadení.

Ako server určí, aké jedlá sú na zariadení? Dotazuje sa na tabuľku „stored_item_list“ pre toto zariadenie a získa zoznam párov „id – aktualizované“.

Na základe analýzy týchto dvoch zoznamov server rozhodne, čo sa má odoslať do zariadenia a čo sa má vymazať. V diagrame je to „zoznam_delta_položiek“. Preto v požiadavke nie sú žiadne „lastUpdated“ a „lastId“, ich úlohu vykonávajú dvojice „id - aktualizované“.

Ako server vie o jedlách dostupných v zariadení? Pridané do požiadavky na server nový parameter“items”, ktorý obsahuje zoznam id položiek, ktoré boli odoslané do zariadenia pri poslednej synchronizácii (“device_last_stored_item_list”). Samozrejme, môžete poslať zoznam ID všetkých jedál, ktoré sú na zariadení, a nekomplikovať algoritmus. Ak je však na zariadení 3 000 riadov a budú sa odosielať zakaždým, náklady na prevádzku budú veľmi vysoké. Vo veľkej väčšine synchronizácií bude parameter „items“ prázdny.

Server musí neustále aktualizovať svoj „zoznam_uložených_položiek“ údajmi, ktoré pochádzajú zo zariadenia v parametri „položky“.

Mali by ste implementovať mechanizmus na vymazanie údajov servera v zozname uložených_položiek. Napríklad po preinštalovaní aplikácie do zariadenia bude server predpokladať, že údaje sú na zariadení stále aktuálne. Preto pri inštalácii aplikácie musí zariadenie nejakým spôsobom informovať server, aby vymazal zoznam uložených_položiek pre toto zariadenie. V našej aplikácii posielame dodatočný parameter"clearCache" = 1 v tomto prípade.

Záver

Súhrnná tabuľka charakteristík týchto prístupov:

№	Prístup	Objem premávky(5 - veľké)	Pracovná náročnosť vývoja(5 - vysoká)	Využitie pamäte zariadenia(5 - vysoká)	Správnosť údajov na zariadení(5 - vysoká)	Môžete si vybrať konkrétne zariadenie
1	Všetko je vždy synchronizované	5	1	5	5	nie
2	Aktualizované iba synchronizované	1	2	5	3	nie
3	Synchronizácia po častiach	1	3	1	3	nie
4	Správna synchronizácia po častiach	1	3	1	3	nie
5	Synchronizácia so znalosťou toho, čo je už v zariadení	2	5	2	5	Áno

„Správnosť údajov na zariadení“ je pravdepodobnosť, že zariadenie má všetky údaje odoslané serverom. V prípade prístupov #1 a #5 je 100% istota, že zariadenie má všetky potrebné údaje. V opačnom prípade takáto záruka neexistuje. To neznamená, že nemožno použiť iné prístupy. Stačí ak má zariadenie súčiastku údaje sa stratia, potom to nebude fungovať opraviť zo servera (a ešte viac sa o tom dozvedieť na strane servera).

Možno, za prítomnosti neobmedzených taríf pre internet a zadarmo problém s wifi obmedzenia premávky generované mobilnou aplikáciou budú menej relevantné. Zatiaľ však musíme prejsť na všetky možné triky, vymyslieť „inteligentnejšie“ prístupy, ktoré môžu znížiť náklady na sieť a zvýšiť výkon aplikácií. Nie vždy to funguje. Niekedy sa to stáva „čím jednoduchšie, tým lepšie“, v závislosti od situácie. Dúfam, že tento článok vám pomôže nájsť prístup, ktorý sa vám bude hodiť.

Existuje prekvapivo málo popisov synchronizácie servera a mobilné zariadenia. Okrem toho existuje veľa aplikácií, ktoré fungujú podľa tejto schémy. Pre zaujemcov par linkov.