Razvoj poslužiteljskog dijela mobilnih aplikacija. Razvoj mobilne aplikacije: Sinkronizacija sa serverom Razvoj serverskog dijela aplikacije

SIGURNOSNE KOPIJE

Zašto su vam potrebne sigurnosne kopije na mobilnoj platformi?

Stručnjaci znaju koliko su mobilne aplikacije na 1C ponekad nepouzdane: pogreške se mogu pojaviti u bilo kojem trenutku, zbog čega će baze podataka korisnika jednostavno biti uništene. Istodobno, suočeni smo s nepouzdanošću samih uređaja: mogu se pokvariti, izgubiti, ukrasti, a korisnici žele sačuvati svoje podatke. A do verzije 8.3.9 nismo imali platformski mehanizam za spremanje sigurnosnih kopija.

Budući da korisnici prije nisu imali gumb "spremi kopiju", programeri aplikacije Boss morali su sami napraviti sigurnosne kopije. Kako smo to uspjeli?

Same podatke baze podataka spremamo u XML obliku.

Preporučljivo je ponuditi korisniku nekoliko opcija za pohranjivanje kopija - prije svega, to je prikladno za klijente, mogu odabrati najbolju opciju za sebe: prenijeti u oblak, poslati sebi e-poštom, spremiti na svoj uređaj.

Tako se programeri dodatno osiguravaju. Ako nešto pođe po zlu i iznenada se pokvari mehanizam za stvaranje kopija na Google Driveu ili Yandex Driveu, uvijek možete reći korisniku da ovaj trenutak programer rješava grešku, ali za sada može spremiti podatke alternativni način. A korisnici su zadovoljni jer mogu biti sigurni u svoje podatke.

Obavezno treba se usredotočiti na usluge u oblaku , jer ako se uređaj izgubi ili pokvari, a korisnik je spremio kopiju na isti uređaj, tada će podaci biti izgubljeni.

Također i mi Svakako podsjećamo korisnika na potrebu izrade sigurnosnih kopija.

Kako spremiti kopije ako se konfiguracija promijeni?

Kada govorimo o masovnom rješenju, aplikaciji koja se stalno mijenja, razvija i poboljšava, moramo voditi računa o ponašanju korisnika. Korisnik će možda htjeti vratiti sigurnosnu kopiju spremljenu u stara verzija prijavu gdje nije bilo pojedinosti. I onda se postavlja zadatak: pročitati podatke, pa ispuniti podatke po logici ažuriranja sa stare verzije aplikacije. Kako to učiniti? Osim podataka, spremite i samu strukturu podataka, kako biste je kasnije znali čitati.

Postoji nekoliko opcija za pohranjivanje ove strukture podataka, uključujući pohranjivanje u samoj konfiguraciji. Odnosno, prilikom objavljivanja svake nove verzije sačuvajte strukturu metapodataka prethodna verzija u rasporedu u konfiguraciji.

Ne treba zaboraviti da u mobilnoj aplikaciji konfiguracija ne treba samo rasti, moramo cijeniti prostor u njoj, moramo je učiniti što kompaktnijom. No, aplikacija se razvija i takvih će izgleda biti mnogo, a s vremenom će ih biti sve više.

Stoga je u slučaju mobilne aplikacije poželjniji drugi način - spremite strukturu metapodataka izravno u podatkovnu datoteku. Na izlazu dobivamo ovu datoteku, gdje prvo spremamo neke pomoćne podatke - konfiguracijsku verziju, konfiguracijski dijagram, granice niza, a zatim upisujemo same korisničke podatke u XML format. Štoviše, u odjeljku "Pomoćni podaci" datoteke možete pohraniti i druge važne podatke koji iz nekog razloga nisu mogli biti upisani u XML.

Uzimamo podatkovnu shemu koju smo spremili u datoteku i na temelju nje gradimo XDTO paket za čitanje datoteke. Sličan objekt kreiramo u bazi podataka, ispunimo ga, izvršimo dodatnu obradu prilikom ažuriranja i spremamo gotov objekt u bazu podataka.

Dolje na slici možete vidjeti savjet kako lijepo napisati XDTO model konfiguracijskih podataka. Tvrtka koja je izdala aplikaciju Boss eksperimentirala je s tim, pronašla nekoliko načina, ali se odlučila za ovu opciju za snimanje sheme metapodataka. Kada se otvori sama podatkovna datoteka, možete vidjeti uobičajeni strukturirani XML, čitljiv, koji navodi sve metapodatke aplikacije.

// Snimanje konfiguracijskog dijagrama ModelXDTO = FactoryXDTO.ExportModelXDTO("http://v8.1c.ru/8.1/data/enterprise/current-config"); FactoryXDTO.WriteXML(UploadFile, ModelXDTO); // Čitanje konfiguracijske sheme ModelXDTO = FactoryXDTO.ReadXML(ReadXML, FactoryXDTO.Type("http://v8.1c.ru/8.1/xdto","Model")); FactoryUnload = Nova tvornicaXDTO(ModelXDTO);

Kako biste zaštitili korisnika, morate ga ponovno pitati treba li vratiti sigurnosnu kopiju. Možda je samo eksperimentirao i pritiskao sve tipke u aplikaciji :) I sada može izgubiti trenutne podatke. Stoga pri izvođenju potencijalno “opasnih” radnji uvijek razjašnjavamo želi li on to doista i kako bi se to trebalo dogoditi. Korisnik mora biti svjestan svojih postupaka.

Mora postojati mehanizam za izradu sigurnosnih kopija kada govorimo o offline rješenju, kada korisnik ima sve podatke pohranjene isključivo na mobilnom uređaju: korisnik može izgubiti svoj uređaj, a onda će se izgubiti i podaci. I, čini se, ako aplikacija ne radi autonomno, već je povezana sa središnjim poslužiteljem, tada korisnik ne bi trebao imati takav problem, jer ako se uređaj izgubi, spojit će se na poslužitelj, primiti sve svoje podatke opet sa servera i sve će biti ok.

Međutim, korisnici sigurnosne kopije ne koriste uvijek na način na koji to od njih očekujemo :) Vrlo često ih koriste za jednostavno “vratljenje” podataka. Ovo je stvarno vrlo čudno ponašanje, ali korisnici mobilne aplikacije previše lijeni da otkriju gdje su mogli pogriješiti prilikom unosa podataka, te jednostavno vrate podatke i ponovno unesu podatke za tekući dan. Nakon analize statistike rada s aplikacijom Boss, uvidjeli smo da je to normalna praksa i da je ovakvo ponašanje korisnika češće nego što smo mogli zamisliti.

A ako koristite sinkronizaciju s drugim uređajima, onda morate to riješiti. Ovdje postoji nekoliko rješenja:

prekinuti vezu s poslužiteljem, navodeći da će podaci na njemu ostati kakvi su bili, a kopija će se vratiti samo na korisnikov uređaj;
Korisniku je bolje dopustiti da vrati kopiju na svim uređajima odjednom, prethodno propisavši takve mehanizme.

Ovdje postoji još jedna stvar. Do sada smo sami spremali sigurnosne kopije, kontrolirali cijeli proces i hvatali radnje korisnika izravno u kodu kada je kliknuo gumb "spremi kopiju". Sve se to može naknadno obraditi. U platformi 8.3.9 postalo je moguće spremati sigurnosne kopije pomoću alata platforme. A korisnik to radi bez našeg znanja. Ako se koristi sinkronizacija sa središnjom bazom podataka, tada se takav scenarij mora obraditi. Moramo nekako saznati na našem poslužitelju da je korisnik vratio prethodno spremljenu kopiju i moramo mu dati neko rješenje. Ne možemo si priuštiti da podaci ne budu sinkronizirani.

ZAMJENICE

Kada govorimo o privatnom rješenju na mobilnoj platformi, obično imamo kupca koji npr. želi koristiti mobilnu platformu za svoje prodajne agente i razmjenjivati podatke sa središnjom bazom podataka. Ovdje je sve jednostavno: jedna baza podataka, nekoliko uređaja, postavite poslužitelj, postavite vezu s njim. Dakle, problem razmjene između uređaja je jednostavno riješen.

Ali ako govorimo o masovnoj aplikaciji, gdje postoji mnogo baza podataka, od kojih svaka ima puno korisnika, situacija postaje kompliciranija. Korisnici su preuzeli aplikaciju s tržišta i žele se međusobno sinkronizirati. Na primjer, muž je skinuo aplikaciju za računovodstvo osobnih financija, a sada želi da se i njegova supruga poveže i rade zajedno u istoj aplikaciji. Mnogo je korisnika, aplikacija se razvija, raste i postoji potreba za velikim, velikim brojem baza podataka. Kako sve to organizirati? Korisnici neće osobno kontaktirati programere kako bi za njih izradili zasebnu bazu podataka i omogućili sinkronizaciju. Žele pritisnuti gumb i sve odmah proradi. U istom trenutku.

Kako nastaviti? Tu u pomoć dolazi mehanizam za razdvajanje podataka. Omogućuje organiziranje jedne baze podataka, gdje postoji jedna zajednička konfiguracija, ali u isto vrijeme, neograničen broj korisničkih baza podataka pohranjen je unutar jedne zajedničke baze podataka.

Najbolji dio je što korisnike možete dodavati dinamički, programski, bez našeg sudjelovanja. U stvarnosti korisnici jednostavno kliknu na gumb "registracija na poslužitelju" i sve se događa samo od sebe: na poslužitelju se stvara osobna baza podataka i on odmah može početi raditi u njoj.

Kako to učiniti? Prvo i najjednostavnije rješenje je napisati vlastitu bazu poslužitelja s ovim mehanizmom. Kada je naša tvrtka krenula s izradom aplikacije Boss i razmjene u njoj, u prvoj smo verziji napravili upravo to: napisali smo serversku bazu podataka s mehanizmom dijeljenja podataka. Sve je radilo, pogotovo jer nije bilo ništa komplicirano - separator baze je uobičajeni atribut.

Ali onda smo shvatili da smo ponovno izumili kotač :) Zapravo, već postoji gotovo rješenje, a već uzima u obzir točke o kojima još nismo ni razmišljali. Ovo je 1C:Fresh.

Ovdje se razmišlja o skalabilnosti usluge: što učiniti kada ima puno podataka i baza podataka, kako rasti uz sve to. Ovdje postoji trenutak o stvaranju sigurnosne kopije područja podataka: to jest, ne izrađujemo samo sigurnosnu kopiju jedne zajedničke baze podataka, izrađujemo kopije konkretnog korisnika. Štoviše, tamo je mehanizam takav da se kopije izrađuju samo kada su stvarno potrebne. Ako se korisnik nije ulogirao u bazu tjedan dana, tada mu ne radimo kopije, jer se tu ništa nije promijenilo. Još jedna značajka Fresha je da usluga implementira mehanizam za smanjenje opterećenja na poslužitelju, a to je vrlo važno kada imate mnogo baza podataka.

Općenito, Fresh je nešto novo i zanimljivo za nas. Polako pokušavamo to shvatiti, ali većinom smo samo zadovoljni kako funkcionira.

Prijenos podataka. Kako to implementirati za razmjenu između uređaja

Platforma nudi dva mehanizma - SOAP i http usluge. Ovdje postoje nijanse o tome kako pristupiti tim uslugama kada je uključen mehanizam za odvajanje podataka. Konkretno, trebate dodati parametre koji označavaju određeni broj područja kojem pristupate, jer platforma ne može odrediti kojoj bazi podataka pristupiti s korisničkim imenom. Osim toga, isti korisnik može raditi s više baza podataka unutar jedne baze (vidi sliku).

Što se tiče usluga, aplikacija Boss provodi trenutnu razmjenu: jedan korisnik unosi podatke, a drugi ih prima. Korisnici mobilnih aplikacija navikli su da se sve događa odmah, pa smo razmišljali kako bolju uslugu koristiti - SOAP ili http. Brzina veze odigrala je ključnu ulogu. U httpu je brzina povezivanja puno veća, a pri spajanju preko SOAP-a dobivamo opis usluge koji je težak i dugo se učitava. Platforma ima način pohranjivanja opisa usluge, ali zbog parametara koje dinamički dodajemo, ne možemo koristiti WS poveznice. Osim toga, prema našem iskustvu, pristup http uslugama je praktičniji i fleksibilniji.

Dakle, naš cilj je implementirati razmjenu u stvarnom vremenu. Odnosno, trudimo se da ne bude tako da korisnik mora negdje otići, kliknuti na neku tipku, razmišljati koliko su mu podaci ažurni, treba li ih ažurirati... Podaci korisnika trebaju uvijek biti gore. -do danas. Toliko su navikli na to kada rade u instant messengerima - jedan je poslao podatke, drugi ih je odmah primio. Sve se događa trenutno. Isto vrijedi i za aplikacije vezane uz poslovanje: jedan prodavač je završio prodaju, drugi mora odmah vidjeti trenutno stanje bez poduzimanja bilo kakve radnje.

Zato aplikacija Boss koristi pozadinske poslove za razmjene. Nakon svakog unosa podataka u bazu, pokreće se pozadinski posao koji inicira razmjenu. Prvi dio je slanje podataka na poslužitelj. Tada bi drugi uređaji trebali znati da postoje novi podaci. Za to koristimo PUSH obavijesti. Ova shema već radi i radi prilično brzo.

Ali htjeli smo to učiniti još brže, jer radimo u stvarnom vremenu i u pravilu nemamo puno podataka. Imamo mali XML, ali u isto vrijeme šaljemo poruku s tim podacima s prvog uređaja na poslužitelj, poslužitelj šalje PUSH drugom uređaju, a zatim drugi uređaj nakon što primi PUSH inicira razmjenu sa svoje strane , kontaktira poslužitelj i traži podatke, prima te podatke i zatim šalje odgovor da su podaci primljeni. Dugo je to vrijeme, ali bilo je vrlo malo podataka.

Pitali smo se kako bi se taj proces mogao ubrzati.

Da bismo to učinili, otkrili smo što PUSH sadrži i kako se također može koristiti. Ispostavilo se da PUSH sadrži polja kao što su podaci i tekst. U dokumentaciji za iOS i Android navedena su ograničenja veličine PUSH poruka, no nama se to nije učinilo dovoljno i htjeli smo to sami shvatiti iskustvom. A provjerili smo da je za iOS zbroj dopuštenih znakova 981, a za Android 3832 znaka. U potonjem slučaju, ograničenje se može koristiti; jedan ili više objekata baze podataka može se ugurati u takav volumen. A onda su programeri tvrtke malo promijenili shemu. Kada nema puno podataka, šaljemo ih s jednog uređaja, primamo na server, tamo pakiramo u PUSH i šaljemo direktno na drugi uređaj. Shema je postala kraća, a razmjena se počela odvijati još brže :)

Važna točka u korištenju PUSH-a je da ne iritiramo korisnike.

Vrlo je lako riješiti se ove situacije: samo nemojte korisniku slati puno PUSH poruka :) Ako trenutno radi u aplikaciji, možete slati puno poruka. Kada je platforma pokrenuta, korisnik ne vidi PUSH, sve se događa automatski. Ali kada je aplikacija zatvorena, klijent ima mnogo nepročitanih poruka. Stoga se ni pod kojim okolnostima ne smije poslati sljedeći PUSH dok se od uređaja ne dobije odgovor da je aplikacija pokrenuta, aktivna i da je prethodni PUSH već obrađen.

Još jedna nijansa razmjene je rad putem weba. Moramo koristiti asinkroniju što je više moguće. Ne možete raditi kao i obično - napisali ste kod - pozvali funkciju - pričekali da se izvrši - dobili odgovor - i sve je u redu. Ako radite putem weba, i dalje ćete se susresti s određenim ograničenjima, na primjer, nestabilnim internetom, vremenskim ograničenjima pri izvođenju dugotrajnih operacija. Stoga je potrebno unaprijed razmisliti o arhitekturi.

Na primjeru registracije uređaja pogledajmo što se događa u aplikaciji kada se korisnik želi registrirati. Neko vrijeme vodi evidenciju, unio je dosta podataka, ali onda želi da i prodavač radi s tom bazom podataka. Korisnik klikne na gumb "registracija". U početku je sve bilo vrlo jednostavno: uzeli smo njegove podatke, snimili ih na server i, molim vas, možete raditi i povezivati korisnike. Ali onda smo naišli na situaciju u kojoj su baze podataka nekih korisnika na njihovim uređajima već značajno porasle do trenutka kada su se registrirali. I ova shema više nije funkcionirala, jer... Dok se cijela baza podataka snimala na poslužitelju, veza je istekla ili je internet jednostavno nestao. Stoga smo jedan sinkroni poziv zamijenili s mnogo kratkih. Danas se podaci dijele, a ne prenose svi odjednom. Ni u kojem slučaju ne čekamo dok poslužitelj obrađuje i upisuje podatke. Poslali smo podatke, dobili odgovor da su podaci primljeni i prekinuli vezu. Povremeno je potrebno izvršiti prozivanje poslužitelja kako bi saznali što se tamo događa i kako, au međuvremenu se na poslužitelju odvija pozadinski posao koji bilježi primljene podatke. To rezultira velikim brojem poziva poslužitelja, ali imamo jamstvo da će sve proći u redu. A niti vremensko ograničenje niti nestabilnost interneta neće vas spriječiti da učitate sve podatke na poslužitelj.

NADOPUNE

Razmjena između uređaja s različitim verzijama aplikacije

Budući da govorimo o masovnoj aplikaciji koja je puštena na tržišta, moramo uzeti u obzir neke značajke procesa ažuriranja i razmjene podataka.

Ako ste izdali aplikaciju za jedno poduzeće i odlučite je ažurirati, tada obično jednostavno date naredbu tako da svi zaposlenici jednoglasno instaliraju novu aplikaciju. To se ne može učiniti s korisnicima koji su aplikaciju preuzeli s marketa. Ne možete im uopće govoriti što da rade. Na primjer, rade u aplikaciji i ne žele je ažurirati ni sada ni ikada. Nemaju auto-update, pa je sasvim česta situacija kada je više uređaja spojeno na središnju bazu, a svi imaju različite verzije. Drugi razlog za ovu pojavu je vrijeme objave na tržištima: ono je različito za iOS i Android. Često implementiramo ključne stvari, na primjer, popravljanje kritične pogreške, i ne želite čekati da iOS provjeri dva tjedna nova verzija, želimo barem samo za Android, ali objaviti ažuriranje odmah.

Nemamo pravo zapovijedati korisnicima. Ako žele, ažuriraju, a ako ne, ne rade ništa. Na slici je prikazan omjer instalacija aplikacije Boss po verzijama na GooglePlayu, kao i statistika s našeg servera - stvarni omjer verzija aplikacija koje su instalirane na uređajima koji su razmjenjivali podatke sa serverom u proteklom tjednu. Ovo je set s kojim trebate raditi. Ovaj različite verzije i razne metapodatke. I moramo organizirati normalnu razmjenu u ovom slučaju :)

Programeri se suočavaju sa sljedećim zadacima:

Ovo sve treba raditi. Korisnici se ne bi trebali osjećati neugodno jer su zaboravili izvršiti ažuriranje. Oni to uopće ne bi trebali primijetiti. Ažurirano - postalo je bolje, dobro, dobro.
Moramo osigurati sigurnost podataka. Na primjer, jedan korisnik ima imenik i nove podatke, ali drugi ih još nema. Štoviše, ako korisnik koji nema nove podatke promijeni nešto na svom uređaju, tada podaci ne bi trebali biti izgubljeni na drugim uređajima.
Moramo osigurati ažuriranje podataka kada prijeđemo na novu verziju. Kada korisnik odluči da je spreman za nadogradnju, automatski bi trebao imati sve nove informacije koje nije imao samo zato što je imao staru verziju.

Kako smo to uspjeli?

1. Koristimo 2 plana razmjene na poslužitelju. Prvi je za dijeljenje između uređaja, a drugi za ažuriranja. Na primjer, korisniku smo poslali priručnik, ali on nema mjerne jedinice, odnosno nepotpune podatke. Ovo moramo zapamtiti. A kada se ažurira, moramo mu poslati sve podatke koje nije imao. Zbog toga vam je potreban drugi plan razmjene.

2. Za pisanje i čitanje objekata koristimo isti mehanizam koji se koristi za sigurnosne kopije, odnosno spremamo verziju metapodataka. U ovom slučaju radimo s poslužiteljem i možemo si priuštiti dodavanje bilo čega što želimo izravno u konfiguraciju, tako da jednostavno dodajemo sheme metapodataka u konfiguraciju u obliku izgleda kako se aplikacija razvija.

Kako pratiti masivne pogreške tijekom razmjene i na poslužitelju

Prvo morate kontrolirati dostupnost samog poslužitelja. To se događa s poslužiteljima - ruše se. Nismo izmislili ništa posebno za praćenje, već smo jednostavno pronašli bota u telegramu koji vrišti ako nešto nije u redu. Svake minute provjerava performanse poslužitelja, a ako iznenada poslužitelj bude nedostupan, počinje vrištati, administratori to vide i podižu poslužitelj.

Također prikupljamo zapisnike grešaka iz dnevnika. Ništa previše otmjeno - samo prikupljamo zapisnike pogrešaka svaka tri sata, šaljemo ih e-poštom i povremeno ih pregledavamo. Pomaže vam da vidite uobičajeni problemi i neke iznimne situacije. Nije teško pregledavati e-poštu, pratiti i brzo ispravljati pogreške. Ali to vam omogućuje da brzo identificirate i riješite probleme koji mogu rasti kako rastu baze podataka.

Više važna točka- svakako dajte korisniku priliku da se "žali". To poboljšava naš status u njihovim očima i spašava nas. Postoje korisnici, kako ih zovemo, “histerici”, koji nam i na najmanju pogrešku počnu slati hrpu poruka mailom da ništa ne radi, baza se ne učitava, sve je užasno loše. Ali ponekad nas stvarno spase, jer ponekad pronađu greške koje drugi nekim čudom još nisu otkrili, ozbiljne greške.

Korisnik se ne treba bojati. Ne zastrašujuće poruke ili bilo što drugo. Treba im sve lijepo objasniti i pozvati da se žale. I obećavamo da ćemo sve riješiti. Tada su korisnici sretni, jer vide da su zbrinuti i odmah vjeruju da će im se pomoći :)

Ovaj je članak napisan na temelju rezultata izvješća danog na konferenciji INFOSTART EVENT 2016 DEVELOPER. Više članaka možete pročitati.

U 2020. pozivamo sve da sudjeluju na 7 regionalnih susreta, kao i na obljetničkom INFOSTART EVENT 2020 u Moskvi.

Razvoj aplikacijskog poslužitelja

Uvod

Prisutnost na internetu postala je nužnost modernih tvrtki. Bez toga je nemoguće izgraditi potpunu interakciju s klijentima. Često, kako bi riješili takav problem, pribjegavaju stvaranju aplikacija klijent-poslužitelj. Svaki od njih sastoji se od klijentskog dijela i Back-enda. Posljednji izraz odnosi se na poslužiteljski dio aplikacije. Ako u budućnosti trebate sami promijeniti sadržaj mobilni program, onda Back-end mora biti izrađen s posebno visokom kvalitetom. Appomart jamči da će dodijeljeni poslovi biti izvršeni u skladu sa zahtjevima. Stoga, prilikom naručivanja izrade poslužiteljskih aplikacija, možete biti sigurni u pravilan rezultat.

Čemu služi Back-end?

Razvoj aplikacija klijent-poslužitelj uključuje stvaranje dva dijela. Prvi, Front-end, prihvaća zahtjeve korisnika. Ona je vidljiva s ekrana Mobilni uredaji klijentima. Druga, poslužiteljska aplikacija, obrađuje primljene zahtjeve i djeluje kao administrativni panel. Ovdje se pohranjuju baze podataka i programska logika. Bez toga niti jedna aplikacija klijent-poslužitelj neće raditi. Zapravo, Back-end je srce programa. Riječ je o inteligenciji koja je odgovorna za obradu zahtjeva korisnika i brzinu aplikacije. Stoga je važno da je arhitektura poslužiteljske aplikacije osmišljena do najsitnijih detalja, tako da čak i visoko opterećeni servisi rade glatko i brzo.

Kako odabrati programski jezik?

Tijekom pripreme projektni zadatak(dijelovi radne dokumentacije za projekt), arhitekt projektira sustav baza podataka i veza, opisuje objekte i njihova svojstva, te razvija potrebne poslužiteljske metode (upiti koje će mobilne aplikacije “koristiti” prilikom pristupa poslužitelju).

Važnost dokumentacije i napuštenih projekata

Appomartu se često obraćaju kupci koje su iz ovog ili onog razloga "napustili" drugi izvođači. I mi preuzimamo tuđi, ponekad čak i neispravno radni projekt, provodimo njegovu reviziju i naknadnu doradu i podršku. U procesu studiranja izvorni kod i materijala primljenih od korisnika, suočeni smo s činjenicom da mnogi programeri namjerno ne dokumentiraju metode poslužitelja kako bi vezali klijenta za sebe, zbog nesumjerljivosti troškova rada prijenosa projekta za podršku drugom programeru, zbog nedostatak dokumentacije za serverski dio, a ponekad jednostavno zbog neprofesionalnosti. Ova činjenica, nažalost, nije samo tužna, već je i raširena. Kupac, u ovom slučaju, mora platiti razvoj dokumentacije za postojeći projekt, kao i reviziju izvornog koda, prije nego što se može prosuditi o operativnosti, praktičnosti i izvedivosti podrške projektu. Osoblje Appomarta uvijek održava elektroničku dokumentaciju pozadinskih metoda u formatu koji podržavaju Postman i Swagger za buduće potrebe.

Kako provjeriti izvođača prije potpisivanja ugovora?

Pozivamo vas da pažljivo birate izvođača, te da se ne fokusirate samo na primamljivu cijenu, već i na popis dokumenata koje ćete dobiti uz projekt, kao i uvjete prijenosa izvornog koda, te pokrivenost koda komentarima , sheme baze podataka (bilo Mongo DB ili MySQL). Ključ uspjeha, u pravilu, je kompetentna radna dokumentacija, koja jasno ukazuje na zahtjeve za materijale koji vam se prenose nakon završetka svake faze rada.

Značajke razvoja

PHP za poslužiteljsku stranu

Izrada poslužiteljskog dijela aplikacija (ne brkati s poslužiteljima kao hardverom ili računalima, budući da je riječ o softverskom dijelu) zahtijeva specifične stručne vještine i poznavanje programskog jezika koji se koristi na strani poslužitelja. Ako pogledamo primjere klijent-poslužitelj aplikacija, možemo vidjeti da je PHP popularan. Neosporni je lider u području razvoja poslužiteljskih aplikacija. Više od polovice web stranica na svijetu napisano je na ovom jeziku u jednoj ili drugoj konfiguraciji. PHP je pogodan za razvoj i podršku, a osim toga postoje posebni okviri za ubrzavanje razvoja u PHP-u.

Okvir

Okvir ( softverska platforma) - koristi se za sistematiziranje i povećanje razine apstrakcije, što projekt čini fleksibilnijim i skalabilnijim. Međutim, vrijedno je razumjeti da se okvir mora odabrati ispravno, na temelju dubinske analize radne dokumentacije projekta, bez koje je nemoguće razviti visokokvalitetni proizvod.

Delphi, JAVA, Python

Postoje i drugi jezici koji se koriste za stvaranje Back-end-a. Dakle, one nastale u Delphi okruženje poslužiteljske aplikacije. Uz njegovu pomoć, program dobiva poboljšano otklanjanje pogrešaka; također je lako stvoriti jedinstvene programe u okruženju; osigurana je vizualna kreacija, što omogućuje stvaranje lijepog, razumljivog i praktičnog sučelja. Poslužiteljske aplikacije u Javi također su stekle popularnost. Lako ih je dodati, lako ih je izvršiti na bilo kojoj platformi i imaju pristojnu razinu sigurnosti. Python je još jedan popularan jezik. Uz njegovu pomoć poslužiteljske aplikacije izrađuju se brzo, jednostavno i bez značajnih troškova.

Širenje

Stvaranje klijent-poslužitelj aplikacija je traženo u korporativnom okruženju. Često se takvi programi koriste za rad u grupama ili stvaranje informacijski sustavi unutar poduzeća. Velika većina mobilnih aplikacija za održavanje komunikacije s klijentom također ima sličnu arhitekturu. Popularnost je posljedica činjenice da korištenje mogućnosti poslužitelja omogućuje osiguranje kontrole i integriteta sustava, a istovremeno smanjuje opterećenje mreže.

Izradit ćemo klijent-server aplikaciju za Android i iOS kvalitetno i na vrijeme

Razvoj ključ u ruke

Appomart programeri su iskusni i kvalificirani za implementaciju zadataka najrazličitijih razina. Jednako smo dobri u implementaciji društvenih mreža, opterećenih poslovnih projekata ili softvera za male startupe. Po potrebi izradit ćemo klijentski dio aplikacije pod Android kontrola, iOS u skladu s postojećim potrebama i zahtjevima.

Pozadina u Appomartu

Naši programeri rade s različitim tehnologijama i rade to jednako dobro. U Appomartu možete naručiti klijent-poslužitelj aplikaciju u Javi, PHP-u i Node.JS-u. Zahtjevi sustava analiziraju se za svaki projekt pojedinačno, čime se osigurava optimalna izvedba programa. Napravit ćemo klijent-poslužitelj aplikaciju u Javi, PHP-u i Node.JS od nule ili ćemo upotrijebiti postojeću za podršku za poboljšanja i ažuriranja. Ukoliko ste zainteresirani za razvoj novog poslužiteljskog dijela ili podršku postojećeg, ostavite zahtjev za detaljan izračun cijene rada i mogućnosti suradnje.

Značajan dio moderne aplikacije za mobilne platforme(iOS, Android, itd.) radi u tandemu s poslužiteljem. Aplikacija sa zastarjelim podacima gubi svoju korisnost. Stoga je važno osigurati da se podaci od poslužitelja do uređaja stalno ažuriraju. Ovo se odnosi na izvanmrežne aplikacije koje bi trebale raditi bez interneta. Za potpuno online aplikacije, koji ne rade (ili su beskorisni) bez interneta (primjerice Foursquare, Facebook) imaju svoje specifičnosti, koje su izvan okvira ovog članka.

Na primjeru jedne od naših offline aplikacija, reći ću vam koje smo pristupe koristili za sinkronizaciju podataka. U prvim verzijama razvili smo se jednostavne algoritme, a kasnije smo ih s iskustvom unaprijedili. U članku je prikazan sličan slijed - od jednostavnih očitih praksi do složenijih.

Treba pojasniti da se u članku govori o prijenosu podataka u samo jednom smjeru: od poslužitelja do uređaja. Ovdje je poslužitelj izvor podataka.

Opće odredbe za sve pristupe

Na primjer, razmotrit ćemo prijenos imenika posuđa ("posuđe") na uređaj. Pretpostavit ćemo da uređaj postavlja zahtjev na url “/service/dishes/update”, razmjena se odvija preko http protokola u JSON formatu ( www.json.org). Poslužitelj ima tablicu “jela” s poljima: id (identifikator zapisa), naziv (naziv jela), ažurirano (trenutak ažuriranja jela, bolje je odmah podržati vremensku zonu, “GGGG-MM-DDThh: mm:ssTZD”, na primjer, “1997 -07-16T19:20:30+01:00”), is_deleted (znak izbrisanog zapisa).

Napomena o prisutnosti posljednjeg polja. Prema zadanim postavkama, njegova je vrijednost 0. U aplikaciji u kojoj su entiteti sinkronizirani između klijenta i poslužitelja, ne preporučuje se fizičko brisanje podataka s poslužitelja (kako bi se izbjegle pogreške). Stoga su izbrisana jela postavljena na is_deleted = 1. Kada entitet s is_deleted = 1 stigne na uređaj, briše se s uređaja.

Bilo kojim pristupom, o kojem će biti riječi u nastavku, poslužitelj se vraća na uređaje JSON polje objekti (mogu biti prazni):

[
(iskaznica: ,Ime: , ažurirano: ,je izbrisano: },…
]

Primjer odgovora poslužitelja:

[
(id: 5625, ime: "Kruh", ažurirano: "2013-01-06 06:23:12", je Izbrisano: 0),
(id: 23,name: "Kuhani griz",updated: "2013-02-01 14:44:21",isDeleted: 0),(

naziv: "Riblja čorba",

ažurirano: "2013-08-02 07:05:19",

Načela za ažuriranje podataka na uređaju

Ako stigne element koji je na uređaju i isDeleted = 0, tada se ažurira
Ako stigne element koji nije na uređaju i isDeleted = 0, tada se dodaje
Ako je stigao element koji je na uređaju i isDeleted = 1, tada se briše
Ako stigne element koji nije na uređaju i isDeleted = 1, tada se ništa ne radi

Pristup 1: Sve je uvijek sinkronizirano

Ovo je najjednostavniji način. Uređaj od poslužitelja traži popis jela, a poslužitelj šalje cijeli popis. Svaki put lista dolazi puna. Nije sortirano.

Primjer zahtjeva: null ili “()”

Prednosti:

Logika na serveru je jednostavna - uvijek sve poklanjamo
Logika na uređaju je jednostavna – uvijek sve prebrišemo

Mane:

ako često tražite popis (svakih 10 minuta), tada će biti puno internetskog prometa
ako rijetko tražite popis (jednom dnevno), tada će relevantnost podataka biti narušena

Područje primjene:

za aplikacije s malim prometom
prijenos podataka koji se vrlo rijetko mijenjaju (popis gradova, kategorija)
prijenos postavki aplikacije
na početku projekta za prvi prototip mobilne aplikacije

Pristup 2: Sinkroniziran je samo ažurirani

Uređaj zahtijeva popis jela ažuriran od prethodne sinkronizacije. Popis dolazi poredan prema "ažurirano" uzlaznim redoslijedom (neobavezno, ali prikladno). Uređaj pohranjuje “updated” vrijednost za posljednje poslano jelo i na sljedeći zahtjev šalje je poslužitelju u parametru “lastUpdated”. Poslužitelj šalje popis jela koja su novija od “lastUpdated” (updated > lastUpdated). Na prvom zahtjevu poslužitelju, "lastUpdated" = null.

Primjer upita: (zadnje ažurirano: “2013-01-01 00:00:00”)

U dijagramu: "last_updated" je vrijednost koja je pohranjena na uređaju. Obično se na uređaju stvara zasebna tablica za pohranjivanje ovih "last_updated" vrijednosti za svaki entitet (jela, gradovi, organizacije itd.)

Ovaj pristup je pogodan za sinkronizaciju jednostavnih linearnih popisa čija su pravila za dolazak na uređaj ista za sve uređaje. Za selektivniju sinkronizaciju pogledajte “Pristup 5: Sinkronizacija uz znanje o tome što je već na uređaju.”

Obično ovaj pristup pokriva većinu potreba. Na uređaj dolaze samo novi podaci, možete se sinkronizirati barem svake minute - promet će biti mali. Međutim, postoje problemi povezani s ograničenjima mobilnih uređaja. To su memorija i procesor.

Pristup 3: Sinkronizacija u komadima

Mobilnih uređaja ima malo RAM memorija. Ako u direktoriju ima 3000 jela, tada raščlanjivanje velikog json niza s poslužitelja u objekte na uređaju može uzrokovati nedostatak memorije. U tom slučaju aplikacija će se ili srušiti ili neće spremiti ovih 3000 jela. Ali čak i ako je uređaj uspio probaviti takav niz, izvedba aplikacije tijekom sinkronizacije u pozadini bit će niska (kašnjenja sučelja, neglatko pomicanje itd.) Stoga je potrebno zatražiti popis u manjim dijelovima.

Da bi to učinio, uređaj šalje drugi parametar ("količinu") koji određuje veličinu porcije. Popis se šalje obavezno razvrstan prema polju "ažurirano" uzlaznim redoslijedom. Uređaj, slično prethodnom pristupu, pamti “updated” vrijednost posljednjeg poslanog entiteta i prenosi je u polje “lastUpdated”. Ako je poslužitelj poslao točno isti broj entiteta, tada uređaj nastavlja sinkronizaciju i ponovno postavlja zahtjev, ali s ažuriranim "lastUpdated". Ako je poslužitelj poslao manje entiteta, to znači da više nema novih podataka i sinkronizacija završava.

U dijagramu: “last_updated” i “amount” su vrijednosti koje su pohranjene u Mobilna aplikacija. “last_item” – zadnji entitet (jelo) poslan sa servera. Sljedeći popis će biti zatražen noviji od ove vrijednosti.

Primjer zahtjeva: ( lastUpdated: “2013-01-01 00:00:00”, iznos: 100 )

Prednosti:

Uređaj prima onoliko podataka koliko može obraditi odjednom. Veličina porcije određena je praktičnim testovima. Jednostavni entiteti mogu se sinkronizirati 1000 odjednom. Ali također se događa da entiteti sa veliki iznos polja i složenu logiku obrade spremanja, obično se ne sinkronizira više od 5 komada.

Mane:

Ako postoji 250 jela s istim ažuriranjem, tada s količinom = 100 zadnjih 150 neće stići na uređaje. Ova situacija je sasvim stvarna i opisana je u sljedećem pristupu.

Pristup 4: Ispravna sinkronizacija u komadima

U prethodnom pristupu, moguće je da ako postoji 250 jela u tablici s istim "ažuriranim" (na primjer, "2013-01-10 12:34:56"), a veličina porcije je 100, tada samo doći će prvih 100 zapisa. Preostalih 150 bit će odsječeno zbog teškog uvjeta (ažurirano > lastUpdated). Zašto će se to dogoditi? Prilikom postavljanja upita za prvih 100 zapisa, lastUpdated bit će postavljen na “2013-01-10 12:34:56”, a sljedeći će upit imati uvjet (updated > “2013-01-10 12:34:56”). Čak ni ublažavanje uvjeta (ažurirano >= “2013-01-10 12:34:56”) neće pomoći, jer će uređaj tada beskrajno zahtijevati prvih 100 zapisa.

Situacija s istim "ažuriranim" nije tako rijetka. Na primjer, prilikom uvoza podataka iz tekstualna datoteka polje "ažurirano" postavljeno je na NOW(). Uvoz datoteke s tisućama redaka može potrajati manje od sekunde. Također se može dogoditi da će cijeli imenik imati isti "ažuriran".

Da biste to popravili, trebate koristiti neku vrstu polja jela koje bi bilo jedinstveno barem u jednom trenutku ("ažurirano"). Polje “id” je jedinstveno u cijeloj tablici, pa ga dodatno koristite u sinkronizaciji.

Dakle, implementacija ovog pristupa izgleda ovako. Poslužitelj vraća popis poredan prema “updated” i “id”, a uređaji traže podatke pomoću “lastUpdated” i novog parametra “lastId”. Na poslužitelju je uvjet uzorkovanja kompliciraniji: ((ažurirano > lastUpdated) ILI (ažurirano = lastUpdated i id > lastId)).

U dijagramu: “last_updated”, “last_id” i “amount” su vrijednosti koje su pohranjene u mobilnoj aplikaciji. “last_item” – zadnji entitet (jelo) poslan sa servera. Sljedeći popis će biti zatražen noviji od ove vrijednosti.

Pristup 5: Sinkronizacija sa znanjem o tome što je već na uređaju

Prethodni pristupi ne uzimaju u obzir činjenicu da poslužitelj zapravo ne zna koliko su uspješno podaci spremljeni na uređaj. Uređaj možda jednostavno nije spremio neke od podataka zbog neobjašnjivih grešaka. Stoga bi bilo lijepo dobiti potvrdu od uređaja da su sva (ili ne sva) jela spremljena.

Osim toga, korisnik aplikacije može prilagoditi aplikaciju tako da mu treba samo dio podataka. Na primjer, korisnik želi sinkronizirati jela iz samo 2 grada od 10. Gore opisana sinkronizacija to ne može postići.

Ideja pristupa je sljedeća. Poslužitelj pohranjuje informacije o tome koja se jela nalaze na uređaju (u zasebnoj tablici “stored_item_list”). To bi jednostavno mogao biti popis parova "id – ažurirano". Ova tablica pohranjuje sve popise “id – ažurirano” parova jela za sve uređaje.

Uređaj šalje podatke o dostupnim jelima na uređaju (popis parova „id – ažurirano“) na poslužitelj zajedno sa zahtjevom za sinkronizaciju. Prilikom postavljanja zahtjeva poslužitelj provjerava koje posuđe treba biti na uređaju i koje je trenutno dostupno. Razlika se zatim šalje u uređaj.

Kako poslužitelj određuje koje posuđe treba biti na uređaju? U najjednostavnijem slučaju, poslužitelj postavlja zahtjev koji će vratiti popis parova “id – ažurirano” svih jela (na primjer, SELECT id, ažurirano FROM jela). U dijagramu se to radi metodom "WhatShouldBeOnDeviceMethod()". Ovo je nedostatak pristupa - poslužitelj mora izračunati (ponekad postavljajući teške SQL upite) što bi trebalo biti na uređaju.

Kako poslužitelj određuje koje se posuđe nalazi na uređaju? Upituje tablicu "stored_item_list" za ovaj uređaj i prima popis parova "id – ažurirano".

Analizom ova dva popisa poslužitelj odlučuje što treba poslati na uređaj, a što treba izbrisati. U dijagramu je to "delta_item_list". Stoga u zahtjevu nema “lastUpdated” i “lastId”; njihovu zadaću obavljaju parovi “id – updated”.

Kako poslužitelj zna za dostupna jela na uređaju? U zahtjevu prema serveru dodan je novi parametar “items” koji sadrži popis id jela koja su poslana na uređaj u zadnjoj sinkronizaciji (“device_last_stored_item_list”). Naravno, možete poslati popis id-ova svih jela koja se nalaze na uređaju bez kompliciranja algoritma. Ali ako na uređaju ima 3000 jela i sva se šalju svaki put, tada će troškovi prometa biti vrlo visoki. U velikoj većini sinkronizacija, parametar "items" bit će prazan.

Poslužitelj mora stalno ažurirati svoj “stored_item_list” s podacima koji dolaze s uređaja u parametru “items”.

Treba implementirati mehanizam za brisanje podataka poslužitelja u stored_item_list. Na primjer, nakon ponovne instalacije aplikacije na uređaju, poslužitelj će pretpostaviti da su podaci na uređaju još uvijek aktualni. Stoga, kada instalirate aplikaciju, uređaj mora na neki način obavijestiti poslužitelj kako bi izbrisao stored_item_list za ovaj uređaj. U našoj prijavi koju šaljemo dodatni parametar“clearCache” = 1 u ovom slučaju.

Zaključak

Sažeta tablica karakteristika ovih pristupa:

№	Pristup	Količina prometa(5 – veliki)	Složenost razvoja(5 – visoko)	Upotreba memorije uređaja(5 – visoko)	Ispravnost podataka na uređaju(5 – visoko)	Možete odabrati određeni uređaj
1	Sve je uvijek sinkronizirano	5	1	5	5	Ne
2	Sinkronizira se samo ažurirani sadržaj	1	2	5	3	Ne
3	Sinkronizacija u komadima	1	3	1	3	Ne
4	Ispravna sinkronizacija u komadima	1	3	1	3	Ne
5	Sinkronizacija sa znanjem o tome što je već na uređaju	2	5	2	5	Da

“Ispravnost podataka uređaja” je vjerojatnost da uređaj ima sve podatke koje šalje poslužitelj. U slučaju pristupa br. 1 i br. 5, postoji 100% pouzdanost da uređaj ima sve podatke koji su mu potrebni. U drugim slučajevima nema takvog jamstva. To ne znači da se drugi pristupi ne mogu koristiti. Samo što ako se neki od podataka na uređaju izgube, onda to neće biti moguće popraviti s poslužitelja (a kamoli saznati o tome na strani poslužitelja).

Možda, ako imate neograničene internetske tarife i besplatno wifi problem ograničavanje prometa koji generira mobilna aplikacija postat će manje relevantno. Ali za sada moramo pribjegavati svakojakim trikovima kako bismo došli do "pametnijih" pristupa koji mogu smanjiti mrežne troškove i povećati performanse aplikacija. Ovo ne funkcionira uvijek. Ponekad "što jednostavnije to bolje", ovisi o situaciji. Nadam se da ćete u ovom članku pronaći pristup koji će vam biti od koristi.

Postoji iznenađujuće malo opisa sinkronizacije poslužitelja i Mobilni uredaji. Štoviše, postoje mnoge aplikacije koje rade prema ovoj shemi. Par linkova za zainteresirane.

Naša tvrtka nudi usluge izrade serverskog dijela mobilnih poslovnih aplikacija i klijentskih web servisa koji rade u visokoopterećenim okruženjima. Prilikom izrade svakog projekta nastojimo aplicirati individualni pristup tako da dobiveni proizvod postane najviše optimalno rješenje specifične ciljeve kupca.

Ako koristite složenu aplikaciju koja pohranjuje i/ili obrađuje podatke na poslužitelju, tada iza nje postoji Back-end - programski paket, koji se nalazi na web poslužitelju i pokreće aplikaciju, koja se u ovom slučaju naziva Front-end. Aplikacija koja se nalazi na poslužitelju može raditi istovremeno s velikim brojem klijenata, što nameće zahtjeve za velika brzina i sigurnost njegovog rada.

Često je napisana poslužiteljska strana aplikacije PHP jezik, kao najpopularniji za takva rješenja. Može se koristiti za implementaciju jednostavnih zadataka poslužitelja standardni sustavi, no za one specifičnije već je potrebno razviti vlastito rješenje ili dodatke preko standardnih sustava.

Principi razvoja poslužitelja za mobilnu aplikaciju

Naši programeri rade s tehnologijama koje nam omogućuju implementaciju širokog spektra rješenja za bilo koja, čak i vrlo visoka opterećenja i različita područja. Također izrađujemo zasebna poslužiteljska rješenja za pojedinačne zadatke.

Organizacijska kontrola

Svaki projekt kreira zasebna grupa stručnjaka odgovornih za sve faze razvoja i isporuku projekta na vrijeme.

Programiranje

Projektiranje arhitekture poslužitelja najvažniji je korak tijekom kojeg se izrađuju baze podataka i formiraju potrebni algoritmi.

Testiranje

Softverski dio trebao bi raditi bez grešaka ili kvarova. Za to su odgovorni testeri koji provjeravaju sustav.

Tehnička podrška

Naši zaposlenici pružaju punu tehničku podršku za programe, što vam omogućuje brzo uklanjanje nedostataka i ažuriranje.

Značajke razvoja

Kako bi se kompetentno razvila poslužiteljska strana aplikacije, potrebne su određene vještine i poznavanje programskog jezika koji se koristi na poslužitelju. Kao što praksa pokazuje, aplikacije klijent-poslužitelj izrađuju se u PHP-u. On je neosporni lider u ovoj oblasti. Više od polovice web stranica u svijetu napisano je u PHP-u; pogodan je za razvoj i podršku.

Okvir

Ova softverska platforma omogućuje vam da projekt učinite skalabilnijim i fleksibilnijim. Međutim, okvir mora biti odabran što je točnije moguće, stoga je potrebna dubinska analiza radne dokumentacije projekta, koja će kasnije pomoći u razvoju visokokvalitetnog proizvoda.

Postoje i drugi jezici koji se koriste za Back-end razvoj. Na primjer, popularne su poslužiteljske aplikacije izrađene u Delphi okruženju. Zbog toga je program poboljšao otklanjanje pogrešaka. Osim toga, lakše je razviti jedinstvene programe i pruža vizualnu kreaciju. Sve to nam omogućuje stvaranje jasnog i praktičnog sučelja.

Poslužiteljske aplikacije u Javi nisu ništa manje popularne. Mogu se lako nadopunjavati, lako se mogu izvršiti na različitim platformama i imati visoka razina sigurnosti.

Još jedan često korišten jezik. Uz njegovu pomoć, poslužiteljske aplikacije se kreiraju lako, brzo i bez dodatnih troškova.

Skoro sve moderne tvrtke imaju svoje virtualne urede. Web stranica može biti i jedno i drugo poslovna kartica, ili portal ili online katalog s mogućnošću naručivanja.

Poslovni procesi u ovom slučaju ovise o web poslužiteljima, odnosno o njihovoj sposobnosti da izdrže napade, pokušaje hakiranja i vanjskih negativnih utjecaja, kao i o performansama dostatnim za više istovremeno prihvaćenih zahtjeva.

Faze razvoja web servisa

Izradom aplikacija za različite tržišne segmente organiziramo rad prema jedno načelo– cijeli proces dijelimo u zasebne korake, čiji napredak i rezultate komuniciramo s kupcima. Tako je i poslužitelj za mobilnu aplikaciju razvijen na sličan način.

1. Razvoj ideje

Do 2 tjedna

U ovoj fazi stvara se temelj koji daje ideju o tome što će biti postavljeno i u kojem smjeru će se razvijati.

2. Evaluacija projekta

2-3 tjedna

Naši stručnjaci procjenjuju rokove i troškove rada, a zatim sastavljaju preliminarni prijedlog u vezi s razvojem.

3. Projektni zadatak i ugovor

Do 2 tjedna

Nakon razgovora o svim nijansama procesa s kupcem i izrade detaljne tehničke specifikacije, priprema se i potpisuje ugovor.

4. Razvoj sučelja

2-3 tjedna

Dizajneri su odgovorni za stvaranje sučelja potrebnih za pisanje softverskih modula.

6. Ispitivanje

2-3 tjedna

Sveobuhvatnu provjeru dobivenog softverskog rješenja provode testeri pomoću skupa odgovarajućih alata.

7. Završetak projekta

Do 2 tjedna

U dogovorenom roku kupcu se isporučuje gotova, temeljito testirana web usluga.

Naš tim

Analizirajući poslovne aktivnosti i potrebe naših klijenata, stvaramo proizvode koji uistinu rade i pomažu u rješavanju niza poslovnih problema. Korištenje moderne tehnologije nudi širok raspon mogućnosti za implementaciju poslužiteljskog softvera, što jamči visoku izvedbu odgovarajućih mobilnih aplikacija. Naš tim predstavljaju:

Voditelji projekata

Ovi zaposlenici komuniciraju i s klijentima i s programerima, osiguravajući komunikaciju među njima. Oni prate provedbu kako već planiranih radnji tako i potrebnih poboljšanja.

Dizajneri

U svom radu naši stručnjaci uzimaju u obzir zahtjeve za izgradnju sučelja za operacijske dvorane iOS sustavi i Android, tako da objavljene aplikacije ispravno rade na različitim uređajima.

Programeri

Kako bi optimizirali rad mobilnih aplikacija, programeri ih analiziraju Zahtjevi sustava i izraditi specijalizirani poslužiteljski softver.

Testeri

Temeljito testiranje ključ je kvalitete gotovog proizvoda i jamči sigurnost pohranjenih i obrađenih podataka. Ovi stručnjaci koriste različite alate i učinkovite tehnike.

Koje usluge stvaramo?

Biti ugrađen u softver web stranice ili samostalni program, web servis koji služi za obavljanje poslova vezanih uz oglašavanje, analitiku, poslovno planiranje i promociju. S tim u vezi, potrebno je odlučiti koja će vrsta resursa biti optimalno rješenje.

Informacijski projekti

Dizajniran za prilagodbu raznolikog sadržaja.

Tematska mjesta

Gotovo sve njihove stranice posvećene su istoj temi. Potražnja za njima je još uvijek prilično velika.

Stranice s vijestima

Obavještavaju o raznim vijestima unutar jedne ili više tema, odražavajući glavna područja života.

blogovi

Popularnost ovih resursa stalno raste. Poput stranica s vijestima, one prenose ove ili one informacije internetskoj zajednici, ali u ovom slučaju autori izražavaju svoje osobno mišljenje.

Društveni projekti

To uključuje specijalizirane socijalne usluge. mreže, zajednice, forumi itd.

Forumi

Stvoren za raspravu o raznim novostima, proizvodima/uslugama itd. Mogu biti i usko usmjereni i raznoliki.

Društveni mediji

Ti resursi imaju višemilijunsku publiku. Njihova glavna zadaća je pružiti korisnicima Interneta mogućnost online komunikacije putem teksta/ glasovne poruke i video komunikacije.

Razni web servisi

Danas su rašireni, podijeljeni su u nekoliko vrsta.

Katalozi

Poštanske usluge

Pružite korisnicima sve značajke i pogodnosti E-mail, uključujući pregledavanje, slanje, uređivanje pisama i dokumenata itd.

Tražilice

Koristi se za traženje web stranica i razne informacije za određene zahtjeve.

Oglasne ploče

To su web resursi na kojima korisnici mreže objavljuju svoje oglase za kupnju, prodaju i usluge unutar različitih tema.

Hosting stranica

Dizajniran za privremenu pohranu datoteka. Neki od njih pružaju mogućnost pregleda podataka prije preuzimanja.

Pitanja

U nastavku donosimo odgovore na pitanja koja se često postavljaju našim stručnjacima. Ako ovdje ne pronađete informacije koje vas zanimaju, molimo vas da svoje pitanje postavite ovdje. oblik, a mi ćemo svakako odgovoriti.

Koliko dugo može trajati izrada aplikacije i web poslužitelja?

U prosjeku ovaj rad traje od 9 do 20 tjedana. Sve ovisi o složenosti zadatka koji se provodi.

Razvoj poslužiteljskog dijela klijent-poslužiteljske aplikacije započinje projektiranjem arhitekture. Puno ovisi o arhitekturi: od proširivosti aplikacije do njezine izvedbe i jednostavnosti podrške/održavanja.

Prije svega, morate odrediti kako će se podaci postavljati na poslužitelj i kako će se obrađivati zahtjevi koji dolaze od klijenta. Također je potrebno razmotriti organiziranje predmemoriranja podataka poslužitelja.

Potrebno je odlučiti o protokolima razmjene podataka i formatima prijenosa podataka.

API (application programming interface) – sučelje za programiranje aplikacija. Da se izrazimo razumljivijim jezikom, ovo je skup zahtjeva poslužitelju, koje ovaj razumije i može dati točan odgovor. API definira funkcionalnost logike poslužitelja, dok vam API omogućuje apstrahiranje od toga kako je točno ova funkcionalnost implementirana. Drugim riječima, API je neophodan dio cjelokupne infrastrukture klijent-poslužitelj.

Usporedite JSON i XML. Navedite primjere protokola ovisno o vrsti aplikacije.

Višenitnost

Jedan od ključnih aspekata u modernom programiranju je multithreading. Uz pomoć multithreadinga, možemo dodijeliti nekoliko niti u aplikaciji koje će izvoditi razne zadatke istovremeno.

Višenitnost je svojstvo platforme (na primjer, operacijski sustav, virtualni stroj itd.) ili aplikacija, koja se sastoji u činjenici da se proces nastao u operativnom sustavu može sastojati od nekoliko niti koje se izvode "paralelno", to jest bez propisanog redoslijeda u vremenu.

Bit multithreadinga je kvazi-multitasking na razini jednog izvršnog procesa, odnosno sve dretve se izvršavaju u adresnom prostoru procesa. Osim toga, sve niti procesa ne samo da imaju zajednički adresni prostor, već i zajedničke deskriptore datoteka. Proces koji se izvodi ima najmanje jednu (glavnu) nit.

Multithreading (kao programsku doktrinu) ne treba brkati ni s multitaskingom ni s multiprocessingom, iako operacijski sustavi koji implementiraju multitasking obično također implementiraju multithreading.

Prednosti višenitnosti u programiranju uključuju sljedeće:

Pojednostavljenje programa u nekim slučajevima zbog korištenja zajedničkog adresnog prostora.

Manje vremena potrošeno na stvaranje niti u odnosu na proces.

Povećanje performansi procesa paraleliziranjem procesorskih izračuna i I/O operacija.

Teći(nit) je upravljana jedinica izvršnog koda. U višezadaćnom okruženju koje se temelji na nitima, svi pokrenuti procesi moraju imati glavnu nit, ali može ih biti više. To znači da se više zadataka može izvršiti asinkrono u jednom programu. Na primjer, uređivanje teksta u uređivač teksta tijekom ispisa, jer se ova dva zadatka izvode u različitim nitima.

Na tipičnom procesoru, kontrolom niti upravlja operativni sustav. Nit se izvršava dok se ne dogodi hardverski prekid, sistemski poziv ili dok ne istekne vrijeme koje joj je dodijelio operativni sustav. Nakon toga se procesor prebacuje na kod operacijskog sustava koji sprema stanje dretve (njezin kontekst) ili se prebacuje u stanje druge dretve kojoj je također dodijeljeno vrijeme za izvršenje. S takvim multithreadingom, prilično velik broj procesorskih ciklusa se troši na kod operacijskog sustava koji mijenja kontekste. Ako je podrška za niti implementirana u hardveru, tada će se sam procesor moći prebacivati između niti, i, idealno, izvršavati nekoliko niti istovremeno po ciklusu takta.

– Privremeno višenitnost (jedna nit)

– Simultano multithreading (nekoliko niti istovremeno)

Multithreading, naširoko korišten model programiranja i izvođenja koda, omogućuje rad više niti unutar jednog procesa. Ove niti izvršavanja dijele procesne resurse, ali mogu raditi i neovisno. Model višenitnog programiranja pruža programerima prikladnu apstrakciju za paralelno izvođenje. Međutim, možda je najzanimljivija primjena tehnologije kada se primijeni na jedan proces, dopuštajući mu da radi paralelno na višeprocesorskom sustavu.

Ova prednost programa s više niti omogućuje mu brži rad računalni sustavi, koji imaju više procesora, procesor s više jezgri ili na klasteru strojeva - zbog činjenice da su programske niti prirodno pogodne za istinski paralelno izvođenje procesa. U ovom slučaju, programer mora biti vrlo pažljiv kako bi izbjegao uvjete utrke i drugo neintuitivno ponašanje. Kako bi ispravno manipulirali podacima, niti izvršavanja moraju često prolaziti kroz proceduru susreta kako bi obradile podatke ispravnim redoslijedom. Niti izvršenja također mogu zahtijevati mutekse (često implementirane korištenjem semafora) kako bi se spriječilo mijenjanje ili čitanje dijeljenih podataka u isto vrijeme tijekom procesa modifikacije. Nemarno korištenje takvih primitiva može dovesti do zastoja.

Još jedna upotreba višenitnosti, čak i za jednoprocesorske sustave, je sposobnost aplikacije da odgovori na unos. U jednonitnim programima, ako je glavna nit izvršavanja blokirana dugotrajnim zadatkom, cijela aplikacija može završiti u zamrznutom stanju. Premještanjem takvih dugotrajnih zadataka u radnu nit koja se izvodi paralelno s glavnom niti, postaje moguće da aplikacije nastave odgovarati na korisnički unos dok se zadaci izvode u pozadina. S druge strane, u većini slučajeva višenitnost nije jedini način očuvanja osjetljivosti programa. Isto se može postići kroz asinkroni I/O ili signale u UNIX-u.

Postoje dvije vrste multitaskinga: temeljen na procesu I na bazi niti. Razlike između multitaskinga temeljenog na procesima i multitaskinga temeljenog na nitima svode se na sljedeće: multitasking temeljen na procesima organiziran je za paralelno izvođenje programa, a višezadaćnost temeljen na nitima organiziran je za paralelno izvođenje pojedinih dijelova istog programa.

Postoje dvije vrste tokova:

Niti u prvom planu ili prioritet. Prema zadanim postavkama, svaka nit stvorena metodom Thread.Start() automatski postaje nit u prvom planu. Ovaj tip niti osiguravaju da se trenutna aplikacija ne prekine. Zajednički jezik za izvođenje neće zaustaviti aplikaciju dok se sve prioritetne niti ne završe.

Pozadinske niti. Ovaj tip niti, također poznate kao daemon niti, CLR tretira kao proširive staze izvršenja koje se mogu zanemariti u bilo kojem trenutku. Stoga, ako su sve niti u prvom planu prekinute, tada se sve pozadinske niti automatski ukidaju kada se aplikacijska domena oslobodi. Da biste stvorili pozadinske niti, svojstvo IsBackground morate postaviti na true.

Razgovarajte o stanjima niti: pokrenute, obustavljene, pokrenute, ali čekaju nešto.

Problem sinkronizacije niti i zajedničkih resursa.

Interakcija niti

U okruženju s više niti problemi često nastaju kada istodobne niti dijele iste podatke ili uređaje. Za rješavanje takvih problema koriste se metode interakcije niti kao što su muteksi, semafori, kritične sekcije i događaji.

Mutex je sinkronizacijski objekt koji je postavljen na posebno stanje signalizacije kada nije zauzet nijednom niti. Samo jedna nit posjeduje ovaj objekt u bilo kojem trenutku, otuda i naziv takvih objekata (od engleskog uzajamno isključivog pristupa - uzajamno isključiv pristup) - istovremeni pristup zajedničkom resursu je isključen. Nakon što su sve potrebne radnje dovršene, mutex se oslobađa, dopuštajući drugim nitima pristup dijeljenom resursu. Objekt može održavati rekurzivno stjecanje drugi put od strane iste niti, povećavajući brojač bez blokiranja niti i zahtijevajući naknadno otpuštanje više puta. Ovo je, na primjer, kritični odjeljak u Win32. Međutim, postoje i implementacije koje to ne podržavaju i rezultiraju zastojem niti pri pokušaju rekurzivnog snimanja. Ovo je FAST_MUTEX u Windows kernelu.

Semafori predstavljaju raspoložive resurse koje može steći više niti u isto vrijeme dok se skup resursa ne isprazni. Tada dodatne niti moraju čekati dok potrebna količina resursa ponovno ne bude dostupna. Semafori su vrlo učinkoviti jer omogućuju simultani pristup resursima.

Događaji. Objekt koji pohranjuje 1 bit informacije "signalizirano ili ne", nad kojim su definirane operacije "signaliziraj", "resetiraj u nesignalizirano stanje" i "čekaj". Čekanje na signalizirani događaj je izostanak operacije s trenutnim nastavkom izvođenja niti. Čekanje na nesignalizirani događaj uzrokuje da nit obustavi izvršenje dok druga nit (ili druga faza rukovatelja prekidima u jezgri OS-a) ne signalizira događaj. Moguće je čekati nekoliko događaja u modovima “bilo koji” ili “svi”. Također je moguće kreirati događaj koji se automatski vraća u nesignalizirano stanje nakon buđenja prve - i jedine - niti koja čeka (takav objekt se koristi kao osnova za implementaciju objekta "kritične sekcije"). Aktivno se koriste u MS Windowsima, kako u korisničkom načinu rada tako iu načinu rada jezgre. Postoji sličan objekt u Linux kernel pod nazivom kwait_queue.

Kritični dijelovi pružaju sinkronizaciju sličnu muteksima, osim što su objekti koji predstavljaju kritične odjeljke dostupni unutar istog procesa. Događaji, muteksi i semafori također se mogu koristiti u jednoprocesnoj aplikaciji, ali implementacije kritičnih odjeljaka nekih operativnih sustava (kao što je Windows NT) pružaju brži i učinkovitiji mehanizam sinkronizacije koji se međusobno isključuje — "get" i "release" " operacije na kritičnom odjeljku optimizirane su za slučaj jedne niti (bez konkurencije) kako bi se izbjegli bilo kakvi sistemski pozivi koji vode do OS kernela. Poput muteksa, objekt koji predstavlja kritični odjeljak može koristiti samo jedna nit u isto vrijeme, što ih čini iznimno korisnim za ograničavanje pristupa zajedničkim resursima.

Uvjetne varijable(kondvari). Oni su slični događajima, ali nisu objekti koji zauzimaju memoriju - koristi se samo adresa varijable, koncept "sadržaja varijable" ne postoji, adresa proizvoljnog objekta može se koristiti kao uvjetna varijabla. Za razliku od događaja, postavljanje varijable uvjeta u signalizirano stanje nema posljedica ako trenutno nema niti koje čekaju na varijablu. Postavljanje događaja u sličnom slučaju podrazumijeva pohranjivanje "signaliziranog" stanja unutar samog događaja, nakon čega sljedeće niti koje žele čekati događaj nastavljaju izvršavati odmah bez zaustavljanja. Za potpuno korištenje takvog objekta također je neophodna operacija "otpusti mutex i pričekaj varijablu uvjeta atomski". Aktivno se koristi u operacijskim sustavima sličnim UNIX-u. Rasprave o prednostima i nedostacima događaja i varijabli stanja istaknuti su dio rasprava o prednostima i nedostacima Windowsa i UNIX-a.

ulazno-izlazni priključak(IO dovršeni port, IOCP). Implementiran u jezgri OS-a i dostupan putem sistemskih poziva, objekt “queue” s operacijama “stavi strukturu na kraj reda” i “preuzmi sljedeću strukturu s glave reda” - zadnji poziv obustavlja izvršenje niti ako je red čekanja prazan i sve dok druga nit ne izvrši poziv "put". Najvažnija značajka IOCP-a je da se strukture mogu smjestiti u njega ne samo eksplicitnim sistemskim pozivom iz korisničkog načina rada, već implicitno unutar OS kernela kao rezultat dovršetka asinkrone I/O operacije na jednom od deskriptora datoteke. Da biste postigli ovaj učinak, morate koristiti sistemski poziv "pridruži deskriptor datoteke s IOCP". U ovom slučaju, struktura postavljena u red čekanja sadrži šifru pogreške I/O operacije, a također, ako je ova operacija uspješna, broj stvarno unesenih ili izlaznih bajtova. Implementacija priključka dovršetka također ograničava broj niti koje se izvode na jednom procesoru/jezgri nakon primanja strukture iz reda čekanja. Objekt je specifičan za MS Windows i omogućuje obradu dolaznih zahtjeva za povezivanjem i dijelova podataka na poslužitelju softver u arhitekturi gdje broj niti može biti manji od broja klijenata (ne postoji zahtjev za stvaranjem zasebne niti s troškovima resursa za svakog novog klijenta).

Bazen niti

Recite nam nešto o skupu niti