Dezvoltare de aplicatii mobile: Sincronizare cu serverul. Dezvoltarea părții server a aplicațiilor mobile Crearea părții server a aplicației

Offline în trecut, a fi online astăzi este o necesitate. Cel puțin pentru lumea modernă a afacerilor. Prezentări de produse și servicii de marcă, comandă și livrare online, menținerea unei baze de clienți, comunicarea cu clienții și multe altele - toate acestea sunt pur și simplu imposibile fără o prezență pe internet. Dacă aveți nevoie de o aplicație, trebuie să aveți atât Front-end (interfață web) cât și Back-End (back-end-ul aplicației dvs.). Iar dacă vrei să poți edita conținutul aplicației tale fără implicarea dezvoltatorilor, ai nevoie de un panou de administrare bun.

În timp ce front-end-ul din spațiul aplicației mobile este construit folosind tehnologii precum X-Code și Java, back-end-ul, unde va fi stocată baza de date și toată logica aplicației, necesită cunoștințe profesionale a unui limbaj de programare pe partea de server. Un bun exemplu este PHP, care este probabil cel mai popular limbaj de programare folosit pentru aproape orice dezvoltare pe partea de server. Acesta este liderul incontestabil.

Există multe utilizări pentru PHP: site-uri web statice și dinamice + sisteme personalizate de gestionare a conținutului, social media, sisteme CRM specializate, software de comerț electronic și multe altele. Desigur, există piese de server gratuite sau ieftine și panouri de control. Cu toate acestea, în multe cazuri, acestea nu oferă nivelul necesar de confort, personalizare și upgrade.

Programatorii noștri lucrează cu tehnologii pentru a implementa o gamă largă de soluții pentru diferite obiective, nevoi și cerințe de afaceri. Analizăm cerințele de sistem pentru fiecare proiect în mod individual și folosim diverse software-uri specializate de server pentru performanța optimă a aplicației dumneavoastră mobile.

Dacă sunteți în căutarea unei echipe care vă poate conduce la cea mai inteligentă și mai rentabilă soluție pentru a construi o aplicație de la zero sau pentru a reconstrui una existentă pentru o experiență de utilizator perfectă, nu mai trebuie să căutați. Appsmob este gata să vă ajute să găsiți cea mai bună soluție pentru dvs.

Dezvoltarea părții server a unei aplicații client-server începe cu proiectarea arhitecturii. Multe depind de arhitectură: de la extensibilitatea aplicației până la performanța acesteia și ușurința în suport/întreținere.

În primul rând, trebuie să determinați cum vor fi plasate datele pe server și cum vor fi procesate cererile venite de la client. De asemenea, trebuie să luați în considerare organizarea stocării în cache a datelor de pe server.

Este necesar să se determine protocoalele de schimb de date și formatele de transfer de date.

API (interfață de programare a aplicațiilor) este o interfață de programare a aplicațiilor. Într-un limbaj mai ușor de înțeles, acesta este un set de solicitări către server, pe care acesta din urmă le înțelege și le poate da răspunsul corect. API-ul definește funcționalitatea logicii serverului, în timp ce API-ul vă permite să faceți abstracție de la modul exact în care este implementată această funcționalitate. Cu alte cuvinte, API-ul este o parte necesară a infrastructurii client/server.

Comparați JSON și XML. Furnizați un exemplu de protocoale în funcție de tipul de aplicație.

Multithreading

Unul dintre aspectele cheie în programarea modernă este multithreading. Cu ajutorul multithreading-ului, putem aloca mai multe fire de execuție într-o aplicație care va îndeplini diverse sarcini în același timp.

Multithreading-ul este o proprietate a unei platforme (de exemplu, un sistem de operare, o mașină virtuală etc.) sau o aplicație pe care un proces generat într-un sistem de operare poate consta din mai multe fire care rulează „în paralel”, adică fără un comanda din timp.

Esența multithreading-ului este cvasi-multitasking-ul la nivelul unui proces executabil, adică toate firele sunt executate în spațiul de adrese al procesului. În plus, toate firele de execuție dintr-un proces au nu numai un spațiu de adrese comun, ci și descriptori de fișier comun. Un proces care rulează are cel puțin un fir (principal).

Multithreading (ca doctrină de programare) nu trebuie confundat nici cu multitasking, fie cu multiprocesare, în ciuda faptului că sistemele de operare care implementează multitasking tind să implementeze și multithreading.

Avantajele multithreading-ului în programare includ următoarele:

Simplificarea programului în unele cazuri datorită utilizării unui spațiu de adrese comun.

Mai puțin timp petrecut pentru crearea fluxului în raport cu procesul.

Creșterea productivității procesului datorită paralelizării calculelor procesorului și operațiunilor I/O.

curgere(thread) este o unitate gestionată de cod executabil. Într-un mediu multitasking bazat pe fire, toate procesele care rulează trebuie să aibă un fir principal, dar pot fi mai multe. Aceasta înseamnă că mai multe sarcini pot fi efectuate asincron într-un singur program. De exemplu, editarea textului într-un editor de text în timpul imprimării, deoarece aceste două sarcini sunt efectuate în fire diferite.

Pe un procesor convențional, controlul fluxului este gestionat de sistemul de operare. Un fir este executat până când expiră o întrerupere hardware, un apel de sistem sau timpul alocat pentru acesta de sistemul de operare. După aceea, procesorul trece la codul sistemului de operare, care salvează starea firului de execuție (contextul său) sau trece la starea unui alt fir, căruia i se alocă și timp pentru execuție. Cu o astfel de multithreading, un număr destul de mare de cicluri de procesor sunt cheltuite pe codul sistemului de operare care schimbă contextele. Dacă suportul pentru fire este implementat în hardware, atunci procesorul însuși va putea comuta între fire și, în mod ideal, va executa mai multe fire simultan pentru fiecare ciclu de ceas.

- Multithreading temporar (un fir)

- Multithreading simultan (mai multe fire în același timp)

Multithreadingul, ca model de programare și execuție de cod larg răspândit, permite executarea mai multor fire într-un singur proces. Aceste fire de execuție împart resursele procesului, dar pot rula și independent. Modelul de programare cu mai multe fire oferă dezvoltatorilor o abstractizare convenabilă pentru execuția paralelă. Cu toate acestea, poate cea mai interesantă aplicație a tehnologiei este atunci când este aplicată unui singur proces, ceea ce permite executarea acestuia în paralel pe un sistem multiprocesor.

Acest avantaj al unui program multithreaded îi permite să ruleze mai rapid pe sisteme informatice care au mai multe procesoare, un procesor cu mai multe nuclee sau pe un cluster de mașini - deoarece firele de execuție a programului se pretează în mod natural la execuția cu adevărat paralelă a proceselor. În acest caz, programatorul trebuie să fie foarte atent pentru a evita condițiile de cursă și alte comportamente neintuitive. Pentru a manipula corect datele, firele de execuție trebuie să treacă frecvent prin procedura rendezvous pentru a procesa datele în ordinea corectă. Firele de execuție pot avea nevoie și de mutexuri (care sunt adesea implementate folosind semafore) pentru a preveni modificarea sau citirea datelor partajate în același timp în timpul procesului de actualizare. Folosirea neglijentă a unor astfel de primitive poate duce la o fundătură.

O altă utilizare a multithreading-ului, aplicabilă chiar și pentru sistemele uniprocesor, este capacitatea unei aplicații de a răspunde la intrare. În programele cu un singur thread, dacă firul principal este blocat de o sarcină de lungă durată, întreaga aplicație poate fi înghețată. Prin mutarea unor astfel de sarcini consumatoare de timp într-un fir de lucru care rulează în paralel cu firul principal, devine posibil ca aplicațiile să continue să răspundă la intrarea utilizatorului în timp ce sarcinile rulează în fundal. Pe de altă parte, în majoritatea cazurilor, multithreadingul nu este singura modalitate de a păstra sensibilitatea unui program. Același lucru poate fi realizat prin intermediul I/O asincron sau prin semnale pe UNIX.

În total, există două tipuri de multitasking: bazate pe proceseși pe baza fluxurilor... Diferența dintre multitasking bazat pe proces și bazat pe thread se rezumă la următoarele: multitasking bazat pe proces este organizat pentru execuția paralelă a programelor, iar multitasking bazat pe thread este pentru execuția paralelă a părților separate ale aceluiași program.

În total, se disting două tipuri de fluxuri:

Fire de prim-plan sau prim-plan. În mod implicit, fiecare fir creat prin metoda Thread.Start () devine automat firul din prim-plan. Aceste tipuri de fire oferă protecție aplicației curente de la terminare. CLR nu va opri aplicația până când toate firele din prim-plan nu se vor termina.

Fire de fundal Acest tip de fir de execuție se mai numește și fire daemon și este interpretat de CLR ca căi extensibile de execuție care pot fi ignorate în orice moment. Astfel, dacă toate firele din prim-plan sunt terminate, atunci toate firele din fundal sunt distruse automat când domeniul aplicației este descărcat. Pentru a crea fire de fundal, setați proprietatea IsBackground la true.

Spuneți despre stările firelor: rulare, suspendare, rulare, dar așteptând ceva.

Problemă de sincronizare a firelor și resurse partajate.

Interacțiunea firelor

Într-un mediu cu mai multe fire de execuție, adesea apar probleme legate de utilizarea acelorași date sau dispozitive prin fire de execuție paralele. Pentru a rezolva astfel de probleme, se folosesc metode de interacțiune a firelor precum mutexuri, semafore, secțiuni critice și evenimente.

Mutex Este un obiect de sincronizare care este setat la o stare de semnalizare specială atunci când nu este ocupat cu niciun fir. Un singur fir deține acest obiect la un moment dat, de unde și numele unor astfel de obiecte (din limba engleză, care se exclud reciproc) - accesul simultan la o resursă partajată este exclus. După ce sunt întreprinse toate acțiunile necesare, mutex-ul este eliberat, oferind altor fire acces la resursa partajată. Obiectul poate suporta captura recursiva a doua oară de către același fir, incrementând contorul fără a bloca firul de execuție și apoi necesitând mai multe dealocari. Aceasta este, de exemplu, secțiunea critică din Win32. Cu toate acestea, există unele implementări care nu acceptă acest lucru și determină blocarea firului de execuție atunci când încearcă o captură recursivă. Acesta este FAST_MUTEX în nucleul Windows.

Semafoare sunt resurse disponibile care pot fi achiziționate de mai multe fire în același timp până când pool-ul de resurse este gol. Apoi firele suplimentare trebuie să aștepte până când cantitatea necesară de resurse este disponibilă din nou. Semaforele sunt foarte eficiente deoarece permit accesul simultan la resurse.

Evoluții... Un obiect care stochează 1 bit de informație „semnalizat sau nu”, peste care sunt definite operațiunile „semnal”, „resetare la starea nesemnalizată” și „așteptare”. Așteptarea unui eveniment semnalat este absența unei operațiuni cu continuarea imediată a execuției firului. Așteptarea unui eveniment nesemnalizat determină suspendarea firului de execuție până când un alt fir de execuție (sau a doua fază a gestionarului de întreruperi din nucleul sistemului de operare) semnalează evenimentul. Este posibil să așteptați mai multe evenimente în modurile „oricare” sau „toate”. De asemenea, este posibil să se creeze un eveniment care este resetat automat la o stare nesemnalizată după trezirea primului - și singurului - fir în așteptare (un astfel de obiect este folosit ca bază pentru implementarea obiectului „secțiune critică”). Sunt utilizate activ în MS Windows, atât în modul utilizator, cât și în modul kernel. Există un obiect similar în nucleul Linux numit kwait_queue.

Secțiuni critice oferă o sincronizare similară cu mutexurile, cu excepția faptului că obiectele care reprezintă secțiuni critice sunt disponibile în cadrul aceluiași proces. Evenimentele, mutexurile și semaforele pot fi, de asemenea, utilizate într-o aplicație cu un singur proces, cu toate acestea, implementările de secțiuni critice în unele sisteme de operare (cum ar fi Windows NT) oferă un mecanism de sincronizare mai rapid și mai eficient, care se exclud reciproc - operațiunile de obținere și eliberare pe secțiunile critice sunt optimizate pentru cazul unui singur fir (fără dispute) pentru a evita orice apeluri de sistem care duc la nucleul OS. La fel ca mutexurile, un obiect care reprezintă o secțiune critică poate fi folosit doar de un fir la un moment dat, ceea ce le face extrem de utile pentru delimitarea accesului la resursele partajate.

Variabile condiționale(convarii). Sunt asemănătoare evenimentelor, dar nu sunt obiecte care ocupă memorie - se folosește doar adresa unei variabile, conceptul de „conținut al unei variabile” nu există, adresa unui obiect arbitrar poate fi folosită ca variabilă condiționată. . Spre deosebire de evenimente, setarea unei variabile de condiție la o stare semnalată nu are consecințe dacă în prezent nu există fire de execuție în așteptare pentru variabilă. Setarea unui eveniment într-un caz similar implică stocarea stării „semnalizate” în interiorul evenimentului însuși, după care următoarele fire care doresc să aștepte evenimentul continuă imediat execuția fără oprire. Pentru a folosi pe deplin un astfel de obiect, este, de asemenea, necesar să eliberați mutex-ul și să așteptați variabila condiționată atomic. Sunt utilizate pe scară largă în sistemele de operare asemănătoare UNIX. Discuțiile despre avantajele și dezavantajele evenimentelor și ale variabilelor de condiție sunt o parte notabilă a discuțiilor despre avantajele și dezavantajele Windows și UNIX.

Port de completare I/O(Port de completare IO, IOCP). Obiectul „coadă” implementat în nucleul OS și accesibil prin apeluri de sistem cu operațiunile „pune structura în coada cozii” și „ia următoarea structură din capul cozii” - ultimul apel întrerupe execuția firul dacă coada este goală și până când un alt thread nu va face apelul la „put”. Cea mai importantă caracteristică a IOCP este că structurile pot fi plasate în el nu numai printr-un apel de sistem explicit din modul utilizator, ci și implicit în nucleul sistemului de operare, ca urmare a unei operațiuni I/O asincrone finalizate pe unul dintre descriptorii de fișier. Pentru a obține acest efect, trebuie să utilizați apelul de sistem „bind file descriptor to IOCP”. În acest caz, structura plasată în coadă conține codul de eroare al operațiunii I/O și, de asemenea, dacă această operațiune are succes, numărul de octeți de intrare sau de ieșire efectiv. Implementarea portului de completare limitează, de asemenea, numărul de fire care rulează pe un singur procesor/nucleu după ce o structură este pusă în coadă. Obiectul este specific MS Windows și permite procesarea cererilor de conexiune de intrare și a fragmentelor de date în software-ul server într-o arhitectură în care numărul de fire poate fi mai mic decât numărul de clienți (nu există nicio cerință de a crea un fir separat cu costuri de resurse pentru fiecare client nou).

Bazin de fire

Spuneți despre grupul de fire

Compania noastră oferă servicii pentru crearea părții server a aplicațiilor mobile de afaceri și a serviciilor web pentru clienți care operează în medii cu încărcare mare. La dezvoltarea fiecărui proiect, încercăm să aplicăm o abordare individuală, astfel încât produsul rezultat să devină cea mai optimă soluție pentru obiectivele specifice ale clientului.

Dacă utilizați o aplicație complexă care stochează și/sau procesează date pe un server, atunci există un Back-end în spatele acesteia - un pachet software situat pe un server web și care lucrează cu o aplicație, care în acest caz se numește Front-end . O aplicație situată pe un server poate funcționa simultan cu un număr mare de clienți, ceea ce impune cerințe privind viteza mare și siguranța funcționării acesteia.

Partea de server a unei aplicații este adesea scrisă în PHP, care este cel mai popular limbaj pentru astfel de soluții. Pentru a implementa sarcini simple de server, pot fi folosite sisteme standard, dar cele mai specifice necesită deja dezvoltarea unei soluții proprii sau a unor suplimente peste sistemele standard.

Principii de dezvoltare a serverului pentru o aplicație mobilă

Programatorii noștri lucrează cu tehnologii care ne permit să implementăm o gamă largă de soluții pentru orice încărcătură de lucru, chiar și foarte mare și direcții diferite. De asemenea, creăm soluții de server separate pentru sarcini individuale.

Controlul organizațional

Fiecare proiect este creat de un grup separat de specialiști responsabili de toate etapele de dezvoltare și livrare la timp a proiectului.

Programare

Proiectarea arhitecturii serverului este cel mai important pas în procesul de creare a bazelor de date și de formare a algoritmilor necesari.

Testare

Partea software ar trebui să funcționeze fără erori și eșecuri. De asta sunt responsabili testerii care testează sistemul.

Suport tehnic

Angajații noștri oferă suport tehnic complet pentru programe, ceea ce ne permite să eliminăm rapid deficiențele și să facem actualizări.

Caracteristici de dezvoltare

Pentru a dezvolta în mod competent partea de server a aplicației, sunt necesare anumite abilități și cunoștințe ale limbajului de programare folosit pe server. După cum arată practica, aplicațiile client-server sunt create în PHP. El este liderul incontestabil în acest domeniu. Mai mult de jumătate din site-urile din lume sunt scrise în PHP, este convenabil pentru dezvoltare și suport.

Cadru

Această platformă software vă permite să vă faceți proiectul mai scalabil și mai flexibil. Cu toate acestea, cadrul trebuie ales cât mai corect posibil, prin urmare, este necesară o analiză aprofundată a documentației de lucru a proiectului, care va ajuta ulterior la dezvoltarea unui produs de înaltă calitate.

Există și alte limbi folosite pentru dezvoltarea back-end. De exemplu, aplicațiile server create în mediul Delphi sunt populare. Datorită acesteia, programul a îmbunătățit depanarea. În plus, este mai ușor să dezvoltați programe unice în ea, oferă crearea vizuală. Toate acestea fac posibilă crearea unei interfețe clare și ușor de utilizat.

Aplicațiile server Java nu sunt mai puțin populare. Acestea pot fi completate fără probleme, ușor de executat pe diferite platforme și au un nivel ridicat de securitate.

Un alt limbaj folosit în mod obișnuit. Vă ajută să creați aplicații server ușor, rapid și ieftin.

Aproape toate companiile moderne au propriile birouri virtuale. Un site web poate fi fie o carte de vizită, fie un portal sau un catalog online cu posibilitatea de a plasa comenzi.

Procesele de afaceri în acest caz depind de serverele web, și anume de capacitatea acestora de a rezista atacurilor, tentativelor de hacking și influențelor negative externe, precum și de performanță suficientă pentru multe solicitări acceptate simultan.

Etapele dezvoltării serviciului web

Atunci când creăm aplicații pentru diferite segmente de piață, ne organizăm munca după un singur principiu - împărțim întregul proces în pași separați, ale căror progrese și rezultate sunt raportate clienților. Astfel, un server pentru o aplicație mobilă este dezvoltat într-un mod similar.

1. Dezvoltarea unei idei

Până la 2 săptămâni

În această etapă, se creează fundația, dând o idee despre ceea ce va fi pus și în ce direcție se va dezvolta.

2. Evaluarea proiectului

2-3 saptamani

Experții noștri evaluează timpul și costul lucrării, apoi se întocmește o propunere preliminară de dezvoltare.

3. Termeni de referință și contract

Până la 2 săptămâni

După discutarea cu clientul a tuturor nuanțelor procesului și întocmirea unei specificații tehnice detaliate, se întocmește și se semnează un acord.

4. Dezvoltarea interfeței

2-3 saptamani

Designerii sunt implicați în crearea interfețelor necesare pentru scrierea modulelor software.

6. Testare

2-3 saptamani

O verificare completă a soluției software rezultată este efectuată de testeri folosind un set de instrumente adecvate.

7. Finalizarea proiectului

Până la 2 săptămâni

În intervalul de timp convenit, un serviciu web gata făcut, testat temeinic este predat clientului.

echipa noastră

Prin analiza activităților comerciale și a nevoilor clienților noștri, creăm produse cu adevărat funcționale care ajută la rezolvarea unui număr de probleme de afaceri. Utilizarea tehnologiilor moderne oferă o gamă largă de posibilități de implementare a software-ului server, care garantează performanțe ridicate ale aplicațiilor mobile corespunzătoare. Echipa noastra este reprezentata de:

Manageri de proiect

Acești angajați interacționează atât cu clienții, cât și cu dezvoltatorii, asigurând comunicarea între ei. Aceștia controlează implementarea atât a acțiunilor planificate, cât și a îmbunătățirilor necesare.

Designeri

În munca lor, specialiștii noștri țin cont de cerințele pentru construirea de interfețe pentru sistemele de operare iOS și Android, astfel încât aplicațiile lansate funcționează corect pe diferite dispozitive.

Dezvoltatori

Pentru a optimiza performanța aplicațiilor mobile, programatorii își analizează cerințele de sistem și creează software de server specializat.

Testeri

Testarea amănunțită este o garanție a calității produsului finit și o garanție a siguranței datelor stocate și prelucrate. Acești profesioniști folosesc o varietate de instrumente și o metodologie eficientă.

Ce servicii creăm

Indiferent dacă este încorporat într-un site de software sau ca program de sine stătător, un serviciu web servește la îndeplinirea sarcinilor legate de publicitate, analiză, planificare și promovarea afacerii. În acest sens, este necesar să se decidă ce fel de resursă va fi soluția optimă.

Proiecte de informare

Proiectat pentru a găzdui conținut divers.

Site-uri tematice

Aproape toate paginile lor sunt dedicate unui singur subiect. Cererea pentru ele este încă destul de mare.

Site-uri de știri

Informează despre diverse știri în cadrul unuia sau mai multor subiecte, reflectând principalele domenii ale vieții.

Bloguri

Popularitatea acestor resurse este în continuă creștere. La fel ca site-urile de știri, ei transmit cutare sau cutare informație comunității de pe internet, dar în acest caz, autorii își exprimă părerea personală.

Proiecte sociale

Acestea includ servicii sociale specializate. rețele, comunități, forumuri etc.

Forumuri

Creat pentru a discuta despre diverse știri, bunuri/servicii etc. Ele pot fi atât focalizate cât și versatile.

Retele sociale

Aceste resurse au o audiență multimilionară. Sarcina lor principală este de a oferi utilizatorilor de internet capacitatea de a comunica online prin mesaje text/voce și comunicare video.

Diverse servicii web

Răspândite astăzi, ele sunt împărțite în mai multe tipuri.

Cataloage

servicii poștale

Oferiți utilizatorilor toate caracteristicile și beneficiile e-mailului, inclusiv vizualizarea, trimiterea, editarea scrisorilor și documentelor etc.

Motoare de căutare

Acestea sunt folosite pentru a căuta site-uri și diverse informații despre anumite interogări.

Panouri de informare

Acestea sunt resurse web în care internauții își postează reclamele pentru vânzarea și cumpărarea de servicii și servicii într-o varietate de subiecte.

Site-uri de gazduire

Proiectat pentru stocarea temporară a fișierelor. Unele dintre ele oferă posibilitatea de a revizui datele înainte de descărcare.

FAQ

Mai jos oferim răspunsuri la întrebările care sunt adesea adresate de specialiștii noștri. Dacă nu găsiți informațiile de interes aici, vă rugăm să puneți întrebarea dvs formă, și cu siguranță îi vom răspunde.

Cât timp durează construirea aplicației și a serverului web?

În medie, această muncă durează de la 9 la 20 de săptămâni. Totul depinde de complexitatea sarcinii în cauză.

BACKUP

De ce aveți nevoie de copii de rezervă pe o platformă mobilă

Experții știu cât de nesigure sunt uneori aplicațiile mobile de pe 1C: erori pot apărea în orice moment, din cauza cărora baza de utilizatori se va prăbuși pur și simplu. În același timp, ne confruntăm cu lipsa de încredere a dispozitivelor în sine: acestea pot fi sparte, pierdute, pot fi furate, iar utilizatorii doresc să-și păstreze datele. Și până la versiunea 8.3.9 nu aveam un mecanism de platformă pentru salvarea unui backup.

Întrucât utilizatorii nu aveau anterior un buton „salvați o copie”, dezvoltatorii aplicației Boss au fost nevoiți să-și facă propriile copii de rezervă. Cum am făcut-o?

Salvăm datele bazei de date sub formă de XML.

Este recomandabil să oferiți utilizatorului mai multe opțiuni pentru stocarea copiilor - în primul rând, este convenabil pentru clienți, aceștia pot alege cea mai bună opțiune pentru ei înșiși: încărcați în cloud, trimiteți pe e-mailul lor, salvați pe dispozitiv.

Astfel, dezvoltatorii se asigură suplimentar. Dacă ceva nu a mers prost și mecanismul de creare a copiilor pe Google Drive sau Yandex Drive s-a defectat brusc, puteți spune oricând utilizatorului că în acest moment dezvoltatorul se confruntă cu o eroare, dar deocamdată poate salva datele într-o alternativă. cale. Și utilizatorii sunt mulțumiți pentru că pot fi siguri de datele lor.

Neapărat trebuie să se concentreze pe serviciile cloud, deoarece dacă dispozitivul este pierdut sau rupt, iar utilizatorul a salvat o copie pe același dispozitiv, atunci datele se vor pierde.

De asemenea noi asigurați-vă că reamintiți utilizatorului necesitatea de a crea copii de rezervă.

Cum se păstrează copii dacă se modifică configurația?

Atunci când vorbim despre o soluție de masă, despre o aplicație în continuă schimbare, evoluție și rafinare, trebuie să se țină cont de comportamentul clienților. Este posibil ca utilizatorul să dorească să restabilească o copie de rezervă salvată într-o versiune veche a aplicației, care nu avea detalii. Și atunci apare sarcina: să citiți datele, apoi să completați datele conform logicii de actualizare din versiunea veche a aplicației. Cum să o facă? Pe lângă date, salvați structura de date în sine, astfel încât mai târziu să știți cum să o citiți.

Există mai multe opțiuni pentru stocarea acestei structuri de date, inclusiv poate fi stocată în configurația în sine. Adică, de fiecare dată când este lansată o nouă versiune, păstrați structura de metadate a versiunii anterioare într-un aspect în configurație.

Nu uitați că într-o aplicație mobilă configurația nu trebuie să crească chiar așa, ar trebui să punem în valoare locul din ea, să o facem cât mai compactă. Dar aplicația se dezvoltă și vor exista multe astfel de machete, iar în timp vor deveni din ce în ce mai multe.

Prin urmare, în cazul unei aplicații mobile, este de preferat o altă modalitate - salvați structura metadatelor direct în fișierul de date... La ieșire, obținem un astfel de fișier, unde mai întâi stocăm câteva date auxiliare - versiunea de configurare, schema de configurare, limitele secvenței, iar după aceea scriem datele utilizatorului în format XML. Mai mult, în secțiunea „Date auxiliare” a fișierului, puteți stoca și alte date importante care, din anumite motive, nu au putut fi scrise în XML.

Luăm schema de date pe care am salvat-o în fișier și pe baza acesteia construim pachetul XDTO pentru citirea fișierului. Creăm un obiect similar în baza de date, îl completăm, efectuăm procesarea reumplerii la actualizare și salvăm obiectul deja terminat în baza de date.

Mai jos, în imagine, puteți vedea un indiciu despre cum să scrieți frumos modelul XDTO al acestor configurații. Compania care a lansat aplicația Boss a experimentat acest lucru, a găsit mai multe modalități, dar a optat pentru această opțiune pentru înregistrarea schemei de metadate. Când deschideți fișierul de date în sine, puteți vedea XML structurat obișnuit, care poate fi citit, care listează toate metadatele aplicației.

// Scrieți schema de configurare ModelXDTO = FactoryXDTO.ExportModelsXDTO ("http://v8.1c.ru/8.1/data/enterprise/current-config"); XDTO Factory.WriteXML (UploadFile, model XDTO); // Citirea schemei de configurare Model XDTO = Factory XDTO Citire XML (Read XML, Factory XDTO. Type ("http://v8.1c.ru/8.1/xdto", "Model")); UnloadFactory = New XDTOFactory (XDTOModel);

Pentru a proteja utilizatorul, este imperativ să-l întrebați din nou dacă trebuie să restabilească backupul. Poate că doar experimenta și făcea clic pe toate butoanele din aplicație :) Și acum datele curente s-ar putea pierde. Prin urmare, atunci când efectuează acțiuni potențial „periculoase”, precizăm întotdeauna dacă își dorește cu adevărat acest lucru și cum ar trebui făcut. Utilizatorul trebuie să fie conștient de acțiunile sale.

Trebuie să existe un mecanism de creare a backup-urilor atunci când vorbim de o soluție autonomă, când utilizatorul are toate datele stocate exclusiv pe un dispozitiv mobil: utilizatorul își poate pierde dispozitivul, iar atunci datele se vor pierde. Și, s-ar părea, dacă aplicația nu funcționează autonom, ci este conectată la un server central, atunci utilizatorul nu ar trebui să aibă o astfel de problemă, pentru că dacă dispozitivul se pierde, se va conecta la server, va primi toate datele sale. din nou de pe server și totul va fi ok.

Cu toate acestea, utilizatorii nu folosesc întotdeauna copiile de siguranță așa cum ne așteptăm:) Ei le folosesc foarte des pentru a pur și simplu „retroduce” datele înapoi. Acesta este într-adevăr un comportament foarte ciudat, dar utilizatorii de aplicații mobile sunt prea leneși pentru a-și da seama unde ar putea greși atunci când introduc date și pur și simplu derulează înapoi datele și reintroduc datele pentru ziua curentă. După ce am analizat statisticile de lucru cu aplicația Boss, ne-am dat seama că aceasta este o practică normală și acest comportament al utilizatorului este mai frecvent decât ne-am fi așteptat.

Și dacă utilizați sincronizarea cu alte dispozitive, atunci trebuie să vă descurcați. Există mai multe soluții aici:

întrerupeți conexiunea cu serverul, precizând că datele de pe acesta vor rămâne așa cum au fost, iar copia va fi restaurată doar pe dispozitivul utilizatorului;
este mai bine ca utilizatorul să-l lase să restaureze o copie dintr-o dată pe toate dispozitivele, după ce a prescris anterior astfel de mecanisme.

Mai este un lucru aici. Până acum, salvam noi înșine copiile de siguranță, controlam întregul proces, surprindeam acțiunile utilizatorului chiar în cod atunci când apăsa butonul „salvați o copie”. Toate acestea pot fi procesate ulterior. În platforma 8.3.9, a devenit posibilă salvarea copiilor de rezervă exact prin intermediul platformei. Și utilizatorul face asta fără știrea noastră. Dacă se utilizează sincronizarea cu o bază de date centrală, atunci un astfel de scenariu trebuie gestionat. Trebuie să aflăm cumva pe serverul nostru că utilizatorul a restaurat o copie salvată anterior și trebuie să îi oferim un fel de soluție. Nu ne permitem să avem date nesincronizate.

SCHIMB VALUTAR

Când vorbim despre o soluție privată pe o platformă mobilă, avem de obicei un client care, de exemplu, dorește să folosească o platformă mobilă pentru agenții săi de vânzări și astfel încât aceștia să facă schimb de date cu o bază de date centrală. Totul este simplu aici: o bază de date, mai multe dispozitive, ridicați serverul, stabiliți comunicarea cu acesta. Deci problema schimbului între dispozitive este ușor de rezolvat.

Dar dacă vorbim de o aplicație de masă, unde există multe baze de date, fiecare având un număr foarte mare de utilizatori, situația devine mai complicată. Utilizatorii au descărcat aplicația de pe piață și doresc să se sincronizeze între ei. De exemplu, un soț a descărcat o aplicație de contabilitate pentru finanțele personale, iar acum vrea să se conecteze și soția lui, iar ei lucrează împreună în aceeași aplicație. Sunt mulți utilizatori, aplicația se dezvoltă, crește și este nevoie de un număr mare, mare de baze de date. Cum să organizezi toate acestea? Utilizatorii nu vor contacta personal dezvoltatorii pentru a crea o bază de date separată pentru ei și pentru a activa sincronizarea. Vor să apese un buton și să-l facă să funcționeze imediat. In acelasi moment.

Cum se procedează? Aici vine în ajutor mecanismul de partajare a datelor. Vă permite să organizați o singură bază de date, unde există o singură configurație comună, dar, în același timp, un număr nelimitat de baze de utilizatori sunt stocate într-o bază de date comună.

Cea mai bună parte este că puteți adăuga utilizatori dinamic, programatic, fără participarea noastră. În realitate, utilizatorii pur și simplu dau clic pe butonul „Înregistrează-te pe server” și totul se întâmplă de la sine: pe server i se creează o bază de date personală și poate începe imediat să lucreze în ea.

Cum să o facă? Prima și cea mai simplă soluție este să vă scrieți propria bază de server cu acest mecanism. Când compania noastră a început să producă aplicația Boss și să schimbe în ea, în prima versiune am făcut exact asta: am scris o bază de date de server cu un mecanism de partajare a datelor. Totul a funcționat, mai ales că nu a fost nimic complicat - separatorul de bază este o recuzită comună.

Dar apoi ne-am dat seama că reinventăm roata :) De fapt, există o soluție gata făcută, și deja a ținut cont de punctele la care nici măcar nu ne-am gândit încă. Acesta este 1C: proaspăt.

Scalabilitatea serviciului este gândită aici: ce să faci când vor exista o mulțime de date și baze de date, cum să crești cu toate acestea. Există un punct în legătură cu crearea de copii de rezervă ale zonelor de date: adică nu facem doar copii de rezervă pentru o bază de date comună, ci facem copii ale unui anumit utilizator. Mai mult, mecanismul de acolo este astfel încât copiile se fac numai atunci când sunt cu adevărat necesare. Dacă un utilizator nu a intrat în baza de date timp de o săptămână, atunci nu facem copii ale acestuia, pentru că nu s-a schimbat nimic acolo. O altă caracteristică Fresh este că serviciul implementează un mecanism pentru a reduce sarcina pe server, ceea ce este foarte important atunci când aveți o mulțime de baze de date.

În general, Fresh pentru noi este ceva nou și interesant. Încetul cu încetul încercăm să ne dăm seama, dar în cea mai mare parte suntem doar mulțumiți de munca sa.

Transfer de date. Cum se implementează pentru schimbul între dispozitive

Platforma oferă două mecanisme - servicii SOAP și http. Există nuanțe privind modul de accesare a acestor servicii atunci când este implicat mecanismul de partajare a datelor. În special, trebuie să adăugați parametri care indică numărul specific al zonei pe care o accesați, deoarece platforma nu poate determina ce bază de date să acceseze după numele de utilizator. În plus, unul și același utilizator poate lucra cu mai multe baze de date în cadrul unei singure baze de date (vezi imaginea).

În ceea ce privește serviciile, aplicația Boss implementează schimbul instantaneu: un utilizator introduce date, iar celălalt le primește. Utilizatorii aplicațiilor mobile sunt obișnuiți cu faptul că totul se întâmplă instantaneu, așa că ne-am gândit ce serviciu este mai bine să folosim - SOAP sau http. Viteza de conectare a jucat un rol esențial. În http, viteza conexiunii este mult mai mare, iar atunci când ne conectăm prin SOAP, primim o descriere a serviciului, care este grea și durează mult să se încarce. Platforma are o modalitate de a stoca o descriere a unui serviciu, dar din cauza parametrilor pe care îi adăugăm dinamic, nu putem folosi referințe WS. În plus, accesarea serviciilor http este mai convenabilă și mai flexibilă în experiența noastră.

Deci, scopul nostru este să implementăm schimbul în timp real. Adică încercăm să nu-l facem pe utilizator să meargă undeva, să facă clic pe un buton, să ne gândim cât de relevante sunt datele lui, dacă ar trebui să le actualizeze... Datele ar trebui să fie întotdeauna relevante pentru utilizatori. Sunt atât de obișnuiți să lucreze în mesagerie instant - unul a trimis datele, celălalt le-a primit imediat. Totul se întâmplă instantaneu. Același lucru este valabil și pentru aplicațiile legate de afaceri: un vânzător a emis o vânzare, celălalt trebuie să vadă imediat situația actuală fără a lua nicio măsură.

Prin urmare, aplicația Boss folosește joburi de fundal pentru schimburi. După ce fiecare dată este scrisă în baza de date, este pornit un job de fundal, care inițiază schimbul. Prima parte este trimiterea datelor către server. Apoi, alte dispozitive trebuie să știe că există date noi. Pentru aceasta folosim notificări PUSH. Această schemă funcționează deja și funcționează suficient de rapid.

Dar ne-am dorit și mai rapid, pentru că lucrăm în timp real și de obicei avem puține date. Avem XML mic, dar în același timp trimitem un mesaj cu aceste date de la primul dispozitiv către server, serverul trimite PUSH către alt dispozitiv, iar apoi al doilea dispozitiv, după ce a primit PUSH, inițiază un schimb din partea sa, se adresează serverului și solicită date, primește aceste date și apoi trimite un răspuns că datele au fost primite. Este o perioadă lungă de timp, dar datele în sine au fost foarte mici.

Ne-am gândit cum poate fi accelerat acest proces.

Pentru a face acest lucru, ne-am dat seama ce conține PUSH, cum poate fi încă folosit. S-a dovedit că PUSH conține câmpuri precum date și text. Documentația iOS și Android conține restricții cu privire la dimensiunea mesajelor PUSH, dar acest lucru nu ni s-a părut suficient și am vrut să ne dăm seama empiric. Și am verificat că suma caracterelor valide este de 981 de caractere pentru iOS și 3832 de caractere pentru Android. În acest din urmă caz, este foarte posibil să se folosească restricția; unul sau mai multe obiecte de bază pot fi înghesuite într-un astfel de volum. Și apoi dezvoltatorii companiei au schimbat puțin schema. Când nu sunt multe date, le trimitem de pe un dispozitiv, le primim pe server, le împachetăm în PUSH acolo și le trimitem direct către alt dispozitiv din el. Schema a devenit mai scurtă, iar schimbul a început să aibă loc și mai repede :)

Un punct important al utilizării PUSH este să nu enervezi utilizatorii.

Este foarte ușor să scapi de această situație: doar nu trimite multe mesaje PUSH utilizatorului :) Dacă lucrează în aplicație acum, poți trimite o mulțime de mesaje. Când platforma rulează, utilizatorul nu vede PUSH, totul se întâmplă automat pentru el. Dar când aplicația este închisă, clientul are o mulțime de mesaje necitite. Prin urmare, în niciun caz nu trebuie trimis următorul PUSH până când nu se primește un răspuns de la dispozitiv că aplicația rulează, este activă și PUSH-ul anterior a fost deja procesat.

O altă nuanță a schimbului este munca prin web. Trebuie să profităm la maximum de asincronie. Nu puteți lucra ca de obicei - scrieți codul - apelați funcția - așteptați să se execute - obțineți răspunsul - și totul este ok. Dacă lucrați pe web, vă veți confrunta în continuare cu anumite limitări, de exemplu, internet instabil, timeout-uri declanșate atunci când efectuați operațiuni pe termen lung. Prin urmare, este necesar să ne gândim în avans la arhitectură.

Să ne uităm la un exemplu de înregistrare a unui dispozitiv, ce se întâmplă într-o aplicație atunci când un utilizator dorește să se înregistreze. El ține evidențe o vreme, a introdus multe date, dar apoi vrea să lucreze și vânzătorul cu această bază de date. Utilizatorul face clic pe butonul „Înregistrare”. La început totul a fost foarte simplu: i-au luat datele, le-au înregistrat pe server și, vă rog, puteți lucra și conecta utilizatori. Dar apoi ne-am confruntat cu o situație în care pentru unii utilizatori, bazele de date de pe dispozitiv până la momentul înregistrării crescuseră deja foarte mult. Și această schemă nu a mai funcționat, de atunci în timp ce întreaga bază de date era înregistrată pe server, expirarea conexiunii a fost declanșată sau pur și simplu internetul a fost întrerupt. Prin urmare, am înlocuit un apel sincron cu multe apeluri scurte. Acum datele sunt partajate în loc să fie transmise toate odată. Nu așteptăm în niciun fel ca serverul să prelucreze și să înregistreze date. Am trimis date, am primit un răspuns că datele au fost primite, am închis conexiunea. Periodic, trebuie să interogați serverul, ce se întâmplă acolo și cum și, între timp, pe server rulează un job de fundal, care înregistrează datele primite. În acest fel primim o mulțime de apeluri pe server, dar avem garanția că totul va merge bine. Și nici timeout-urile, nici instabilitatea internetului nu vă vor împiedica să încărcați toate datele pe server.

ACTUALIZĂRI

Schimb între dispozitive cu diferite versiuni ale aplicației

Întrucât vorbim despre o aplicație în masă care este lansată pe piețe, trebuie să ținem cont de câteva dintre caracteristicile procesului de actualizare și schimb de date.

Dacă ați lansat o aplicație pentru o întreprindere și ați decis să o actualizați, atunci de obicei dați doar o comandă, astfel încât toți angajații să instaleze noua aplicație împreună. Acest lucru nu se poate face cu utilizatorii care au descărcat aplicația de pe piață. Nu le poți spune deloc ce să facă. De exemplu, lucrează într-o aplicație și nu doresc să o actualizeze nici acum, nici niciodată. Nu au auto-update, așa că este o situație destul de comună când mai multe dispozitive sunt conectate la baza centrală și toate sunt cu versiuni diferite. Un alt motiv pentru acest fenomen este timpul de publicare pe piețe: este diferit pentru iOS și Android. Implementăm adesea lucruri cheie, de exemplu, remediem erori critice și nu vrem să așteptăm ca iOS să verifice o nouă versiune timp de două săptămâni, vrem cel puțin doar pentru Android, dar vrem să lansăm o actualizare chiar acum.

Nu avem dreptul de a comanda utilizatorilor. Dacă vor, sunt actualizate, iar dacă nu, nu fac nimic. Imaginea arată raportul instalărilor aplicației Boss în funcție de versiunile din GooglePlay, precum și statisticile de pe serverul nostru - raportul real al versiunilor de aplicații care sunt instalate pe dispozitivele care au schimbat date cu serverul în ultima săptămână. Iată un set cu care să lucrezi. Acestea sunt versiuni diferite și metadate diferite. Și trebuie să organizăm un schimb normal în același timp :)

Dezvoltatorii se confruntă cu următoarele sarcini:

Toate acestea trebuie să funcționeze. Utilizatorii nu ar trebui să simtă disconfort că au uitat să facă upgrade. Nu ar trebui să observe deloc. Actualizat - e mai bine, bine și bine.
Trebuie să asigurăm siguranța datelor. De exemplu, un utilizator are un director și o nouă recuzită, în timp ce altul nu are încă. Mai mult, dacă un utilizator care nu are detalii noi modifică ceva pe dispozitivul său, atunci datele de pe alte dispozitive nu ar trebui să se piardă.
Trebuie să ne asigurăm că datele sunt actualizate atunci când facem upgrade la o versiune nouă. Când utilizatorul decide că este gata să actualizeze, ar trebui să aibă automat toate informațiile noi pe care nu le-a avut doar pentru că avea o versiune veche.

Cum am făcut-o?

1. Folosim 2 planuri de schimb pe server. Primul este pentru partajarea între dispozitive, iar al doilea este pentru actualizări. De exemplu, am trimis un manual unui utilizator, dar acesta nu are unități de măsură, adică date incomplete. Trebuie să ne amintim asta. Iar când este actualizat, trebuie să-i trimitem toate informațiile pe care nu le avea. Pentru asta este al doilea plan de schimb.

2. Pentru a scrie și a citi obiecte, folosim același mecanism care se folosește pentru backup-uri, adică salvăm versiunea metadatelor. În acest caz, lucrăm cu serverul și ne putem permite să adăugăm orice dorim direct în configurație, așa că pur și simplu adăugăm scheme de metadate la configurație sub formă de layout-uri pe măsură ce aplicația se dezvoltă.

Cum să monitorizezi erorile masive în timpul schimbului și pe server

În primul rând, trebuie să controlați disponibilitatea serverului în sine. Acest lucru se întâmplă cu serverele - acestea cad. Nu am inventat nimic special pentru monitorizare, ci pur și simplu am găsit un bot în telegramă care țipă dacă ceva nu este în regulă. În fiecare minut verifică performanța serverului, iar dacă serverul este brusc indisponibil, începe să țipe, administratorii îl văd și aduc serverul.

De asemenea, colectăm jurnalul de erori din jurnal. De asemenea, nimic supranatural - colectăm doar un jurnal de erori la fiecare trei ore, le trimitem la e-mail și le revizuim periodic. Acest lucru vă ajută să vedeți probleme comune și anumite situații excepționale. Nu este greu să vă citiți e-mailurile, să găsiți și să remediați rapid erorile. Dar acest lucru vă permite să identificați și să rezolvați rapid problemele care pot crește odată cu creșterea bazelor de date.

Un alt punct important - asigurați-vă că oferiți utilizatorului posibilitatea de a „reclama”. Ne îmbunătățește statutul în ochii lor și ne salvează. Sunt utilizatori, așa cum îi numim noi, „isterici” care, la cea mai mică greșeală, încep să ne trimită o grămadă de mesaje prin poștă că nimic nu funcționează, baza de date nu se încarcă, totul este teribil de rău. Dar uneori chiar ne salvează, pentru că uneori găsesc astfel de bug-uri pe care alții în mod miraculos nu le-au găsit, bug-uri serioase.

Utilizatorul nu poate fi speriat. Nu mesaje înfricoșătoare, nimic altceva. Trebuie să explice totul frumos și să se ofere să se plângă. Și promitem că vom rezolva totul. Atunci utilizatorii sunt fericiți, pentru că văd că sunt îngrijiți și cred imediat că vor fi ajutați :)

Acest articol a fost scris pe baza rezultatelor raportului citit la conferința INFOSTART EVENT 2016 DEVELOPER. Mai multe articole pot fi citite.

În 2020, invităm pe toată lumea să participe la 7 întâlniri regionale, precum și la evenimentul aniversar INFOSTART 2020 de la Moscova.

O mare parte din modern aplicații pentru platforme mobile(iOS, Android etc.) funcționează în tandem cu un server. O aplicație cu date învechite își pierde utilitatea. Prin urmare, este important să vă asigurați că datele de la server la dispozitiv sunt păstrate la zi. Acest lucru se aplică aplicațiilor offline care ar trebui să funcționeze fără Internet. Aplicațiile complet online care nu funcționează (sau sunt inutile) fără Internet (de exemplu, Foursquare, Facebook) au propriile lor specificități care depășesc domeniul de aplicare al acestui articol.

Folosind exemplul uneia dintre aplicațiile noastre offline, vă voi spune ce abordări am folosit pentru a sincroniza datele. În primele versiuni ne-am dezvoltat algoritmi simpli și, pe viitor, cu experiență, i-am îmbunătățit. O secvență similară este prezentată în articol - de la simple practici evidente la altele mai complexe.

Trebuie clarificat faptul că articolul tratează transferul de date doar într-o singură direcție: de la server la dispozitiv. Aici serverul este sursa de date.

Prevederi generale pentru toate abordările

De exemplu, vom lua în considerare transferul unui director de feluri de mâncare („vase”) pe dispozitiv. Vom presupune că dispozitivul face o solicitare pentru adresa URL „/ service / dishes / update”, schimbul se efectuează prin protocolul http în format JSON ( www.json.org). Serverul are un tabel „dishes” cu următoarele câmpuri: id (identificatorul înregistrării), numele (numele antenei), actualizat (în momentul în care antena a fost actualizată, este mai bine să faceți imediat suport pentru fusul orar, „AAAA-LL -DDThh: mm: ssTZD”, de exemplu, „1997 -07-16T19: 20: 30 + 01: 00 ”, is_deleted (semnul înregistrării șterse).

Observație privind prezența ultimului câmp. Implicit, valoarea acesteia este 0. Într-o aplicație în care entitățile sunt sincronizate între client și server, nu este recomandată ștergerea fizică a datelor de pe server (pentru a evita erorile). Prin urmare, pentru preparatele șterse este setat is_deleted = 1. Când o entitate cu is_deleted = 1 ajunge la dispozitiv, aceasta este ștearsă de pe dispozitiv.

Cu orice abordare, care va fi luată în considerare mai jos, serverul returnează o serie de obiecte dispozitivelor JSON (poate fi goale):

[
(id: , Nume: , actualizat: , este șters: },…
]

Exemplu de răspuns al serverului:

[
(id: 5625, nume: „Bread”, actualizat: „2013-01-06 06:23:12”, isDeleted: 0),
(id: 23, nume: „Grosul gătit”, actualizat: „2013-02-01 14:44:21”, este Șters: 0), (

nume: "Supa de peste",

actualizat: "2013-08-02 07:05:19",

Principii de actualizare a datelor de pe un dispozitiv

Dacă un element care se află pe dispozitiv a venit și este șters = 0, atunci este actualizat
Dacă a sosit un element care nu este pe dispozitiv și esteDeleted = 0, atunci acesta este adăugat
Dacă un element care se află pe dispozitiv a venit și este șters = 1, atunci este șters
Dacă a sosit un element care nu este pe dispozitiv și esteDeleted = 1, atunci nu se face nimic

Abordarea 1: totul este întotdeauna sincronizat

Aceasta este cea mai ușoară metodă. Dispozitivul solicită o listă de antene de la server, iar serverul trimite întreaga listă. De fiecare dată vine toată lista. Nu sortat.

Exemplu de solicitare: nul sau „()”

Avantaje:

logica pe server este simplă - întotdeauna dăm totul
logica dispozitivului este simplă - întotdeauna suprascriem totul

Dezavantaje:

dacă solicitați lista des (la fiecare 10 minute), atunci va fi mult trafic pe Internet
dacă solicitați lista rar (o dată pe zi), atunci relevanța datelor va fi încălcată

Zona de aplicare:

pentru aplicații cu trafic redus
transmiterea de date care se modifică foarte rar (listă de orașe, categorii)
transferul setărilor aplicației
la începutul proiectului pentru primul prototip al unei aplicații mobile

Abordarea 2: sincronizați doar cele actualizate

Dispozitivul solicită o listă de feluri de mâncare, actualizată de la sincronizarea anterioară. Lista vine sortată după „actualizată” în ordine crescătoare (opțional, dar convenabil). Dispozitivul stochează valoarea „actualizată” pentru cel mai recent dish trimis și, la următoarea solicitare, o trimite la server în parametrul „lastUpdated”. Serverul trimite o listă de feluri de mâncare care sunt mai noi decât „lastUpdated” (actualizat> lastUpdated). La prima solicitare către server „lastUpdated” = nul.

Exemplu de solicitare: (ultima actualizare: „2013-01-01 00:00:00”)

În diagramă: „last_updated” este valoarea care este stocată pe dispozitiv. De obicei, pe dispozitiv este creat un tabel separat pentru a stoca aceste valori „last_updated” pentru fiecare entitate (dish, oraș, organizație etc.)

Această abordare este potrivită pentru sincronizarea listelor liniare simple în care regulile de sosire sunt aceleași pentru toate dispozitivele. Pentru o sincronizare mai selectivă, consultați „Abordarea 5: Sincronizarea cu cunoștințele despre ceea ce este deja pe dispozitiv”.

Această abordare acoperă de obicei majoritatea nevoilor. Pe dispozitiv vin doar date noi, vă puteți sincroniza cel puțin în fiecare minut - traficul va fi mic. Cu toate acestea, există probleme asociate cu limitările dispozitivelor mobile. Acestea sunt memoria și procesorul.

Abordarea 3: Sincronizarea în loturi

Dispozitivele mobile au un nivel scăzut de memorie RAM. Dacă există 3000 de dish-uri în director, atunci analizarea unui șir json mare de pe server în obiecte de pe dispozitiv poate cauza o lipsă de memorie. În acest caz, aplicația fie va bloca, fie nu va salva aceste 3000 de feluri de mâncare. Dar chiar dacă dispozitivul a reușit să digere un astfel de șir, atunci performanța aplicației în momentele sincronizării în fundal va fi scăzută (întârzieri de interfață, nu defilare lină etc.) Prin urmare, este necesar să solicitați lista in portii mai mici.

Pentru a face acest lucru, dispozitivul mai trece un parametru („cantitate”), care determină dimensiunea porțiunii. Lista trebuie trimisă sortată după câmpul „actualizat” în ordine crescătoare. Dispozitivul, similar cu abordarea anterioară, își amintește valoarea „actualizată” a ultimei entități trimise și o transmite câmpului „lastUpdated”. Dacă serverul a trimis exact același număr de entități, atunci dispozitivul continuă sincronizarea și face din nou o solicitare, dar cu „lastUpdated” actualizat. Dacă serverul a trimis mai puține entități, aceasta înseamnă că nu are mai multe date noi, iar sincronizarea se termină.

În diagramă: „last_updated” și „amount” sunt valorile care sunt stocate în aplicatie de mobil... „Last_item” - ultima entitate (dish) trimisă de pe server. Mai nou decât această valoare va fi solicitată următoarea listă.

Exemplu de solicitare: (ultima actualizare: „2013-01-01 00:00:00”, suma: 100)

Avantaje:

Dispozitivul primește cât de multe date este capabil să proceseze la un moment dat. Mărimea porției este determinată de teste practice. Entitățile simple pot fi sincronizate câte 1000 la un moment dat. Dar se întâmplă și ca entitățile cu un număr mare de câmpuri și cu o logică complexă de procesare a stocării să fie sincronizate în mod normal nu mai mult de 5 bucăți.

Dezavantaje:

Dacă există 250 de feluri de mâncare cu aceeași actualizare, atunci cu cantitate = 100, ultimele 150 nu vor fi trimise pe dispozitive. Această situație este destul de reală și este descrisă în următoarea abordare.

Abordarea 4: sincronizarea corectă a lotului

În abordarea anterioară, este posibil ca dacă tabelul conține 250 de feluri de mâncare cu același „actualizat” (de exemplu, „2013-01-10 12:34:56”) și dimensiunea porției să fie 100, atunci numai primele 100 vor veni înregistrări. Cele 150 rămase vor fi decupate greu (actualizate> ultima actualizare). De ce se va întâmpla asta? Când sunt solicitate primele 100 de înregistrări, lastUpdated va fi setat la „2013-01-10 12:34:56”, iar următoarea solicitare va avea condiția (actualizat> „2013-01-10 12:34:56”). Nici măcar atenuarea stării (actualizat> = „2013-01-10 12:34:56”) nu va ajuta, deoarece dispozitivul va solicita apoi la nesfârșit primele 100 de înregistrări.

Situația cu același „actualizat” nu este atât de rară. De exemplu, la importarea datelor dintr-un fișier text, câmpul „actualizat” a fost setat la ACUM (). Poate dura mai puțin de o secundă pentru a importa un fișier cu mii de linii. Se poate întâmpla și ca întregul director să aibă același „actualizat”.

Pentru a remedia acest lucru, trebuie să utilizați un câmp de antenă care ar fi unic cel puțin într-un moment („actualizat”). Câmpul „id” este unic în întregul tabel, așa că ar trebui să îl utilizați suplimentar în sincronizare.

Deci, implementarea acestei abordări arată astfel. Serverul returnează lista sortată după „actualizat” și „id”, iar dispozitivele solicită date folosind „lastUpdated” și noul parametru „lastId“. La server, condiția de selecție este mai complicată: ((actualizat> lastUpdated) SAU (actualizat = lastUpdated și id> lastId)).

În diagramă: „last_updated”, „last_id” și „amount” sunt valorile care sunt stocate în aplicația mobilă. „Last_item” - ultima entitate (dish) trimisă de pe server. Mai nou decât această valoare va fi solicitată următoarea listă.

Abordarea 5: sincronizați cu cunoștințele despre ceea ce este deja pe dispozitiv

Abordările anterioare nu țin cont de faptul că serverul nu știe cu adevărat cât de bine au fost salvate datele pe dispozitiv. Dispozitivul pur și simplu nu a putut salva unele dintre date din cauza unor erori inexplicabile. Prin urmare, ar fi bine să primim confirmarea de la dispozitiv că toate (sau nu) toate felurile de mâncare au fost păstrate.

În plus, utilizatorul aplicației poate configura aplicația în așa fel încât să aibă nevoie doar de o parte din date. De exemplu, un utilizator dorește să sincronizeze feluri de mâncare din doar 2 orașe din 10. Acest lucru nu poate fi realizat folosind sincronizările descrise mai sus.

Ideea din spatele abordării este următoarea. Serverul stochează (într-un tabel separat „stored_item_list”) informații despre ce fel de mâncare sunt pe dispozitiv. Ar putea fi doar o listă de perechi „id - actualizate”. Acest tabel conține toate listele de perechi de antene „id - actualizate” pentru toate dispozitivele.

Dispozitivul trimite informații despre antene disponibile pe dispozitiv (lista de perechi „id - actualizat”) către server împreună cu o solicitare de sincronizare. Când este solicitat, serverul verifică ce antene ar trebui să fie pe dispozitiv și care sunt acum. Diferența este apoi trimisă la dispozitiv.

Cum stabilește serverul ce fel de mâncare ar trebui să fie pe dispozitiv? În cel mai simplu caz, serverul face o solicitare care va returna o listă de perechi „id - actualizat” cu toate felurile de mâncare (de exemplu, SELECT id, updated FROM dishes). În diagramă, acest lucru se face prin metoda „WhatShouldBeOnDeviceMethod ()”. Acesta este dezavantajul abordării - serverul trebuie să calculeze (uneori făcând interogări sql grele) ce ar trebui să fie pe dispozitiv.

Cum stabilește serverul ce fel de mâncare sunt pe dispozitiv? Face o interogare la tabelul „stored_item_list” pentru acest dispozitiv și primește o listă de perechi „id - actualizat”.

Analizând aceste două liste, serverul decide ce trebuie trimis către dispozitiv și ce trebuie șters. În diagramă, aceasta este „delta_item_list”. Prin urmare, cererea nu conține „lastUpdated” și „lastId”, sarcina lor este îndeplinită de perechile „id - updated”.

Cum știe serverul despre felurile disponibile pe dispozitiv? În cererea către server, se adaugă un nou parametru „articole”, care conține o listă cu id-urile antenei care au fost trimise dispozitivului în ultima sincronizare („device_last_stored_item_list”). Desigur, puteți trimite o listă cu id-urile tuturor antenei care se află pe dispozitiv și nu complicați algoritmul. Dar dacă pe dispozitiv sunt 3000 de vase și toate sunt trimise de fiecare dată, atunci costurile de trafic vor fi foarte mari. În marea majoritate a sincronizărilor, parametrul „articole” va fi gol.

Serverul trebuie să actualizeze constant „stored_item_list” cu datele care au venit de la dispozitiv în parametrul „items”.

Ar trebui să implementați un mecanism pentru ștergerea datelor de server din stored_item_list. De exemplu, după reinstalarea unei aplicații pe un dispozitiv, serverul va presupune că dispozitivul este încă actualizat. Prin urmare, la instalarea aplicației, dispozitivul trebuie să informeze cumva serverul, astfel încât să ștergă lista_de_articole_ stocate pentru acest dispozitiv. În aplicația noastră, trimitem un parametru suplimentar „clearCache” = 1 în acest caz.

Concluzie

Un tabel rezumativ al caracteristicilor acestor abordări:

№	O abordare	Volumul traficului(5 - mare)	Intensitatea muncii de dezvoltare(5 - mare)	Utilizarea memoriei dispozitivului(5 - mare)	Corectitudinea datelor de pe dispozitiv(5 - mare)	Puteți selecta un anumit dispozitiv
1	Totul este întotdeauna sincronizat	5	1	5	5	Nu
2	Doar cele actualizate	1	2	5	3	Nu
3	Sincronizare în loturi	1	3	1	3	Nu
4	Sincronizare corectă în loturi	1	3	1	3	Nu
5	Sincronizare cu cunoașterea a ceea ce este deja pe dispozitiv	2	5	2	5	da

„Corectitatea datelor de pe dispozitiv” este probabilitatea ca dispozitivul să conțină toate datele care au fost trimise de server. În cazul abordărilor #1 și #5, există o certitudine de 100% că dispozitivul are toate datele de care are nevoie. În alte cazuri, nu există o astfel de garanție. Acest lucru nu înseamnă că alte abordări nu pot fi utilizate. Doar că, dacă o parte din date se pierde pe dispozitiv, atunci nu va fi posibil să o repari de pe server (și cu atât mai mult pentru a afla despre asta pe partea de server).

Poate că, în prezența tarifelor de internet nelimitate și a wifi-ului gratuit, problema limitării traficului generat de o aplicație mobilă va deveni mai puțin relevantă. Dar, în timp ce trebuie să mergeți la tot felul de trucuri, veniți cu abordări mai inteligente care pot reduce costurile rețelei și pot crește performanța aplicațiilor. Nu merge întotdeauna. Uneori este „cu cât mai simplu, cu atât mai bine”, în funcție de situație. Sperăm că, din acest articol, puteți alege o abordare care vă este utilă.

Există în mod surprinzător de puține descrieri ale sincronizării serverului pe Internet și dispozitive mobile... Mai mult, există multe aplicații care funcționează conform acestei scheme. Pentru cei interesați, câteva link-uri.