Parte server a aplicației mobile. Dezvoltarea laturii server a aplicațiilor mobile

Dezvoltarea laturii server a aplicației

Introducere

O prezență pe internet a devenit o necesitate pentru afacerile de astăzi. Fără aceasta, este imposibil să construim o interacțiune deplină cu clienții. Adesea, pentru a rezolva o astfel de problemă, recurg 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 server a aplicației. Dacă în viitor trebuie să schimbați independent conținutul programului mobil, atunci back-end-ul ar trebui creat cu o calitate deosebit de înaltă. Appomart garantează îndeplinirea sarcinilor atribuite în conformitate cu cerințele. Prin urmare, atunci când comandați crearea de aplicații server, puteți fi siguri de rezultatul corect.

Pentru ce este back-end-ul?

Dezvoltarea aplicațiilor client-server implică două părți. Primul, Front-end, acceptă cererile utilizatorilor. Ea este vizibilă de pe ecrane dispozitive mobile clienți. A doua, aplicația server, procesează solicitările primite și acționează ca un panou administrativ. Bazele de date, 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 informația responsabilă de procesarea cererilor clienților, viteza aplicației. Prin urmare, este important ca arhitectura aplicației server să fie gândită până la cele mai mici detalii, astfel încât chiar și serviciile foarte încărcate să ruleze fără probleme și rapid.

Cum se alege un limbaj de programare?

In pregatire termeni de referinta(parte a documentației de lucru pentru proiect), arhitectul proiectează un sistem de baze de date și leagă, descrie obiecte și proprietățile acestora și dezvoltă, de asemenea, metodele de server necesare (solicitări pe care aplicațiile mobile le vor „utiliza” la accesarea serverului).

Importanța documentării și a proiectelor abandonate

Appomart este adesea abordat de clienții care au fost abandonați de alți contractori dintr-un motiv sau altul. Și luăm proiectul altcuiva, uneori chiar incorect de lucru, efectuăm auditul și revizuirea ulterioară și sprijinul. În procesul de studiu a codului sursă și a materialelor primite de la client, ne confruntăm cu faptul că mulți dezvoltatori nu documentează în mod deliberat metodele serverului pentru a-l lega pe client de ei înșiși, din cauza costurilor incomensurabile ale forței de muncă ale transferului proiectului pentru a sprijini un alt dezvoltator, din cauza lipsei de documentație pentru partea serverului și uneori doar 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 un proiect existent, precum și pentru un audit al codului sursă, înainte de a fi posibil să se judece operabilitatea, comoditatea și oportunitatea sprijinului proiectului. Personalul Appomart păstrează întotdeauna documentația electronică a metodelor back-end într-un format acceptat de Postman și Swagger pentru utilizare ulterioară.

Cum să verificați contractorul înainte de a semna contractul?

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 de documente pe care le veți primi împreună cu proiectul, precum și condițiile pentru transferul codului sursă și acoperirea codului cu comentarii, scheme de baze de date (fie Mongo DB sau MySQL). Cheia succesului devine, de regulă, o documentație de lucru competentă, care indică în mod clar cerințele pentru materialele transferate la finalizarea fiecărei etape de lucru.

Caracteristici de dezvoltare

PHP pentru partea serverului

Crearea laturii de server a aplicațiilor (nu trebuie confundată cu serverele ca „hardware” sau computere, deoarece vorbim despre partea software) necesită abilități profesionale specifice și cunoștințe despre limbajul de programare care este utilizat pe partea serverului. Dacă ne uităm la exemple de aplicații client-server, putem vedea că PHP este popular. Este liderul incontestabil în dezvoltarea de aplicații server. Mai mult de jumătate din site-urile lumii sunt scrise în această limbă într-o configurație sau alta. PHP este ușor de dezvoltat și întreținut și există cadre speciale pentru a accelera dezvoltarea PHP.

Cadru

Framework (platformă software) - utilizat pentru a organiza și crește nivelurile de abstractizare, ceea ce face proiectul mai flexibil și scalabil. Cu toate acestea, trebuie înțeles 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 calitate.

Delphi, JAVA, Python

Există și alte limbi care sunt folosite pentru a crea back-end-ul. Deci, aplicațiile de server create în mediul Delphi sunt răspândite. 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 asigurată crearea vizuală, ceea ce face posibilă crearea unei interfețe frumoase, ușor de înțeles și convenabile. Aplicațiile server Java au câștigat, de asemenea, popularitate. Acestea sunt ușor completate, ușor de executat pe orice platformă și au un nivel decent de securitate. Un alt limbaj popular este Python. Aplicațiile server cu ajutorul său sunt create rapid, simplu, fără costuri serioase.

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 pentru a crea sisteme de informareîn cadrul întreprinderii. Marea majoritate aplicatii mobile are, de asemenea, o arhitectură similară pentru a menține comunicarea cu clientul. Popularitatea se datorează faptului că utilizarea capabilităților serverului vă permite să asigurați controlul și integritatea sistemului, reducând în același timp sarcina în rețea.

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

Dezvoltare la cheie

Programatorii Appomart sunt experimentați și calificați să se ocupe de sarcini de o gamă largă de niveluri. Suntem la fel de buni la implementarea rețelelor sociale, a proiectelor de afaceri cu sarcină mare sau a părții software pentru startup-uri mici. Dacă este necesar, vom crea partea clientului a aplicației Android, iOS în conformitate cu nevoile și cerințele existente.

Back-end în Appomart

Programatorii noștri lucrează cu o varietate de tehnologii și o fac la fel de bine. În Appomart puteți comanda o aplicație client-server în Java, PHP și Node.JS. Cerințele de sistem sunt analizate individual pentru fiecare proiect pentru a asigura performanța optimă a programului. Să creăm o aplicație client-server Java, PHP și Node.JS de la zero sau să luăm una existentă în sprijin pentru îmbunătățiri și actualizări. Dacă sunteți interesat să dezvoltați o nouă parte de server sau să o susțineți pe una existentă - lăsați o cerere pentru a primi un calcul detaliat al costului lucrării și opțiunilor de cooperare.

Offline în trecut, a fi online astăzi este o necesitate. Cel puțin pentru lumea afacerilor moderne. 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 al aplicației dvs.). Și dacă doriți să puteți edita conținutul aplicației dvs. fără implicarea dezvoltatorilor, aveți nevoie de un bun panou de administrare.

În timp ce front-end-ul în aplicațiile mobile este construit folosind tehnologii precum X-Code și Java, Back-end-ul, unde baza de date și toată logica aplicației vor fi stocate, necesită cunoștințe profesionale despre un limbaj de programare pe partea de server. Un bun exemplu este PHP, care este, fără îndoială, cel mai popular limbaj de programare utilizat pentru aproape orice dezvoltare pe partea serverului. 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 și panouri de control gratuite sau ieftine. Cu toate acestea, în multe cazuri, acestea nu oferă nivelul necesar de confort, personalizare și îmbunătățire.

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țe de sistem pentru fiecare proiect în mod individual și folosim diverse software-uri de server specializate pentru performanțe optime ale aplicației dvs. mobile.

Dacă sunteți în căutarea unei echipe care să vă poată 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 dumneavoastră.

BACKUP

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

Experții știu cât de uneori sunt aplicațiile mobile fiabile de pe 1C: pot apărea erori î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 fiabilitate 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 am avut un mecanism de platformă pentru salvarea unei copii de rezervă.

Întrucât utilizatorii nu aveau anterior butonul „Salvați o copie”, dezvoltatorii aplicației Boss trebuiau să 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 la e-mail, salvați pe dispozitiv.

Astfel, dezvoltatorii se asigură în plus. Dacă ceva nu a funcționat corect și mecanismul de creare a copiilor pe Google Drive sau Yandex Drive s-a defectat brusc, puteți spune utilizatorului că în acest moment dezvoltatorul se ocupă de eroare, dar pentru moment poate salva datele mod alternativ... Iar utilizatorii sunt mulțumiți, deoarece pot fi siguri de datele lor.

Necesar 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 vor fi pierdute.

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

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

Când vorbim despre o soluție de masă, despre o aplicație care se schimbă constant, evoluează și se rafinează, trebuie luat în considerare comportamentul clienților. Utilizatorul poate dori să restabilească o copie de rezervă salvată în versiune veche o aplicație care nu avea cerințe. Și apoi apare sarcina: să citiți datele, apoi completați datele conform logicii de actualizare din vechea versiune 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 însăși. Adică, odată cu lansarea fiecărei noi versiuni, păstrați structura metadatelor versiunea anterioara la layout în config.

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

Prin urmare, în cazul unei aplicații mobile, este de preferat un alt mod - salvați structura metadatelor direct în fișierul de date... La ieșire, obținem un astfel de fișier, unde la început stocăm unele date auxiliare - versiunea de configurare, schema de configurare, limitele secvenței și, ulterior, scriem datele utilizatorului în format XML. Mai mult, în secțiunea „Date auxiliare” a fișierului, puteți stoca și alte date importante care, dintr-un anumit motiv, nu au putut fi scrise în XML.

Luăm schema de date pe care am salvat-o în fișier și, pe baza sa, 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 s-a stabilit pe această opțiune de înregistrare a schemei de metadate. Când deschideți fișierul de date în sine, puteți vedea XML structurat obișnuit, lizibil, 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, XDTO Model); // Citirea schemei de configurare Model XDTO = Factory XDTO. Read 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 întrebi din nou dacă are nevoie să restabilească copia de rezervă. Poate doar experimenta și făcea clic pe toate butoanele din aplicație :) Și acum datele sale actuale s-ar putea pierde. Prin urmare, atunci când efectuăm acțiuni potențial „periculoase”, specificăm întotdeauna dacă el dorește cu adevărat acest lucru și cum ar trebui să fie făcut. Utilizatorul trebuie să fie conștient de acțiunile sale.

Trebuie să existe un mecanism pentru crearea copiilor de rezervă atunci când vorbim despre o soluție autonomă, când utilizatorul are toate datele stocate exclusiv pe un dispozitiv mobil: utilizatorul își poate pierde dispozitivul, iar apoi datele se vor pierde. Și, s-ar părea, dacă aplicația nu funcționează autonom, dar 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, își va primi toate datele din server din nou și totul va fi ok.

Cu toate acestea, utilizatorii nu folosesc întotdeauna copiile de rezervă așa cum ne așteptăm să le facem :) Ei le folosesc foarte des pentru a „întoarce” datele înapoi. Acesta este într-adevăr un comportament foarte ciudat, dar utilizatorii aplicațiilor mobile sunt prea leneși pentru a-și da seama unde ar putea face o greșeală atunci când introduc date și pur și simplu derulează datele înapoi și reintroduc datele pentru ziua curentă. După analizarea statisticilor 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ă o gestionați. Există mai multe soluții aici:

• întrerupeți conexiunea cu serverul, specificând că datele de pe acesta vor rămâne aceleași, iar copia va fi restaurată numai pe dispozitivul utilizatorului;
• este mai bine pentru utilizator să-l lase să restabilească o copie simultan pe toate dispozitivele, după ce a prescris anterior astfel de mecanisme.

Mai este un lucru aici. Până acum, am salvat singuri copiile de rezervă, am controlat întregul proces și am surprins acțiunile utilizatorului chiar în cod atunci când a apăsat 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. Iar utilizatorul face acest lucru fără știrea noastră. Dacă se utilizează sincronizarea cu o bază de date centrală, atunci trebuie gestionat un astfel de scenariu. Trebuie cumva să aflăm pe serverul nostru că utilizatorul a restaurat o copie salvată anterior și trebuie să îi ofere un fel de soluție. Nu ne putem permite să avem date neconectate.

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ă utilizeze o platformă mobilă pentru agenții lor de vânzări și astfel încât 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, configurați comunicarea cu acesta. Deci, problema schimbului între dispozitive este ușor de rezolvat.

Dar dacă vorbim despre o aplicație de masă în care există multe baze de date, fiecare dintre acestea având un număr foarte mare de utilizatori, situația devine mai complicată. Utilizatorii au descărcat aplicația de pe piață și vor să se sincronizeze între ei. De exemplu, un soț a descărcat o aplicație de contabilitate a finanțelor personale, iar acum vrea ca și soția sa să se conecteze și lucrează împreună în aceeași aplicație. Există 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 permite sincronizarea. Vor să apese un buton și să-l facă să funcționeze imediat. În același 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 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, programat, fără participarea noastră. În realitate, utilizatorii fac pur și simplu clic pe butonul „Înregistrează-te pe server” și totul se întâmplă de la sine: o bază de date personală este creată pentru el pe server și el poate începe imediat să lucreze în el.

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

Dar apoi ne-am dat seama că reinventăm roata :) De fapt, există o soluție gata făcută și a luat deja în considerare punctele la care nici nu ne gândisem. Acesta este 1C: Fresh.

Scalabilitatea serviciului este gândită aici: ce să facem atunci când vor exista o mulțime de date și baze de date, cum să creștem cu toate acestea. Aici este un moment despre creație backup-uri zone de date: adică nu facem doar o copie de rezervă a unei baze de date comune, ci facem copii ale unui anumit utilizator. Mai mult, mecanismul existent este astfel încât copiile sunt făcute numai atunci când sunt într-adevăr necesare. Dacă un utilizator nu a intrat în baza de date de o săptămână, atunci nu facem copii ale acestuia, deoarece nimic nu s-a schimbat acolo. O altă caracteristică a Fresh este că serviciul implementează un mecanism de reducere a încărcării pe server, ceea ce este foarte important atunci când aveți o mulțime de 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 doar mulțumiți de munca sa.

Transfer de date. Cum să-l implementați pentru schimbul între dispozitive

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

În ceea ce privește serviciile, aplicația Boss implementează schimbul instant: un utilizator introduce date, iar celălalt le primește. Utilizatorii de aplicații mobile sunt obișnuiți cu faptul că totul se întâmplă instantaneu, așa că ne-am gândit la ce serviciu este mai bine să utilizăm - SOAP sau http. Viteza conexiunii a jucat un rol cheie. În http, viteza conexiunii este mult mai mare și, atunci când ne conectăm prin SOAP, primim o descriere a serviciului, care este greu și este nevoie de mult timp pentru încărcare. Platforma are o modalitate de a stoca o descriere a serviciului, dar datorită parametrilor pe care îi adăugăm dinamic, nu putem folosi referințe WS. În plus, accesul la serviciile http este mai convenabil și mai flexibil în experiența noastră.

Deci, obiectivul nostru este să implementăm schimbul în timp real. Adică încercăm să nu facem utilizatorul să meargă undeva, să facă clic pe un buton, să ne gândim cât de relevante sunt datele sale, 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 se aplică și aplicațiilor 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ă fiecare scriere a datelor în baza de date, aceasta rulează job de fundal care inițiază schimbul. Prima parte este de a trimite date 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 repede.

Dar am vrut-o și mai repede, pentru că lucrăm în timp real și de obicei avem puține date. Avem un 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 un 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 mult timp, dar datele în sine erau foarte mici.

Ne-am gândit la modul în care acest proces poate fi accelerat.

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 privind 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ă pentru iOS suma caracterelor valide este de 981 de caractere, iar pentru Android este de 3832 de caractere. În acest din urmă caz, este foarte posibil să se utilizeze 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 există prea 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 acesta. Schema a devenit mai scurtă, iar schimbul a devenit și mai rapid :)

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

Este foarte ușor să scăpați de această situație: pur și simplu nu trimiteți o mulțime de mesaje PUSH utilizatorului :) Dacă lucrează acum î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 o mulțime de mesaje necitite. Prin urmare, în nici un caz următorul PUSH nu trebuie trimis până când nu este primit un răspuns de la dispozitiv că aplicația rulează, 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 - primiți răspunsul - și totul este în regulă. Dacă lucrați pe web, vă veți confrunta în continuare cu anumite limitări, de exemplu, internetul instabil, declanșarea timeout-urilor atunci când efectuați operațiuni lungi. Prin urmare, este necesar să ne gândim la arhitectură în avans.

Să vedem 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. Păstrează înregistrări pentru o vreme, a introdus o mulțime de date, dar apoi vrea ca vânzătorul să lucreze și 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 utilizatorii. Dar apoi am ajuns într-o situație în care, pentru unii utilizatori, bazele de date de pe dispozitiv până la înregistrare crescuseră deja foarte mult. Și această schemă nu mai funcționa, de atunci în timp ce întreaga bază de date a fost înregistrată pe server, timpul de expirare a conexiunii a fost declanșat sau internetul a fost pur și simplu întrerupt. Prin urmare, am înlocuit un apel sincron cu multe apeluri scurte. Acum, datele sunt distribuite mai degrabă decât transmise simultan. Nu așteptăm în niciun fel ca serverul să proceseze și să înregistreze date. Am trimis date, am primit un răspuns că datele au fost primite, am închis conexiunea. Periodic, trebuie să chestionați serverul, ce se întâmplă acolo și cum și, între timp, se execută o lucrare de fundal pe server, care înregistrează datele primite. În acest fel primim o mulțime de apeluri de server, dar avem garanția că totul va merge bine. Și nici expirările, nici instabilitatea Internetului nu vă vor împiedica să încărcați toate datele pe server.

ACTUALIZĂRI

Schimbați între dispozitive cu diferite versiuni ale aplicației

Deoarece vorbim despre o aplicație de masă care este lansată pe piețe, trebuie să luăm în considerare unele dintre caracteristicile procesului de actualizare și schimb de date.

Dacă ați lansat o aplicație pentru o singură întreprindere și ați decis să o actualizați, atunci de obicei dați doar o comandă pentru toți angajații să instaleze împreună 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ă într-o aplicație și nu vor să o actualizeze nici acum, niciodată. Nu au actualizare automată, deci este o situație destul de obișnuită când mai multe dispozitive sunt conectate la baza centrală și toate au versiuni diferite. Un alt motiv pentru acest fenomen este timpul publicării pe piețe: este diferit pentru iOS și Android. De multe ori implementăm lucruri cheie, de exemplu, remediem erorile critice și nu vrem să așteptăm ca iOS să verifice două săptămâni versiune noua, vrem cel puțin numai Android, dar vrem să lansăm actualizarea chiar acum.

Nu avem dreptul de a comanda utilizatorilor. Dacă vor, sunt actualizați și, 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 aplicației 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 - este mai bine, bine și bine.
• Trebuie să asigurăm siguranța datelor. De exemplu, un utilizator are un director și un element nou de recuzită, în timp ce altul nu are încă. În același timp, dacă un utilizator care nu are detalii noi schimbă ceva pe dispozitivul său, atunci datele nu trebuie pierdute pe alte dispozitive.
• Trebuie să ne asigurăm că datele sunt actualizate atunci când facem upgrade la o nouă versiune. Când utilizatorul decide că este gata să se actualizeze, ar trebui să aibă automat toate noile informații pe care nu le avea 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 acest lucru. Și 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 este utilizat pentru copiile de rezervă, adică salvăm versiunea metadatelor. În acest caz, lucrăm cu serverul și ne putem permite să adăugăm orice ne dorim direct la configurație, așa că pur și simplu adăugăm scheme de metadate la configurație sub formă de machete pe măsură ce aplicația se dezvoltă.

Cum să monitorizați 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ă serverelor - 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ă. Verifică performanța serverului în fiecare minut și, 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 - doar colectăm un jurnal de erori la fiecare trei ore, le trimitem prin poștă, le examinăm periodic. Acest lucru vă ajută să vedeți probleme comune și un fel de situații excepționale. Nu este greu să vă citiți e-mailul, să urmăriț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ă dați utilizatorului posibilitatea de a „plânge”. Ne îmbunătățește statutul în ochii lor și ne salvează. Există 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ă nu funcționează nimic, baza de date nu se încarcă, totul este teribil de rău. Dar uneori ne salvează cu adevărat, pentru că uneori găsesc astfel de bug-uri pe care alții nu le-au găsit în mod miraculos, bug-uri grave.

Utilizatorul nu poate fi speriat. Nu mesaje înfricoșătoare, nimic altceva. Ei trebuie să explice totul frumos și să se ofere să se plângă. Și promitem să rezolvăm 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 toată lumea să participe la 7 întâlniri regionale, precum și la aniversarea INFOSTART EVENT 2020 la Moscova.

O mare parte din modernitate 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ă se asigure reînnoire constantă date de la server la dispozitiv. Acest lucru se aplică aplicațiilor offline care ar trebui să funcționeze fără Internet. Pentru aplicațiile complet online care nu funcționează (sau sunt inutile) fără Internet (de exemplu, Foursquare, Facebook) există 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, în viitor, cu experiență, i-am îmbunătățit. O secvență similară este prezentată în articol - de la practici evidente simple la practici mai complexe.

Ar trebui clarificat faptul că articolul se ocupă cu transferul de date doar într-o singură direcție: de la server la dispozitiv. Aici serverul este sursa de date.

Dispoziții generale pentru toate abordările

De exemplu, vom lua în considerare transferul unui director de vase pe dispozitiv („vase”). Vom presupune că dispozitivul face o cerere pentru adresa URL „/ service / dish / update”, schimbul se efectuează prin protocolul http în format JSON ( www.json.org). Serverul are un tabel „vase” cu următoarele câmpuri: id (identificator înregistrare), nume (numele vasului), actualizat (în momentul în care vasul este actualizat, este mai bine să acceptați imediat fusul orar, „AAAA-MM-ZZTh : mm: ssTZD ”, de exemplu,„ 1997 -07-16T19: 20: 30 + 01: 00 ”), este_ șters (semnul înregistrării șterse).

Observație privind prezența ultimului câmp. În mod implicit, valoarea sa este 0. Într-o aplicație în care entitățile sunt sincronizate între client și server, nu se recomandă ștergerea fizică a datelor de pe server (pentru a evita erorile). Prin urmare, is_deleted = 1 este setat pentru vasele șterse. 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 gol):

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

Exemplu de răspuns server:

[
(id: 5625, nume: „Pâine”, actualizat: „06.06.2013 06:23:12”, este Șters: 0),
(id: 23, nume: „Grâu gătit”, actualizat: „01-02-2013 14:44:21”, este Șters: 0), (

nume: "Supă de pește",

actualizat: "02.02.2013 07:05:19",

Principiile actualizării datelor de pe un dispozitiv

1. Dacă un element care se află pe dispozitiv a venit și este șters = 0, atunci acesta este actualizat
2. Dacă a sosit un element care nu este pe dispozitiv și este Șters = 0, atunci acesta este adăugat
3. Dacă un element care se află pe dispozitiv a venit și este Șters = 1, atunci este șters
4. Dacă a sosit 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 ușoară metodă. Dispozitivul solicită o listă de preparate de la server, iar serverul trimite întreaga listă. De fiecare dată când apare întreaga listă. Nu sunt sortate.

Exemplu de cerere: nul sau „()”

Avantaje:

• logica de 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 exista mult trafic pe Internet
• dacă lista este solicitată 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 schimbă foarte rar (lista orașelor, categoriilor)
• transferul setărilor aplicației
• la începutul proiectului pentru primul prototip al unei aplicații mobile

Abordarea 2: sincronizați numai actualizarea

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

Exemplu de cerere: (lastUpdated: „2013-01-01 00:00:00”)

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

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

Această abordare acoperă de obicei majoritatea nevoilor. Numai datele noi vin pe dispozitiv, 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 memorie și procesor.

Abordarea 3: Sincronizarea în loturi

Dispozitivele mobile au puține memorie cu acces aleator... Dacă există 3000 de feluri de mâncare î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 se va bloca sau 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 de sincronizare în fundal va fi scăzută (întârzieri de interfață, defilare netedă etc.) Prin urmare, este necesar să solicitați lista în mai mici porții.

Pentru a face acest lucru, dispozitivul trece încă un parametru („suma”), care determină mărimea 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 trece în câmpul „lastUpdated”. Dacă serverul a trimis exact același număr de entități, atunci dispozitivul continuă sincronizarea și face din nou o cerere, 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 încheie.

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

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

Avantaje:

• Dispozitivul primește la fel de multe date pe cât este capabil să proceseze simultan. Mărimea porției este determinată de teste practice. Entitățile simple pot fi sincronizate 1000 câteodată. Dar, de asemenea, se întâmplă ca entitățile cu un număr mare de câmpuri și 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 suma = 100, ultimele 150 nu vor fi trimise către 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ă există 250 de feluri de mâncare în tabel cu același „actualizat” (de exemplu, „2013-01-10 12:34:56”) și dimensiunea porției este de 100, atunci numai vor veni primele 100 de discuri. Restul de 150 vor fi decupate (actualizat> lastUpdated). De ce se va întâmpla asta? Când sunt solicitate primele 100 de înregistrări, ultima actualizare va fi setată la „2013-01-10 12:34:56” și următoarea solicitare va avea condiția (actualizat> „2013-01-10 12:34:56”). Chiar și 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 importați date 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. De asemenea, se poate întâmpla ca întregul director să aibă același „actualizat”.

Pentru a remedia acest lucru, trebuie să utilizați un câmp antena care ar fi unic cel puțin într-un moment („actualizat”). Câmpul „id” este unic pe întregul tabel, deci 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 (updated = lastUpdated și id> lastId)).

În diagramă: „last_updated”, „last_id” și „amount” sunt valorile stocate în aplicația mobilă. „Last_item” - ultima entitate (antena) trimisă de la server. Este mai nou decât această valoare că 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 iau în considerare faptul că serverul nu știe cu adevărat cât de bine au fost salvate datele pe dispozitiv. Dispozitivul pur și simplu nu poate salva o parte din date din cauza erorilor inexplicabile. Prin urmare, ar fi frumos să primiți confirmarea de pe 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 preparatele din doar 2 orașe din 10. Acest lucru nu se poate realiza cu sincronizările descrise mai sus.

Ideea abordării este următoarea. Serverul stochează (într-un tabel separat „stored_item_list”) informații despre ce feluri 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 vase „id - actualizate” pentru toate dispozitivele.

Dispozitivul trimite informații despre vasele disponibile pe dispozitiv (lista perechilor „id - actualizate”) către server împreună cu o cerere de sincronizare. La cerere, serverul verifică ce feluri de mâncare ar trebui să fie pe dispozitiv și care sunt acum. Diferența este apoi trimisă dispozitivului.

Cum determină serverul ce feluri de mâncare ar trebui să fie pe dispozitiv? În cel mai simplu caz, serverul face o cerere care va returna o listă de perechi „id - actualizate” ale tuturor felurilor de mâncare (de exemplu, SELECT id, actualizate din feluri de mâncare). În diagramă, acest lucru se face prin metoda „WhatShouldBeOnDeviceMethod ()”. Acesta este dezavantajul abordării - serverul trebuie să calculeze (uneori făcând întrebări sql grele) ce ar trebui să fie pe dispozitiv.

Cum determină serverul ce feluri de mâncare sunt pe dispozitiv? Face o interogare la tabelul „stocat_item_list” pentru acest dispozitiv și primește o listă de perechi „id - actualizate”.

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

Cum știe serverul despre vasele disponibile pe dispozitiv? În solicitarea către server, se adaugă un nou parametru „articole”, care conține o listă a id-ului vaselor care au fost trimise dispozitivului în ultima sincronizare („dispozitiv_ultim_stocat_element_element”). Desigur, puteți trimite o listă cu ID-ul tuturor vaselor care sunt pe dispozitiv și nu complicați algoritmul. Dar dacă pe dispozitiv există 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 în mod constant „stocat_item_list” cu datele provenite de pe dispozitiv în parametrul „articole”.

Ar trebui să implementați un mecanism pentru ștergerea datelor serverului în stocat_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ă șteargă lista stocată_item pentru acest dispozitiv. În aplicația noastră, trimitem un parametru suplimentar „clearCache” = 1 în acest caz.

Concluzie

Un tabel rezumat al caracteristicilor acestor abordări:

„Corectitudinea datelor de pe dispozitiv” este probabilitatea ca dispozitivul să conțină toate datele trimise de server. În cazul abordărilor # 1 și # 5, există 100% certitudine că dispozitivul are toate datele de care are nevoie. În alte cazuri, nu există o astfel de garanție. Aceasta 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ă le remediați de pe server (și cu atât mai mult să aflați despre acestea din partea serverului).

Poate că, în prezența tarifelor de internet nelimitate și a conexiunii WiFi gratuite, problema limitării traficului generat de o aplicație mobilă va deveni mai puțin relevantă. Dar, deși 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ției. Nu merge întotdeauna. Uneori este „cu cât este 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ă 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 legături.

Compania noastră oferă servicii pentru crearea serverului de aplicații mobile de afaceri și servicii web pentru clienți care operează în medii cu sarcini mari. Atunci când dezvoltăm fiecare proiect, încercăm să aplicăm o abordare individuală, astfel încât produsul rezultat să devină cea mai optimă soluție la 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 acestuia - un pachet software situat pe un server web și care lucrează cu o aplicație, care în acest caz se numește Front- Sfârșit. O aplicație localizată 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 sale.

Adesea partea serverului aplicației este scrisă în PHP, care este cel mai popular limbaj pentru astfel de soluții. Pentru a implementa sarcini de server simple, pot fi utilizate sisteme standard, dar pentru altele mai specifice, trebuie deja să vă dezvoltați propria soluție sau suplimente față de sistemele standard.

Principiile 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 sarcină 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 pentru toate etapele de dezvoltare și livrare a proiectului la timp.

Programare

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

Testarea

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ă asistență tehnică deplină 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 server a aplicației, sunt necesare anumite abilități și cunoștințe ale limbajului de programare utilizat 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 lumii 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ă profundă a documentației de lucru a proiectului, care va ajuta ulterior la dezvoltarea unui produs de înaltă calitate.

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

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

O altă limbă frecvent utilizată. Vă ajută să creați aplicații server ușor, rapid și ieftin.

Aproape toate companiile moderne au propriile birouri virtuale. Site-ul 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 lor de a rezista atacurilor, încercărilor de hacking și influențelor negative externe, precum și de performanța suficientă pentru multe cereri acceptate simultan.

Etapele dezvoltării serviciilor web

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

1. Dezvoltarea unei idei

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

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

2. Evaluarea proiectului

2-3 săptămâni

Experții noștri evaluează calendarul și costul lucrărilor, apoi se întocmește o propunere preliminară pentru dezvoltare.

3. Termenii de referință și contractul

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

După discutarea cu clientul a tuturor nuanțelor procesului și elaborarea unei specificații tehnice detaliate, este pregătit și semnat un acord.

4. Dezvoltarea interfeței

2-3 săptămâni

Proiectanții sunt implicați în crearea de interfețe necesare pentru scrierea modulelor software.

6. Testarea

2-3 săptămâni

O verificare cuprinzătoare a soluției software rezultate 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, 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 pentru implementarea unui server software, care garantează performanțe ridicate ale aplicațiilor mobile respective. Echipa noastră este reprezentată 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. Acestea controlează implementarea atât a acțiunilor planificate, cât și a îmbunătățirilor necesare.

Designeri

În activitatea lor, specialiștii noștri țin cont de cerințele pentru construirea de interfețe pentru sisteme 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.

Testerii

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 software sau ca program independent, un serviciu web servește la îndeplinirea sarcinilor legate de publicitate, analiză, planificare și promovare a afacerii. În acest sens, este necesar să se decidă ce tip de resursă va fi soluția optimă.

Proiecte de informare

Conceput pentru a găzdui conținut divers.

Site-uri tematice

Aproape toate paginile lor sunt dedicate unui singur subiect. Cererea pentru ei 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, acestea transmit această informație comunității comunității de internet, dar în acest caz, autorii își exprimă opinia personală.

Proiecte sociale

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

Forumuri

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

Retele sociale

Aceste resurse au un public de milioane. Sarcina lor principală este de a oferi utilizatorilor de Internet capacitatea de a comunica online prin text / mesaje vocaleș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-mail, 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 cereri.

Panouri de informare

Acestea sunt resurse web în care internauții își postează reclame de vânzare și cumpărare și servicii în diferite subiecte.

Site-uri de găzduire

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ări care sunt deseori puse de specialiștii noștri. Dacă nu găsiți informațiile de interes aici, vă rugăm să puneți întrebarea în acest sens formă, și cu siguranță vom răspunde.

Cât timp poate dura construirea aplicației și a serverului web?

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