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

BACKUP-uri

De ce aveți nevoie de copii de rezervă pe platforma mobilă?

Experții știu cât de nesigure sunt uneori aplicațiile mobile de pe 1C: erorile pot apărea în orice moment, din cauza cărora bazele de date ale utilizatorilor vor fi pur și simplu distruse. În același timp, ne confruntăm cu lipsa de încredere a dispozitivelor în sine: acestea pot fi sparte, pierdute, furate, iar utilizatorii doresc să-și salveze datele. Și până la versiunea 8.3.9, nu aveam un mecanism de platformă pentru salvarea copiilor de rezervă.

Deoarece utilizatorii nu aveau anterior un buton „Salvați o copie”, dezvoltatorii aplicației Boss au trebuit să facă ei înșiși copii de siguranță. Cum am făcut-o?

Salvăm datele bazei de date în sine în formă 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 singuri prin e-mail, salvați pe dispozitivul lor.

Astfel, dezvoltatorii se asigură suplimentar. Dacă ceva nu merge bine și, brusc, mecanismul de creare a copiilor pe Google Drive sau Yandex Drive se defectează, puteți oricând să spuneți utilizatorului că acest moment dezvoltatorul se ocupă de eroare, dar deocamdată poate salva datele cale alternativă. Și utilizatorii sunt mulțumiți pentru că pot fi siguri de datele lor.

Neapărat trebuie să se concentreze asupra servicii 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 Cu siguranță reamintim utilizatorului necesitatea de a crea copii de rezervă.

Cum se salvează copii dacă se modifică configurația?

Când vorbim despre o soluție de masă, o aplicație care se schimbă, se dezvoltă și se îmbunătățește constant, trebuie să ținem cont de comportamentul clienților. Este posibil ca utilizatorul să dorească să restabilească o copie de rezervă salvată în versiune veche aplicație unde nu existau detalii. Și atunci apare sarcina: citiți datele, apoi completați datele conform logicii actualizării din versiunea veche a aplicației. Cum să o facă? Pe lângă date, salvați și structura de date în sine, pentru ca mai târziu să știți să o citiți.

Există mai multe opțiuni pentru stocarea acestei structuri de date, inclusiv stocarea acesteia în configurația în sine. Adică, atunci când lansați fiecare versiune nouă, păstrați structura metadatelor versiunea anterioaraîn layout în configurație.

Nu trebuie să uităm că într-o aplicație mobilă configurația nu trebuie pur și simplu să crească, trebuie să punem în valoare spațiul din ea, trebuie să o facem cât mai compactă. Dar aplicația se dezvoltă și vor exista multe astfel de machete, iar în timp vor fi 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 acest fișier, unde mai întâi stocăm câteva date auxiliare - versiunea de configurare, diagrama de configurare, limitele secvenței și apoi scriem datele utilizatorului în sine. 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 ei construim un pachet XDTO pentru citirea fișierului. Creăm un obiect similar în baza de date, îl umplem, efectuăm procesări suplimentare la actualizare și salvăm obiectul terminat în baza de date.

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

// Înregistrarea diagramei de configurare ModelXDTO = FactoryXDTO.ExportModelXDTO("http://v8.1c.ru/8.1/data/enterprise/current-config"); FactoryXDTO.WriteXML(UploadFile, ModelXDTO); // Citirea schemei de configurare ModelXDTO = FactoryXDTO.ReadXML(ReadXML, FactoryXDTO.Type("http://v8.1c.ru/8.1/xdto","Model")); FactoryUnload = New FactoryXDTO(ModelXDTO);

Pentru a proteja utilizatorul, trebuie să-l întrebați din nou dacă trebuie să restabilească backupul. Poate că doar experimenta și apăsa toate butoanele din aplicație :) Și acum s-ar putea să-și piardă datele actuale. Prin urmare, atunci când efectuăm acțiuni potențial „periculoase”, clarificăm întotdeauna dacă își dorește cu adevărat acest lucru și cum ar trebui să se întâmple. 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 offline, 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ă, deoarece 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ță în modul în care ne așteptăm de la ei :) Ei le folosesc foarte des pentru a pur și simplu „retroduce” datele. Acesta este un comportament foarte ciudat, dar utilizatorii aplicatii mobile prea leneși să-și dea seama unde ar fi putut să facă o greșeală la introducerea datelor ș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 un astfel de comportament al utilizatorului este mai frecvent decât ne-am fi putut imagina.

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

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

Mai este un punct aici. Până acum, am salvat singuri copiile de rezervă, am controlat întregul proces și am prins acțiunile utilizatorului chiar în cod atunci când a făcut clic pe butonul „Salvați o copie”. Toate acestea pot fi procesate ulterior. În platforma 8.3.9, a devenit posibilă salvarea copiilor de rezervă folosind instrumentele 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 procesat. 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 putem permite ca datele să nu se sincronizeze.

SCHIMBURI

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 să îi pună să facă schimb de date cu o bază de date centrală. Totul este simplu aici: o bază de date, mai multe dispozitive, configurați un server, stabiliți o conexiune cu acesta. Deci problema schimbului între dispozitive este ușor de rezolvat.

Dar dacă vorbim de o aplicație de masă, în care există multe baze de date, fiecare având o mulțime 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 pentru contabilitatea finanțelor personale și acum vrea să se conecteze și soția lui, iar aceștia 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ă facă totul să funcționeze imediat. In acelasi moment.

Cum se procedează? Aici vine în ajutor mecanismul de separare 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 date 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 „Înregistrați-vă pe server” și totul se întâmplă de la sine: o bază de date personală este creată pe server ș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 pe server cu un mecanism de partajare a datelor. Totul a funcționat, mai ales că nu a fost nimic complicat - separatorul de bază este un atribut comun.

Dar apoi ne-am dat seama că reinventăm roata :) De fapt, deja există soluție gata făcută, și ia deja în considerare puncte 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 există o mulțime de date și baze de date, cum să crești cu toate acestea. Există un moment aici despre creație copii de rezervă zone de date: adică nu facem doar backup la o bază de date comună, ci facem copii utilizator specific. Mai mult, mecanismul de acolo este astfel încât copiile se fac doar atunci când sunt cu adevărat necesare. Dacă un utilizator nu s-a autentificat în baza de date timp de o săptămână, atunci nu facem copii pentru el, pentru că nu s-a schimbat nimic acolo. O altă caracteristică a Fresh este că serviciul implementează un mecanism de reducere a încărcăturii pe server, iar acest lucru este foarte important atunci când aveți multe baze de date.

În general, Fresh este ceva nou și interesant pentru noi. Încercăm încet să ne dăm seama, dar în cea mai mare parte suntem mulțumiți de modul în care funcționează.

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

Platforma oferă două mecanisme - servicii SOAP și http. Există aici nuanțe despre cum să accesați aceste servicii atunci când este implicat mecanismul de separare a datelor. În special, trebuie să adăugați parametri care indică numărul specific de zonă pe care o accesați, deoarece platforma nu poate determina ce bază de date să acceseze din numele de utilizator. În plus, 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 altul le primește. Utilizatorii aplicațiilor mobile sunt obișnuiți ca totul să se întâmple instantaneu, așa că ne-am gândit cum un serviciu mai bun utilizați - 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 descrierea serviciului, dar din cauza parametrilor pe care ii adaugam dinamic, nu putem folosi link-uri WS. În plus, accesarea serviciilor http este mai convenabilă și mai flexibilă, din experiența noastră.

Deci, scopul nostru este să implementăm schimbul în timp real. Adică încercăm să nu facem astfel încât utilizatorul să fie nevoit să meargă undeva, să facă clic pe un buton, să ne gândim cât de actualizate sunt datele lui, dacă ar trebui să le actualizeze... Datele utilizatorilor ar trebui să fie mereu la zi -până în prezent. Sunt atât de obișnuiți cu asta atunci când lucrează î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 finalizat o vânzare, celălalt trebuie să vadă imediat situația actuală fără a lua nicio măsură.

De aceea, aplicația Boss folosește joburi de fundal pentru schimburi. După fiecare intrare de date în baza de date, se lansează un job de fundal care inițiază schimbul. Prima parte este să trimiteți datele către server. Apoi, alte dispozitive ar trebui să știe că există date noi. Pentru aceasta folosim notificări PUSH. Această schemă funcționează deja și funcționează destul de repede.

Dar am vrut să o facem și mai repede, deoarece lucrăm în timp real și, de regulă, nu avem multe 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-ul, inițiază schimbul din partea sa , contactează serverul ș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 erau foarte puține date.

Ne-am întrebat cum ar putea fi accelerat acest proces.

Pentru a face acest lucru, ne-am dat seama ce conține PUSH și cum poate fi, de asemenea, utilizat. S-a dovedit că PUSH conține câmpuri precum date și text. Documentația pentru iOS și Android indică restricții privind dimensiunea mesajelor PUSH, dar acest lucru nu ni s-a părut suficient și am vrut să ne dăm seama prin experiență. Și am verificat că pentru iOS suma caracterelor permise este de 981 de caractere, iar pentru Android este de 3832 de caractere. În acest din urmă caz, restricția poate fi utilizată; unul sau mai multe obiecte de bază de date pot fi stoarse î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, acolo le împachetăm în PUSH și le trimitem direct către alt dispozitiv. Schema a devenit mai scurtă, iar schimbul a început să aibă loc și mai repede :)

Un aspect important în utilizarea PUSH este că nu irităm utilizatorii.

Este foarte ușor să scapi de această situație: doar nu trimiteți utilizatorului multe mesaje PUSH :) Dacă lucrează în prezent în aplicație, puteți trimite o mulțime de mesaje. Când platforma rulează, utilizatorul nu vede PUSH, totul se întâmplă automat. Dar când aplicația este închisă, clientul are multe 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ță de schimb este funcționarea prin web. Trebuie să folosim asincronia cât mai mult posibil. Nu poți lucra ca de obicei - ai scris codul - ai numit funcția - ai așteptat să fie executat - ai primit un răspuns - și totul este ok. Dacă lucrați prin web, veți întâmpina în continuare anumite limitări, de exemplu, internet instabil, timeout-uri atunci când efectuați operațiuni de lungă durată. Prin urmare, este necesar să se gândească în avans la arhitectură.

Folosind exemplul de înregistrare a dispozitivului, să ne uităm la ce se întâmplă în aplicație atunci când utilizatorul dorește să se înregistreze. Ține evidențe de ceva timp, 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-am luat datele, le-am înregistrat pe server și, vă rog, puteți lucra și conecta utilizatori. Dar apoi am întâlnit o situație în care bazele de date ale unor utilizatori de pe dispozitivul lor crescuseră deja semnificativ până la momentul în care s-au înregistrat. Și această schemă nu a mai funcționat, pentru că... În timp ce întreaga bază de date era înregistrată pe server, conexiunea a expirat sau pur și simplu s-a oprit Internetul. Prin urmare, am înlocuit un apel sincron cu multe apeluri scurte. În zilele noastre, datele sunt partajate mai degrabă decât transferate dintr-o dată. Nu așteptăm sub nicio formă cât serverul procesează și scrie date. Am trimis datele, am primit un răspuns că datele au fost primite și am închis conexiunea. Periodic, trebuie să interogați serverul pentru a afla ce se întâmplă acolo și cum și, între timp, pe server rulează un job de fundal, care înregistrează datele primite. Acest lucru duce la 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ă luăm în considerare unele caracteristici ale procesului de actualizare și schimb de date.

Dacă ați lansat o aplicație pentru o întreprindere și decideți să o actualizați, atunci de obicei dați pur și simplu o comandă, astfel încât toți angajații să instaleze în unanimitate noua aplicație. 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ă în aplicație și nu doresc să o actualizeze nici acum, nici niciodată. Nu au auto-actualizări, așa că este o situație complet comună când mai multe dispozitive sunt conectate la baza de date centrală și toate au versiuni diferite. Un alt motiv pentru acest fenomen este timpul de publicare în piețe: este diferit pentru iOS și Android. Adesea implementăm lucruri cheie, de exemplu, repararea erori criticeși nu vreau să aștept ca iOS să verifice timp de două săptămâni versiune noua, vrem să facem cel puțin doar pentru Android, dar lansăm actualizarea chiar acum.

Nu avem dreptul de a comanda utilizatorilor. Dacă vor, se actualizează, iar dacă nu, nu fac nimic. Imaginea arată raportul instalărilor aplicației Boss după versiune pe GooglePlay, precum și statisticile de pe serverul nostru - raportul real al versiunilor de aplicație care sunt instalate pe dispozitivele care au schimbat date cu serverul în ultima săptămână. Acesta este setul cu care trebuie să lucrați. Acest versiuni diferiteși diverse metadate. Și trebuie să organizăm un schimb normal în acest caz :)

Dezvoltatorii se confruntă cu următoarele sarcini:

Toate acestea trebuie să funcționeze. Utilizatorii nu ar trebui să se simtă deranjați pentru că au uitat să actualizeze. Nu ar trebui să observe deloc. Actualizat - a devenit mai bine, bine, bine.
Trebuie să asigurăm siguranța datelor. De exemplu, un utilizator are un director și detalii noi, dar altul nu are încă unul. Mai mult, dacă un utilizator care nu are detalii noi modifică ceva pe dispozitivul său, atunci datele nu ar trebui să se piardă pe alte dispozitive.
Trebuie să ne asigurăm că datele sunt actualizate atunci când trecem la o versiune nouă. Când utilizatorul decide că este gata să facă upgrade, ar trebui să aibă automat toate informațiile noi pe care nu le-a avut doar pentru că avea versiunea 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, i-am trimis utilizatorului o carte de referință, 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. Acesta este motivul pentru care aveți nevoie de un al doilea plan de schimb.

2. Pentru a scrie și a citi obiecte, folosim același mecanism care este folosit pentru backup-uri, adică salvăm versiunea metadatelor. În acest caz, lucrăm cu un server și ne putem permite să adăugăm orice dorim direct la 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 se dezvoltă aplicația.

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 - se prăbușesc. 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ă. El verifică performanța serverului în fiecare minut și, dacă dintr-o dată serverul nu este disponibil, începe să țipe, administratorii văd acest lucru și ridică serverul.

De asemenea, colectăm jurnalele de erori din jurnal. Nimic prea elegant - colectăm doar jurnalele de erori la fiecare trei ore, le trimitem prin e-mail și le revizuim periodic. Te ajută să vezi probleme comune si unele situatii exceptionale. Nu este dificil să vizualizați e-mailurile, să urmăriți și să corectați rapid erorile. Dar acest lucru vă permite să identificați și să rezolvați rapid problemele care pot crește pe măsură ce bazele de date cresc.

Mai mult punct important- asigurați-vă că oferiți utilizatorului posibilitatea de a „reclama”. Acest lucru ne îmbunătățește statutul în ochii lor și ne salvează. Sunt utilizatori, așa cum îi numim noi, „isteric”, care, la cea mai mică greșeală, încep să ne trimită o grămadă de mesaje prin e-mail 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 bug-uri pe care alții în mod miraculos nu le-au descoperit încă, bug-uri serioase.

Utilizatorul nu trebuie să se sperie. Nu mesaje înfricoșătoare sau orice altceva. Trebuie să explice totul frumos și să-i invite 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 unui raport dat la conferința INFOSTART EVENT 2016 DEVELOPER. Mai multe articole pot fi citite.

În 2020, invităm pe toată lumea să ia parte la 7 întâlniri regionale, precum și la aniversarea INFOSTART EVENT 2020 la Moscova.

Dezvoltare server de aplicații

Introducere

Prezența online a devenit o necesitate pentru companiile moderne. Fără aceasta, este imposibil să construiești o interacțiune completă cu clienții. Adesea, pentru a rezolva o astfel de problemă, se recurge la crearea de aplicații client-server. Fiecare dintre ele constă dintr-o parte client și un back-end. Ultimul termen se referă la partea de server a aplicației. Dacă trebuie să schimbați singur conținutul în viitor program mobil, atunci Back-end-ul trebuie creat cu o calitate deosebit de înaltă. Appomart garantează că sarcinile atribuite vor fi îndeplinite în conformitate cu cerințele. Prin urmare, atunci când comandați crearea de aplicații server, puteți fi sigur de rezultatul potrivit.

Pentru ce este Back-end-ul?

Dezvoltarea aplicațiilor client-server presupune crearea a două părți. Primul, Front-end, acceptă cereri de la utilizatori. Ea este vizibilă de pe ecrane dispozitive mobile clientii. A doua, aplicația server, procesează cererile primite și acționează ca un panou administrativ. Bazele de date și logica programului sunt stocate aici. Fără aceasta, nicio aplicație client-server nu va funcționa. De fapt, back-end-ul este inima programului. Aceasta este inteligența care este responsabilă pentru procesarea cererilor clienților și viteza aplicației. Prin urmare, este important ca arhitectura aplicației server să fie gândită până la cel mai mic detaliu, astfel încât chiar și serviciile foarte încărcate să funcționeze fără probleme și rapid.

Cum să alegi un limbaj de programare?

În timpul pregătirii termeni de referinta(părți ale documentației de lucru pentru proiect), arhitectul proiectează un sistem de baze de date și conexiuni, descrie obiectele și proprietățile acestora și, de asemenea, dezvoltă metodele de server necesare (interogări pe care aplicațiile mobile le vor „utiliza” atunci când accesează serverul).

Importanța documentării și a proiectelor abandonate

Appomart este adesea abordat de clienți care au fost „abandonați” de alți contractori dintr-un motiv sau altul. Și luăm proiectul altcuiva, uneori chiar care funcționează incorect, să îi efectuăm auditul și rafinarea și sprijinul ulterioare. În curs de studiu cod sursași materialele primite de la client, ne confruntăm cu faptul că mulți dezvoltatori nu documentează în mod deliberat metodele serverului pentru a lega clientul de ei înșiși, din cauza incomensurabilității costurilor cu forța de muncă a transferului proiectului pentru a sprijini un alt dezvoltator, din cauza lipsa documentației pentru partea de server și, uneori, pur și simplu din cauza lipsei de profesionalism. Acest fapt, din păcate, nu este doar trist, ci și răspândit. Clientul, în acest caz, trebuie să plătească pentru dezvoltarea documentației pentru proiectul existent, precum și un audit al codului sursă, înainte de a putea evalua operabilitatea, comoditatea și fezabilitatea susținerii proiectului. Personalul Appomart păstrează întotdeauna documentația electronică a metodelor backend într-un format acceptat de Postman și Swagger pentru referințe viitoare.

Cum să verifici un antreprenor înainte de a semna un contract?

Vă îndemnăm să alegeți cu atenție un antreprenor și să vă concentrați nu numai pe prețul tentant, ci și pe lista documentelor pe care le veți primi odată cu proiectul, precum și condițiile de transfer al codului sursă și acoperirea codului cu comentarii. , scheme de baze de date (fie Mongo DB sau MySQL). Cheia succesului, de regulă, este o documentație de lucru competentă, care indică în mod clar cerințele pentru materialele transferate către dvs. la finalizarea fiecărei etape de lucru.

Caracteristici de dezvoltare

PHP pentru partea de server

Crearea unei părți server a aplicațiilor (a nu se confunda cu servere ca hardware sau computere, deoarece vorbim despre partea software) necesită abilități profesionale specifice și cunoștințe ale limbajului de programare care este folosit pe partea de server. Dacă ne uităm la exemple de aplicații client-server, putem vedea că PHP este popular. Este liderul incontestabil în domeniul dezvoltării aplicațiilor server. Mai mult de jumătate dintre site-urile web din lume sunt scrise în această limbă într-o configurație sau alta. PHP este convenabil pentru dezvoltare și suport și, în plus, există cadre speciale pentru a accelera dezvoltarea în PHP.

Cadru

Cadru ( platforma software) - folosit pentru sistematizarea și creșterea nivelurilor de abstractizare, ceea ce face proiectul mai flexibil și mai scalabil. Cu toate acestea, merită să înțelegeți că cadrul trebuie ales corect, pe baza unei analize aprofundate a documentației de lucru a proiectului, fără de care este imposibil să se dezvolte un produs de înaltă calitate.

Delphi, JAVA, Python

Există și alte limbi care sunt folosite pentru a crea Back-end. Astfel, cele create în Mediul Delphi aplicatii server. Cu ajutorul său, programul primește o depanare îmbunătățită; este, de asemenea, ușor să creați programe unice în mediu; este oferită creație vizuală, ceea ce face posibilă crearea unei interfețe frumoase, ușor de înțeles și convenabil. Aplicațiile server în Java au câștigat, de asemenea, popularitate. Acestea sunt ușor de adăugat, ușor de executat pe orice platformă și au un nivel decent de securitate. Python este un alt limbaj popular. Cu ajutorul acestuia, aplicațiile server sunt create rapid, simplu și fără costuri semnificative.

Răspândirea

Crearea de aplicații client-server este solicitată în mediul corporativ. Adesea, astfel de programe sunt folosite pentru grupuri de lucru sau creare sisteme de informareîn cadrul întreprinderii. Marea majoritate a aplicațiilor mobile pentru menținerea comunicării cu clientul au și o arhitectură similară. Popularitatea se datorează faptului că utilizarea capacităților serverului vă permite să asigurați controlul și integritatea sistemului, reducând în același timp încărcarea rețelei.

Vom crea o aplicație client-server pentru Android și iOS de înaltă calitate și la timp

Dezvoltare la cheie

Programatorii Appomart sunt experimentați și calificați pentru a implementa sarcini de o mare varietate de niveluri. Suntem la fel de buni la implementarea rețelelor sociale, a proiectelor de afaceri cu încărcare mare sau a software-ului pentru micile startup-uri. Dacă este necesar, vom crea partea client a aplicației sub Control Android, iOS în conformitate cu nevoile și cerințele existente.

Back-end la Appomart

Programatorii noștri lucrează cu diferite tehnologii și o fac la fel de bine. La Appomart puteți comanda o aplicație client-server în Java, PHP și Node.JS. Cerințele de sistem sunt analizate pentru fiecare proiect în mod individual, ceea ce asigură performanța optimă a programului. Vom crea o aplicație client-server în Java, PHP și Node.JS de la zero sau vom folosi una existentă pentru suport pentru îmbunătățiri și actualizări. Dacă sunteți interesat să dezvoltați o nouă parte de server sau să susțineți una existentă, lăsați o solicitare pentru a primi un calcul detaliat al costului muncii și opțiunile de cooperare.

O parte semnificativă a modernului aplicații pentru platforme mobile(iOS, Android etc.) funcționează în tandem cu serverul. 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 actualizate în mod constant. Acest lucru se aplică aplicațiilor offline care ar trebui să funcționeze fără Internet. Pentru complet aplicații online, care nu funcționează (sau sunt inutile) fără Internet (de exemplu, Foursquare, Facebook) au propriile lor specificuri, care depășesc domeniul de aplicare al articolului actual.

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, mai târziu, 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 discută despre transferul de date î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 („dishes”) pe dispozitiv. Vom presupune că dispozitivul face o solicitare către url-ul „/service/dishes/update”, schimbul are loc prin protocolul http în format JSON ( www.json.org). Serverul are un tabel „dishes” cu câmpurile: id (identificatorul înregistrării), numele (numele antenei), actualizat (în momentul în care antena este actualizată, este mai bine să accepte imediat fusul orar, „AAAA-LL-DDThh: mm:ssTZD”, de exemplu, „1997 -07-16T19:20:30+01:00”), is_deleted (semnul unei înregistrări șterse).

O notă 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, mâncărurile șterse sunt setate la is_deleted = 1. Când o entitate cu is_deleted = 1 ajunge pe dispozitiv, aceasta este ștearsă de pe dispozitiv.

Cu orice abordare, care va fi discutată mai jos, serverul revine la dispozitive matrice JSON obiecte (pot fi goale):

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

Exemplu de răspuns al serverului:

[
(id: 5625, nume: „Pâine”, actualizat: „2013-01-06 06:23:12”, este șters: 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 pentru actualizarea datelor de pe un dispozitiv

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

Abordarea 1: Totul este întotdeauna sincronizat

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

Exemplu de solicitare: nul sau „()”

Avantaje:

Logica de pe server este simplă - întotdeauna dăm totul
Logica de pe dispozitiv este simplă - suprascriem întotdeauna totul

Defecte:

dacă solicitați lista în mod frecvent (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 afectată

Zona de aplicare:

pentru aplicații cu trafic redus
transmiterea de date care se schimbă 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: Doar cea actualizată este sincronizată

Dispozitivul solicită o listă de antene actualizate de la sincronizarea anterioară. Lista este 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 serverului în parametrul „lastUpdated”. Serverul trimite o listă de feluri de mâncare care sunt mai noi decât „lastUpdated” (actualizate > lastUpdated). La prima solicitare către server, „lastUpdated” = nul.

Exemplu de interogare: ( 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 (vase, orașe, organizații etc.)

Această abordare este potrivită pentru sincronizarea listelor liniare simple ale căror reguli pentru a ajunge la un dispozitiv 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”.

De obicei, această abordare acoperă majoritatea nevoilor. Pe dispozitiv vin doar date noi, 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 bucăți

Dispozitivele mobile au puține memorie cu acces aleator. Dacă în director există 3000 de antene, 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, performanța aplicației în timpul sincronizării în fundal va fi scăzută (întârzieri de interfață, nu defilare lină etc.) Prin urmare, este necesar să solicitați lista în porțiuni mai mici.

Pentru a face acest lucru, dispozitivul transmite un alt parametru („cantitate”), care determină dimensiunea porțiunii. Lista este trimisă neapărat 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 transferă în câmpul „lastUpdated”. Dacă serverul a trimis exact același număr de entități, atunci dispozitivul continuă sincronizarea și face din nou cererea, dar cu „lastUpdated” actualizat. Dacă serverul a trimis mai puține entități, aceasta înseamnă că nu mai are date noi și 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 poate procesa 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 o cantitate mare câmpuri și logica de procesare de salvare complexă, nu mai mult de 5 bucăți sunt sincronizate în mod normal.

Defecte:

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

Abordarea 4: Sincronizarea corectă în bucăți

În abordarea anterioară, este posibil ca dacă în tabel există 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 vor veni primele 100 de înregistrări. Restul de 150 vor fi tăiați de o condiție grea (actualizat > ultima actualizare). De ce se va întâmpla asta? La interogarea primelor 100 de înregistrări, LastUpdated va fi setat la „2013-01-10 12:34:56”, iar următoarea interogare va avea condiția (actualizat > „2013-01-10 12:34:56”). Nici măcar atenuarea condiției (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, când se importă date din fisier text câmpul „actualizat” a fost setat la ACUM(). Importarea unui fișier cu mii de linii poate dura mai puțin de o secundă. De asemenea, se poate întâmpla ca întregul director să aibă același „actualizat”.

Pentru a remedia acest lucru, trebuie să utilizați un fel de 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ă o listă sortată după „actualizat” și „id”, iar dispozitivele solicită date folosind „lastUpdated” și noul parametru „lastId”. Pe server, condiția de eșantionare 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 de fapt cât de bine au fost salvate datele pe dispozitiv. Este posibil ca dispozitivul să nu fi salvat o parte din date din cauza unor erori inexplicabile. Prin urmare, ar fi bine să primiți confirmarea de la dispozitiv că toate (sau nu toate) felurile de mâncare au fost salvate.

În plus, utilizatorul aplicației poate personaliza aplicația astfel î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. Sincronizarea descrisă mai sus nu poate realiza acest lucru.

Ideea abordării este următoarea. Serverul stochează informații despre felurile de mâncare pe dispozitiv (într-un tabel separat „listă_de_articole_stocate”). Aceasta ar putea fi pur și simplu o listă de perechi „id – actualizate”. Acest tabel stochează toate listele de perechi de antene „id – actualizate” pentru toate dispozitivele.

Dispozitivul trimite informații despre felurile disponibile pe dispozitiv (o listă de perechi „id – actualizat”) către server împreună cu o solicitare de sincronizare. Când faceți o solicitare, serverul verifică ce antene ar trebui să fie pe dispozitiv și care sunt disponibile în prezent. 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” a tuturor felurilor 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? Acesta interogează 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, nu există „lastUpdated” și „lastId” în cerere; 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 „items”, care conține o listă de id-uri care au fost trimise dispozitivului în ultima sincronizare („device_last_stored_item_list”). Bineînțeles, puteți trimite o listă cu ID-urile tuturor antenei care se află pe dispozitiv fără a complica 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ă-și actualizeze constant „lista_de_articole” cu datele care au venit de la dispozitiv în parametrul „articole”.

Ar trebui implementat 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ă datele de pe dispozitiv sunt încă actuale. Prin urmare, atunci când instalează o aplicație, dispozitivul trebuie să informeze cumva serverul, astfel încât să ștergă lista_de_articole stocate pentru acest dispozitiv. În aplicația noastră trimitem parametru suplimentar„clearCache” = 1 în acest caz.

Concluzie

Tabel rezumat al caracteristicilor acestor abordări:

№	O abordare	Volumul traficului(5 – mare)	Complexitatea dezvoltării(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 conținutul actualizat este sincronizat	1	2	5	3	Nu
3	Sincronizare în bucăți	1	3	1	3	Nu
4	Sincronizare corectă în bucăți	1	3	1	3	Nu
5	Sincronizați cu cunoștințele despre ceea ce este deja pe dispozitiv	2	5	2	5	da

„Corectitudinea datelor dispozitivului” este probabilitatea ca dispozitivul să aibă toate datele trimise de server. În cazul abordărilor nr. 1 și nr. 5, există încredere 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ă unele dintre datele de pe dispozitiv se pierd, atunci nu va fi posibil să le remediați de pe server (darămite să aflați despre asta pe partea de server).

Poate, dacă aveți tarife nelimitate la internet și gratuit problema wifi limitarea traficului generat de o aplicație mobilă va deveni mai puțin relevantă. Dar deocamdată trebuie să apelăm la tot felul de trucuri, pentru a veni cu abordări mai „inteligente” care pot reduce costurile rețelei și pot crește performanța aplicațiilor. Acest lucru nu funcționează întotdeauna. Uneori, „cu cât mai simplu, cu atât mai bine”, depinde de situație. Sper că puteți găsi o abordare care să vă fie utilă din acest articol.

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

Compania noastră oferă servicii pentru crearea părții server a aplicațiilor mobile de afaceri și a serviciilor web client care operează în medii cu încărcare mare. Când dezvoltăm fiecare proiect, încercăm să aplicăm abordare individuală astfel încât produsul rezultat să devină cel mai mult soluție optimă obiectivele specifice ale clientului.

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

Adesea, partea de server a unei aplicații este scrisă limbaj PHP, ca fiind cea mai populară pentru astfel de soluții. Poate fi folosit pentru a implementa sarcini simple de server sisteme standard, dar pentru cele mai specifice, este deja necesar să vă dezvoltați propria soluție sau suplimente peste sisteme standard.

Principii de dezvoltare a unui server 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, chiar și sarcini foarte mari și diverse zone. 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 a proiectului la timp.

Programare

Proiectarea arhitecturii serverului este cel mai important pas, în timpul căruia se creează baze de date și se formează algoritmii necesari.

Testare

Partea software ar trebui să funcționeze fără erori sau erori. De asta sunt responsabili testerii care verifică sistemul.

Suport tehnic

Angajații noștri oferă suport tehnic complet pentru programe, ceea ce vă permite să eliminați rapid deficiențele și să faceți actualizări.

Caracteristici de dezvoltare

Pentru a dezvolta în mod competent partea de server a unei aplicații, 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 dintre site-urile web din lume sunt scrise în PHP; este convenabil pentru dezvoltare și suport.

Cadru

Această platformă software vă permite să faceți proiectul mai scalabil și mai flexibil. Cu toate acestea, cadrul trebuie ales cât mai corect posibil, astfel încât 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. Din acest motiv, programul a îmbunătățit depanarea. În plus, este mai ușor să dezvoltați programe unice și oferă creație vizuală. Toate acestea ne permit să creăm o interfață clară și convenabilă.

Aplicațiile server în Java nu sunt mai puțin populare. Ele pot fi completate cu ușurință, pot fi executate cu ușurință pe diferite platforme și au nivel inalt Securitate.

Un alt limbaj folosit frecvent. Cu ajutorul acestuia, aplicațiile server sunt create ușor, rapid și fără costuri suplimentare.

Aproape totul companiile moderne au propriile birouri virtuale. Site-ul poate fi fie carte de vizită, sau un portal sau catalog online cu posibilitatea de a plasa comenzi.

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

Etapele dezvoltării serviciului web

Prin crearea de aplicații pentru diferite segmente de piață, ne organizăm munca în funcție de un singur principiu– împărțim întregul proces în etape separate, ale căror progrese și rezultate sunt comunicate clienților. Astfel, serverul pentru aplicația mobilă este dezvoltat într-un mod similar.

1. Dezvoltarea ideii

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

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

2. Evaluarea proiectului

2-3 saptamani

Specialistii nostri evalueaza timpul si costul lucrarii, apoi intocmesc o propunere preliminara privind dezvoltarea.

3. Termeni de referință și contract

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

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

4. Dezvoltarea interfeței

2-3 saptamani

Designerii sunt responsabili pentru crearea interfețelor necesare la 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, serviciul web finalizat, testat temeinic este livrat clientului.

echipa noastră

Analizând activitățile de afaceri și nevoile clienților noștri, creăm produse cu adevărat funcționale care ajută la rezolvarea unei game de probleme de afaceri. Utilizare tehnologii moderne oferă o gamă largă de opțiuni pentru implementarea 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. Ei monitorizează implementarea atât a acțiunilor deja planificate, cât și a îmbunătățirilor necesare.

Designeri

În munca lor, specialiștii noștri iau în considerare cerințele pentru construirea de interfețe pentru sălile de operație sisteme 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 le analizează Cerințe de sistemși creați software de server specializat.

Testori

Testarea amănunțită este cheia calității produsului finit și garantează securitatea datelor stocate și procesate. Acești specialiști folosesc diferite instrumente și tehnici eficiente.

Ce servicii creăm?

Fiind integrat în software-ul site-ului web sau program independent, un serviciu web folosit pentru a îndeplini sarcini legate de publicitate, analiză, planificare de afaceri și promovare. În acest sens, este necesar să se decidă ce tip 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 aceluiași subiect. Cererea pentru ele este încă destul de mare.

Site-uri de știri

Ei 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, ele transmit cutare sau cutare informații comunității de pe internet, dar în acest caz autorii își exprimă opiniile personale.

Proiecte sociale

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

Forumuri

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

Rețelele de socializare

Aceste resurse au o audiență de mai multe milioane. Sarcina lor principală este de a oferi utilizatorilor de internet posibilitatea de a comunica online prin text/ mesaje vocaleși comunicații 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-mail, inclusiv vizualizarea, trimiterea, editarea scrisorilor și documentelor etc.

Motoare de căutare

Folosit pentru a căuta site-uri și diverse informatii pentru anumite cereri.

Panouri de informare

Acestea sunt resurse web în care utilizatorii rețelei își postează reclamele pentru achiziții, vânzări și servicii în cadrul diferitelor 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 specialiștilor noștri. Dacă nu găsiți aici informațiile care vă interesează, vă rugăm să vă adresați întrebarea aici. formă, și cu siguranță îi vom răspunde.

Cât timp poate dura crearea unei aplicații și a unui server web?

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

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 de 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, este necesar să se ia în considerare organizarea stocării în cache a datelor serverului.

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

API (interfață de programare a aplicației) – interfață de programare a aplicației. Pentru a spune î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, un API este o parte necesară a infrastructurii client-server.

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

Multithreading

Unul dintre aspectele cheie în programarea modernă este multithreading-ul. Cu ajutorul multithreading-ului, putem aloca mai multe fire în aplicația care va funcționa diverse sarcini simultan.

Multithreadingul este o proprietate a platformei (de exemplu, sistem de operare, mașină virtuală etc.) sau aplicație, constând în faptul că un proces generat în sistemul de operare poate consta din mai multe fire care rulează „în paralel”, adică fără o ordine în timp prescrisă.

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 ale unui proces nu numai că au 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, deși sistemele de operare care implementează multitasking de obicei implementează ș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 unui fir în raport cu procesul.

Creșterea performanței procesului prin paralelizarea calculelor procesorului și a operațiilor 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 executate asincron într-un singur program. De exemplu, editarea textului în editor de textîn timpul tipăririi, deoarece aceste două sarcini sunt efectuate în fire diferite.

Pe un procesor tipic, controlul firelor este gestionat de sistemul de operare. Firul se execută până când apare o întrerupere hardware, are loc un apel de sistem sau până când expiră timpul alocat pentru acesta de sistemul de operare. După aceasta, procesorul trece la codul sistemului de operare care păstrează starea firului de execuție (contextul său) sau trece la starea altui fir de execuție, căruia îi este, de asemenea, alocat timp de 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, poate executa mai multe fire simultan pe ciclu de ceas.

– Multithreading temporar (un singur fir)

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

Multithreading, un model de programare și execuție de cod utilizat pe scară largă, permite mai multe fire de execuție să ruleze într-un singur proces. Aceste fire de execuție partajează 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, permițându-i să ruleze în paralel pe un sistem multiprocesor.

Acest avantaj al unui program cu mai multe fire îi permite să ruleze mai rapid sisteme informatice, care au mai multe procesoare, un procesor cu mai multe nuclee sau pe un cluster de mașini - datorită faptului că firele de execuție de program 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 printr-o procedură de întâlnire pentru a procesa datele în ordinea corectă. Firele de execuție pot necesita, de asemenea, mutexuri (deseori implementate folosind semafore) pentru a preveni modificarea sau citirea datelor partajate în același timp în timpul procesului de modificare. Utilizarea neglijentă a unor astfel de primitive poate duce la un impas.

O altă utilizare a multithreading-ului, chiar și pentru sistemele cu un singur procesor, este capacitatea unei aplicații de a răspunde la intrare. În programele cu un singur thread, dacă firul principal de execuție este blocat de o sarcină de lungă durată, întreaga aplicație poate ajunge într-o stare înghețată. Prin mutarea unor astfel de sarcini de lungă durată î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 obținut prin I/O asincrone sau semnale în UNIX.

Există două tipuri de multitasking: bazat pe procesȘi bazate pe fire. Diferențele dintre multitasking-ul bazat pe proces și cel bazat pe fire se reduc la următoarele: multitasking-ul bazat pe proces este organizat pentru execuția paralelă a programelor, iar multitasking-ul bazat pe fire este organizat pentru execuția paralelă a părților individuale ale aceluiași program.

Există două tipuri de fluxuri:

Fire în prim plan sau prioritate. În mod implicit, fiecare fir creat prin metoda Thread.Start() devine automat un fir în prim-plan. Acest tip firele de execuție asigură că aplicația curentă nu se termină. Common Language Runtime nu va opri aplicația până când toate firele prioritare nu se vor finaliza.

Fire de fundal. Acest tip firele de execuție, cunoscute și sub denumirea de fire daemon, sunt tratate de CLR ca căi de execuție extensibile care pot fi ignorate în orice moment. Astfel, dacă toate firele de execuție din prim-plan sunt terminate, atunci toate firele de execuție din fundal sunt eliminate automat când domeniul aplicației este descărcat. Pentru a crea fire de fundal, trebuie să setați proprietatea IsBackground la true.

Vorbiți despre stările firelor: rulare, suspendare, alergare, dar așteptați ceva.

Problemă de sincronizare a firelor și resurse partajate.

Interacțiunea firelor

Într-un mediu cu mai multe fire, problemele apar adesea atunci când firele concurente partajează aceleași date sau dispozitive. Pentru a rezolva astfel de probleme, se folosesc metode de interacțiune cu fire precum mutexuri, semafoare, 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 de niciun fir. Un singur fir deține acest obiect în orice moment, de unde și numele unor astfel de obiecte (din engleză mutually exclusive access - mutually exclusive access) - accesul simultan la o resursă partajată este exclus. După ce toate acțiunile necesare sunt finalizate, mutex-ul este eliberat, permițând altor fire să acceseze resursa partajată. Un obiect poate menține o achiziție recursivă a doua oară de către același fir, incrementând contorul fără a bloca firul și necesitând eliberarea ulterioară de mai multe ori. Aceasta este, de exemplu, secțiunea critică din Win32. Cu toate acestea, există și implementări care nu acceptă acest lucru și au ca rezultat un blocaj al firului de execuție atunci când se încearcă o captură recursivă. Acesta este FAST_MUTEX în nucleul Windows.

Semafoare reprezintă resurse disponibile care pot fi achiziționate de mai multe fire de execuție î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.

Evenimente. Un obiect care stochează 1 bit de informații „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 face ca firul de execuție să suspende execuția până când un alt fir (sau a doua fază a handler-ului de întrerupere 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ă la 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 accesibile în cadrul aceluiași proces. Evenimentele, mutexurile și semaforele pot fi, de asemenea, utilizate într-o aplicație cu un singur proces, dar implementările secțiunilor critice din unele sisteme de operare (cum ar fi Windows NT) oferă un mecanism de sincronizare mai rapid și mai eficient, care se exclud reciproc - „obține” și „eliberare” operațiunile pe secțiunea critică sunt optimizate pentru cazul unui singur thread (fără concurență) 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, făcându-le extrem de utile pentru delimitarea accesului la resursele partajate.

Variabile condiționale(convarii). Ele sunt asemănătoare evenimentelor, dar nu sunt obiecte care ocupă memorie - este folosită doar adresa unei variabile, conceptul de „conținut variabil” nu există, adresa unui obiect arbitrar poate fi folosită ca variabilă de condiție. Spre deosebire de evenimente, setarea unei variabile de condiție la o stare semnalată nu are consecințe dacă nu există fire de execuție în așteptare pentru variabilă. Setarea unui eveniment într-un caz similar implică stocarea unei stări „semnalizate” în cadrul evenimentului în sine, după care firele ulterioare care doresc să aștepte evenimentul continuă să se execute imediat fără oprire. Pentru a utiliza pe deplin un astfel de obiect, este necesară și operația „eliberați mutexul și așteptați variabila de condiție atomic”. Folosit activ în sisteme de operare asemănătoare UNIX. Discuțiile despre avantajele și dezavantajele evenimentelor și ale variabilelor de condiție sunt o parte importantă a discuțiilor despre avantajele și dezavantajele Windows și UNIX.

Port de finalizare I/O(Port de completare IO, IOCP). Implementat în nucleul OS și accesibil prin apeluri de sistem, obiectul „coadă” cu operațiunile „pune o structură la coada cozii” și „ia următoarea structură din capul cozii” - ultimul apel suspendă execuția a firului dacă coada este goală și până când un alt thread nu va efectua apelul „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 finalizării unei operațiuni I/O asincrone pe unul dintre descriptorii de fișier. Pentru a obține acest efect, trebuie să utilizați apelul de sistem „asociați descriptor de fișier cu IOCP”. În acest caz, structura plasată în coadă conține codul de eroare al operației de I/O și, de asemenea, dacă această operație are succes, numărul de octeți efectiv introduși sau ieșiți. Implementarea portului de completare limitează, de asemenea, numărul de fire care se execută pe un singur procesor/nucleu după primirea unei structuri din coadă. Obiectul este specific MS Windows și permite procesarea cererilor de conectare primite și a porțiunilor de date în server softwareî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-ne despre grupul de fire