Mobil alkalmazások szerver részének fejlesztése. Mobil alkalmazás fejlesztés: Szinkronizálás a szerverrel Az alkalmazás szerver oldalának fejlesztése

MENTÉSEK

Miért van szükség biztonsági mentésekre mobilplatformon?

A szakértők tudják, hogy az 1C mobilalkalmazások néha mennyire megbízhatatlanok: bármikor előfordulhatnak hibák, amelyek miatt a felhasználói bázisok egyszerűen összeomlanak. Ugyanakkor maguknak az eszközöknek a megbízhatatlanságával is szembesülünk: eltörhetnek, elveszhetnek, ellophatók, a felhasználók meg akarják őrizni adataikat. A 8.3.9-es verzióig pedig nem volt platform biztonsági mentési mechanizmusunk.

Mivel korábban a felhasználóknak nem volt „másolat mentése” gombja, a Boss alkalmazás fejlesztőinek maguknak kellett biztonsági másolatot készíteniük. Hogyan csináltuk?

Az adatbázis adatait XML formátumban mentjük.

Célszerű több lehetőséget kínálni a felhasználónak a másolatok tárolására - először is kényelmes az ügyfelek számára, kiválaszthatják maguknak a legjobb lehetőséget: feltöltik a felhőbe, elküldik a levelükre, elmentik az eszközre.

Így a fejlesztők emellett biztosítják magukat. Ha valami hiba történt, és a Google Drive-on vagy a Yandex Drive-on a másolatok létrehozásának mechanizmusa hirtelen meghibásodott, mindig elmondhatja a felhasználónak, hogy Ebben a pillanatban a fejlesztő foglalkozik a hibával, de egyelőre el tudja menteni az adatokat alternatív módon. A felhasználók pedig elégedettek, mert nyugodtak lehetnek az adataikkal kapcsolatban.

Szükségszerűen összpontosítani kell felhő szolgáltatások , mert ha az eszköz elveszik vagy elromlik, és a felhasználó másolatot mentett ugyanarra az eszközre, akkor az adatok elvesznek.

Mi is ügyeljen arra, hogy emlékeztesse a felhasználót a biztonsági másolatok készítésének szükségességére.

Hogyan lehet másolatokat menteni, ha a konfiguráció megváltozik?

Amikor tömegmegoldásról, folyamatosan változó, fejlődő, fejlődő alkalmazásról beszélünk, figyelembe kell venni a vásárlók viselkedését. Előfordulhat, hogy a felhasználó vissza akar állítani egy mentett biztonsági másolatot régi verzió alkalmazás, ahol nem voltak részletek. És akkor jön a feladat: beolvasni az adatokat, majd kitölteni az adatokat a frissítési logika szerint az alkalmazás régi verziójából. Hogyan kell csinálni? Az adatok mellett mentse el magát az adatstruktúrát is, hogy később tudja, hogyan kell azokat elolvasni.

Számos lehetőség van ennek az adatszerkezetnek a tárolására, beleértve a tárolást magában a konfigurációban. Azaz minden új verzió kiadásával mentse el a metaadat-struktúrát előző verzió konfigurációban való elrendezéshez.

Ne felejtsük el, hogy egy mobilalkalmazásban a konfiguráció nem csak úgy nőhet, értékelnünk kell a benne elfoglalt helyet, a lehető legkompaktabbá kell tenni. De az alkalmazás fejlődik, és sok ilyen elrendezés lesz, és idővel egyre több lesz.

Ezért egy mobilalkalmazás esetében egy másik mód előnyösebb - mentse a metaadat-struktúrát közvetlenül az adatfájlba. Ennek eredményeként egy ilyen fájlt kapunk, ahol először tárolunk néhány segédadatot - konfigurációs verziót, konfigurációs sémát, sorozathatárokat, majd magát a felhasználói adatokat írjuk be. XML formátum. Sőt, a fájl "Kiegészítő adatok" részében más fontos adatokat is tárolhat, amelyeket valamiért nem lehetett XML-be írni.

Felvesszük a fájlba mentett adatsémát, és ez alapján felépítjük az XDTO csomagot a fájl olvasásához. Az adatbázisban létrehozunk egy hasonló objektumot, kitöltjük, frissítéskor befejezési feldolgozást végzünk, és a kész objektumot elmentjük az adatbázisba.

Alább a képen láthat egy tippet, hogyan lehet szépen megírni ezeknek a konfigurációknak az XDTO modelljét. A Boss alkalmazást kiadó cég ezzel kísérletezett, több módot is talált, de a metaadatséma megírásakor csak erre a lehetőségre dőlt be. Az adatfájl megnyitásakor a szokásos strukturált XML olvasható, amely az alkalmazás összes metaadatát felsorolja.

// Konfigurációs séma írása XDTO Model = XDTO Factory.XDTO Model Export("http://v8.1c.ru/8.1/data/enterprise/current-config"); FactoryXDTO.WriteXML(FileUpload, ModelXDTO); // Konfigurációs séma beolvasása ModelXDTO = FactoryXDTO.ReadXML(ReadingXML, FactoryXDTO.Type("http://v8.1c.ru/8.1/xdto","Modell")); Unload Factory = Új XDTO gyár (XDTO modell);

A felhasználó védelme érdekében újra meg kell kérdezni, hogy vissza kell-e állítania a biztonsági másolatot. Lehet, hogy csak kísérletezett és mindenre kattintott a gombokra az alkalmazásban :) És most elveszhetnek az aktuális adatai. Ezért, amikor potenciálisan "veszélyes" cselekvéseket hajtunk végre, mindig tisztázzuk, hogy valóban ezt akarja-e, és ennek hogyan kell megtörténnie. A felhasználónak tisztában kell lennie cselekedeteivel.

Kell lennie egy biztonsági mentési mechanizmusnak, amikor offline megoldásról beszélünk, amikor a felhasználó minden adatát kizárólag mobileszközön tárolja: a felhasználó elveszítheti a készülékét, és akkor az adatok elvesznek. És úgy tűnik, hogy ha az alkalmazás nem működik offline, hanem csatlakozik egy központi szerverhez, akkor a felhasználónak nem lehet ilyen problémája, mert ha az eszköz elveszik, csatlakozik a szerverhez, és megkapja az összes adatát a szerver újra, és minden rendben lesz.

A felhasználók azonban nem mindig úgy használják a biztonsági mentéseket, ahogyan azt elvárjuk tőlük :) Nagyon gyakran használják őket arra, hogy egyszerűen „visszacsatolják” az adatokat. Ez tényleg nagyon furcsa viselkedés, de a felhasználók mobil alkalmazások lusták kitalálni, hol hibázhattak az adatbevitel során, és egyszerűen visszagörgetik az adatokat, és újraindítják az aktuális nap adatait. A Boss alkalmazással végzett munka statisztikáinak elemzése után rájöttünk, hogy ez egy normális gyakorlat, és az ilyen felhasználói viselkedés gyakoribb, mint azt gondoltuk volna.

És ha szinkronizálást használ más eszközökkel, akkor ezt fel kell dolgoznia. Itt több megoldás is létezik:

• szakítsa meg a kapcsolatot a szerverrel, megadva, hogy a rajta lévő adatok a régiek maradjanak, és a másolat csak a felhasználó eszközén kerül visszaállításra;
• jobb, ha a felhasználó hagyja, hogy egyszerre állítson vissza egy másolatot az összes eszközön, miután korábban előírta az ilyen mechanizmusokat.

Itt van még egy pont. Eddig mi magunk mentettük a biztonsági mentéseket, irányítottuk a teljes folyamatot, közvetlenül a kódba fogtuk a felhasználó műveleteit, amikor a „másolat mentése” gombra kattintott. Mindez később feldolgozható. A 8.3.9-es platformon lehetővé vált a biztonsági mentések mentése a platform eszközeivel. A felhasználó pedig a tudtunk nélkül teszi ezt. Ha egy központi adatbázissal szinkronizálnak, akkor egy ilyen forgatókönyvet kell feldolgozni. Valahogy meg kell találnunk a szerverünkön, hogy a felhasználó visszaállított egy korábban elmentett másolatot, és döntést kell adnia neki. Nem engedhetjük meg magunknak, hogy az adatok kiesjenek a szinkronból.

CSERE

Amikor egy mobil platformon egy privát megoldásról beszélünk, akkor általában van olyan ügyfelünk, aki például mobil platformot szeretne használni az értékesítési ügynökei számára, és egy központi adatbázissal adatcserét kérni. Itt minden egyszerű: egy adatbázis, több eszköz, felemeled a szervert, beállítod vele a kommunikációt. Így az eszközök közötti csere problémája könnyen megoldható.

De ha tömeges alkalmazásról beszélünk, ahol sok adatbázis van, amelyek mindegyikének sok felhasználója van, akkor a helyzet bonyolultabbá válik. A felhasználók letöltötték az alkalmazást a piacról, és szinkronizálni szeretnének egymással. Például egy férj letöltött egy személyes pénzügyi alkalmazást, és most azt akarja, hogy a felesége is csatlakozzon, hogy együtt dolgozhassanak ugyanazon az alkalmazáson. Sok a felhasználó, az alkalmazás fejlődik, növekszik, nagy, nagyon nagy számú adatbázisra van szükség. Hogyan lehet mindezt megszervezni? A felhasználók nem fognak személyesen felvenni a kapcsolatot a fejlesztőkkel, hogy külön adatbázist hozzanak létre számukra és lehetővé tegyék a szinkronizálást. Meg akarnak nyomni egy gombot, és azonnal működni akarnak. Ugyanabban a pillanatban.

Hogyan kell eljárni? Itt jön a segítség az adatleválasztási mechanizmus. Lehetővé teszi egyetlen adatbázis megszervezését, ahol egy közös konfiguráció van, ugyanakkor korlátlan számú felhasználói adatbázist tárolunk egy közös adatbázison belül.

A legjobb az egészben, hogy dinamikusan, programozottan, a mi részvételünk nélkül is hozzáadhat felhasználókat. A valóságban a felhasználók egyszerűen rákattintanak a „regisztráció a szerveren” gombra, és minden magától történik: létrejön számára egy személyes adatbázis a szerveren, és azonnal elkezdheti a munkát.

Hogyan kell csinálni? Az első és legegyszerűbb megoldás, ha ezzel a mechanizmussal saját szerveradatbázist írunk. Amikor cégünk elkezdte készíteni a Boss alkalmazást és a benne lévő cseréket, az első verzióban éppen ezt tettük: szerver adatbázist írtunk adatmegosztó mechanizmussal. Minden működött, különösen azért, mert nem volt semmi bonyolult - az alapelválasztó gyakori tulajdonság.

De aztán rájöttünk, hogy újra feltaláltuk a kereket :) Sőt, van egy kész megoldás, és már olyan pillanatokat is figyelembe vesz, amelyekre még nem is gondoltunk. Ez az 1C: Fresh.

A szolgáltatás skálázhatósága itt átgondolt: mit tegyünk, ha sok az adat és adatbázis, hogyan lehet mindezzel együtt növekedni. Itt van egy pillanat az alkotásról biztonsági mentések adatterületek: vagyis nem csak egy közös adatbázisról készítünk biztonsági másolatot, hanem másolatokat is készítünk konkrét felhasználó. Ráadásul az ottani mechanizmus olyan, hogy csak akkor készülnek másolatok, amikor valóban szükség van rájuk. Ha a felhasználó egy hétig nem jelentkezett be az adatbázisba, akkor nem készítünk másolatot neki, mert ott nem változott semmi. A Fresh másik jellemzője, hogy a szolgáltatásnak van egy olyan mechanizmusa, amely csökkenti a szerver terhelését, és ez nagyon fontos, ha sok adatbázisunk van.

Általában véve a Fresh valami új és érdekes számunkra. Lassan próbálunk rájönni, de többnyire csak elégedettek vagyunk a munkájával.

Adatátvitel. Hogyan valósítsuk meg az eszközök közötti megosztáshoz

A platform két mechanizmust kínál - SOAP és http szolgáltatásokat. Itt vannak árnyalatok, hogyan lehet elérni ezeket a szolgáltatásokat, ha az adatmegosztási mechanizmus engedélyezve van. Különösen olyan paramétereket kell hozzáadnia, amelyek jelzik az elérni kívánt tartomány konkrét számát, mivel a platform nem tudja meghatározni, hogy melyik adatbázishoz kell hozzáférni a felhasználónévből. Ezenkívül ugyanaz a felhasználó több adatbázissal is dolgozhat egyetlen adatbázison belül (lásd a képet).

A szolgáltatások terén a Boss alkalmazás azonnali megosztást valósít meg: az egyik felhasználó adja meg az adatokat, a másik pedig megkapja azokat. A mobilalkalmazások felhasználói megszokták, hogy minden azonnal megtörténik, ezért elgondolkodtunk, hogyan jobb szolgáltatást használni - SOAP vagy http. A kapcsolat sebessége kulcsszerepet játszott. http-ben jóval nagyobb a csatlakozási sebesség, és SOAP-on keresztül történő csatlakozáskor nehézkes és sokáig tölthető szolgáltatásleírást kapunk. A platformon van mód a szolgáltatás leírásának tárolására, de a dinamikusan hozzáadott paraméterek miatt nem tudunk WS hivatkozásokat használni. Emellett tapasztalataink szerint kényelmesebb és rugalmasabb a http szolgáltatások elérése.

Tehát a célunk a valós idejű csere megvalósítása. Vagyis igyekszünk nem úgy csinálni, hogy a felhasználónak el kell mennie valahova, rá kell kattintania valami gombra, át kell gondolnia, mennyire naprakészek az adatai, frissítenie kell-e... A felhasználóknak mindig legyenek fent adatok- randizni. Annyira hozzászoktak a hírnökökhöz – az egyik elküldte az adatokat, a másik azonnal megkapta. Minden azonnal megtörténik. Ugyanez vonatkozik az üzlettel kapcsolatos alkalmazásokra is: az egyik eladó befejezte az eladást, a másiknak azonnal látnia kell az aktuális helyzetet, anélkül, hogy bármit tenne.

Ezért a Boss alkalmazás háttérfeladatokat használ a cserékhez. Az adatbázisba való minden adatbevitel után elindul egy háttérfeladat, amely elindítja a cserét. Az első rész az adatok elküldése a szervernek. A többi eszköznek tudnia kell, hogy vannak új adatok. Ehhez PUSH értesítéseket használunk. Ez a rendszer már működik, és elég gyorsan működik.

De még gyorsabbat akartunk, mert valós időben dolgozunk, és általában kevés adatunk van. Kis XML-ünk van, ugyanakkor az első eszközről üzenetet küldünk ezekkel az adatokkal a szerver felé, a szerver PUSH-t küld egy másik eszközre, majd a második eszköz, miután megkapta a PUSH-t, kezdeményezi a cserét a maga részéről, hozzáfér a szerverhez és adatokat kér, fogadja ezeket az adatokat, majd választ küld, hogy az adatok megérkeztek. Ez hosszú idő, de maga nagyon kevés adat volt.

Gondolkodtunk azon, hogyan lehetne ezt a folyamatot felgyorsítani.

Ehhez kitaláltuk, hogy a PUSH mit tartalmaz, hogyan használható még. Kiderült, hogy a PUSH olyan mezőket tartalmaz, mint az adatok és a szöveg. Az iOS és Android dokumentációja jelzi a PUSH üzenetek méretének korlátait, de nekünk úgy tűnt, hogy ez nem elég, mi magunk akartuk kitalálni. És ellenőriztük, hogy iOS esetén az engedélyezett karakterek összege 981 karakter, Android esetén pedig 3832 karakter. Utóbbi esetben teljesen lehetséges a korlátozás alkalmazása, egy vagy több alapobjektum tolható egy ilyen kötetbe. Aztán a cég fejlesztői egy kicsit változtattak a sémán. Ha kevés az adat, egy eszközről küldjük, fogadjuk a szerveren, PUSH-ba csomagoljuk és közvetlenül egy másik eszközre küldjük. A program rövidebb lett, a csere pedig még gyorsabb lett :)

A PUSH használatának fontos pontja, hogy nem zavarja a felhasználókat.

Ezt a helyzetet nagyon könnyű megszabadulni: csak ne küldj sok PUSH üzenetet a felhasználónak :) Ha éppen az alkalmazásban dolgozik, akkor sok üzenetet küldhetsz. Amikor a platform fut, a felhasználó nem látja a PUSH-t, minden automatikusan történik számára. De amikor az alkalmazás be van zárva, az ügyfélnek sok olvasatlan üzenete van. Ezért semmi esetre se küldje el a következő PUSH-t, amíg nem érkezik válasz az eszköztől, hogy az alkalmazás fut, aktív és az előző PUSH-t már feldolgozták.

A csere másik árnyalata a weben keresztüli munka. Amennyire csak lehetséges, használnunk kell az aszinkront. Nem tud a szokásos módon dolgozni - írjon kódot - hívjon meg egy függvényt - várja meg, amíg végrehajtja - választ kap - és minden rendben van. Ha az interneten keresztül dolgozik, akkor is találkozhat bizonyos korlátozásokkal, például instabil internettel, időtúllépésekkel a hosszú műveletek végrehajtása során. Ezért előre át kell gondolni az építészetet.

Nézzük meg az eszközregisztráció példáját, mi történik az alkalmazásban, amikor a felhasználó regisztrálni akar. Egy ideig nyilvántartja, sok adatot beírt, de utána szeretné, ha az eladó is ezzel az adatbázissal dolgozna. A felhasználó rákattint a „regisztráció” gombra. Eleinte minden nagyon egyszerű volt: elvették az adatait, rögzítették a szerveren, és kérem, dolgozzon és csatlakozzon a felhasználókhoz. Ekkor azonban belefutottunk abba a helyzetbe, hogy egyes felhasználók számára a készülék adatbázisai már a regisztráció idejére nagyon megnőttek. És ez a séma már nem működött, mert. miközben a teljes adatbázis rögzítve volt a szerveren, a kapcsolat időtúllépése kiváltott, vagy egyszerűen megszakadt az internet. Ezért egy szinkronhívást sok rövid hívással helyettesítettünk. Az adatok most megosztásra kerülnek, nem pedig egyszerre. Semmi esetre sem várjuk meg, amíg a szerver feldolgozza és kiírja az adatokat. Elküldtük az adatokat, azt a választ kaptuk, hogy megérkezett az adat, lezártuk a kapcsolatot. Időnként le kell kérni a szervert, hogy mi történik ott és hogyan, és közben fut egy háttérfeladat a szerveren, ami kiírja a kapott adatokat. Ez sok szerverhívást eredményez, de garanciát vállalunk rá, hogy minden rendben lesz. És sem az időtúllépések, sem az Internet instabilitása nem akadályozza meg, hogy minden adatot feltöltsön a szerverre.

FRISSÍTÉSEK

Megosztás különböző alkalmazásverziójú eszközök között

Mivel tömeges alkalmazásról beszélünk, amely piacra kerül, ezért figyelembe kell venni a frissítési és adatcsere folyamat néhány jellemzőjét.

Ha kiadott egy alkalmazást egy vállalat számára, és úgy dönt, hogy frissíti, akkor általában csak azt a parancsot adja, hogy minden alkalmazott egyhangúlag telepítse az új alkalmazást. Azokkal a felhasználókkal, akik a piacról töltötték le az alkalmazást, ezt nem lehet megtenni. Egyáltalán nem mondhatja meg nekik, mit tegyenek. Például dolgoznak az alkalmazásban, és nem akarják frissíteni sem most, sem soha. Nincs bennük automatikus frissítés, így elég gyakori, hogy több eszköz is csatlakozik a központi adatbázishoz, és mindegyik más-más verzióval. A jelenség másik oka a piacokon a megjelenési idő: ez iOS és Android esetében eltérő. Gyakran kulcsfontosságú dolgokat hajtunk végre, például a javítást kritikus hibák, és nem akarja megvárni, amíg az iOS két hetet ellenőriz új verzió, azt szeretnénk, hogy legalább az Android számára elérhető legyen, de most azonnal kiad egy frissítést.

Nincs jogunk parancsolni a felhasználóknak. Ha akarnak, frissítenek, ha nem, akkor nem tesznek semmit. A képen a Boss alkalmazás telepítéseinek aránya a GooglePlay verziói szerint, valamint a szerverünkről származó statisztikák láthatók – az alkalmazások azon verzióinak valós aránya, amelyek az elmúlt héten adatot cseréltek a szerverrel a szerverrel. Itt van egy készlet, amellyel dolgozni kell. azt különböző verziókés különféle metaadatokat. És egyúttal rendes cserét is kell szervezni :)

A fejlesztőknek a következő feladatokkal kell szembenézniük:

• Mindennek működnie kell. A felhasználóknak nem kell rosszul érezniük magukat, ha elfelejtenek frissíteni. Egyáltalán nem szabad észrevenniük. Frissítve - jobb lett, nos, jó.
• Biztosítanunk kell az adatok biztonságát. Például az egyik felhasználónak van könyvtára és új attribútuma, míg egy másiknak még nincs. Sőt, ha egy felhasználó, aki nem rendelkezik új adatokkal, valamit megváltoztat az eszközén, akkor a többi eszközön lévő adatok nem vesznek el.
• Gondoskodni kell arról, hogy az adatok frissüljenek, amikor új verzióra váltunk. Amikor a felhasználó úgy dönt, hogy készen áll a frissítésre, automatikusan rendelkeznie kell minden új információval, amivel csak azért nem rendelkezett, mert megvolt a régi verzió.

Hogyan csináltuk?

1. A szerveren 2 cseretervet használunk. Az első az eszközök közötti megosztásra, a második pedig a frissítésekre szolgál. Pl. küldtünk egy könyvtárat a felhasználónak, de abban nincsenek mértékegységek, vagyis hiányos adatok. Ezt emlékeznünk kell. És amikor frissítik, el kell küldenünk neki minden olyan információt, amivel nem rendelkezett. Ehhez egy második cseretervre van szükség.

2. Az objektumok írásához és olvasásához ugyanazt a mechanizmust használjuk, mint a biztonsági mentéseknél, vagyis mentjük a metaadat verziót. Ebben az esetben a szerverrel dolgozunk, és megengedhetjük magunknak, hogy bármit közvetlenül hozzáadjunk a konfigurációhoz, így egyszerűen csak metaadat-sémákat adunk hozzá a konfigurációhoz elrendezések formájában, ahogy az alkalmazás fejlődik.

Hogyan lehet nyomon követni a hatalmas hibákat a központban és a szerveren

Először is ellenőriznie kell magának a szervernek az elérhetőségét. A szerverekkel ez történik – esnek. Nem találtunk ki semmi különöset a megfigyeléshez, hanem egyszerűen találtunk egy botot a táviratban, amely sikoltoz, ha valami baj van. Percenként ellenőrzi a szerver teljesítményét, és ha hirtelen nem elérhető a szerver, akkor üvöltözni kezd, ezt látják az adminok és felemelik a szervert.

A naplóból hibanaplót is gyűjtünk. Szintén semmi természetfeletti – csak háromóránként gyűjtünk egy hibanaplót, elküldjük e-mailben, és rendszeresen ellenőrizzük. Segít látni gyakori problémákés néhány kivételes helyzet. Nem nehéz megtekinteni a leveleket, nyomon követni és gyorsan kijavítani a hibákat. Ez azonban lehetővé teszi a problémák gyors azonosítását és megoldását, amelyek az adatbázisok növekedésével növekedhetnek.

Több fontos pont- mindenképpen adjunk lehetőséget a felhasználónak a „panaszra”. Ez javítja a helyzetünket az ő szemükben, és megment minket. Vannak felhasználók, ahogy mi hívjuk "hisztériás", akik a legkisebb tévedésre elkezdenek küldeni nekünk egy csomó üzenetet levélben, hogy semmi sem működik, az adatbázis nem töltődik be, minden rettenetesen rossz. De néha tényleg megmentenek minket, mert néha olyan hibákat találnak, amelyeket a többiek még csodával határos módon nem fedeztek fel, komoly hibákat.

A felhasználónak nem szabad megijednie. Nincsenek ijesztő üzenetek, semmi más. Mindent szépen el kell magyarázniuk, és fel kell ajánlaniuk a panaszt. És megígérjük, hogy mindent megoldunk. Aztán a felhasználók elégedettek, mert látják, hogy gondoskodnak róluk, és azonnal elhiszik, hogy segíteni fognak :)

Ez a cikk az INFOSTART EVENT 2016 DEVELOPER konferencián felolvasott jelentés eredményeit követően készült. További cikkek olvashatók.

2020-ban mindenkit meghívunk 7 regionális találkozóra, valamint a jubileumi INFOSTART EVENT 2020 moszkvai rendezvényre.

Az alkalmazás szerver oldalának fejlesztése

Bevezetés

Az internetes jelenlét a modern vállalatok számára elengedhetetlenné vált. E nélkül lehetetlen teljes értékű interakciót kialakítani az ügyfelekkel. Egy ilyen probléma megoldásához gyakran kliens-szerver alkalmazások létrehozásához folyamodnak. Mindegyik a kliens részből és a háttérből áll. Az utolsó kifejezés az alkalmazás szerveroldalára utal. Ha a jövőben magának kell módosítania a tartalmat mobil program, akkor a Back-endet különösen jó minőségben kell elkészíteni. Az Appomart garantálja a rábízott feladatok követelményeknek megfelelő teljesítését. Ezért, amikor megrendeli a szerveralkalmazások létrehozását, biztos lehet a megfelelő eredményben.

Mire való a Back-end?

A kliens-szerver alkalmazások fejlesztése két részből áll. Az első, a Front-end fogadja a felhasználók kéréseit. A képernyőkről látható mobil eszközökügyfelek. A második, a szerveralkalmazás feldolgozza a beérkezett kéréseket, és adminisztrációs panelként működik. Itt tároljuk az adatbázisokat és a programlogikát. E nélkül egyetlen kliens-szerver alkalmazás sem fog működni. Valójában a háttér a program szíve. Ez az intelligencia, amely felelős az ügyfelek kérésének feldolgozásáért, az alkalmazás sebességéért. Ezért fontos, hogy a szerveralkalmazás architektúrája a legapróbb részletekig átgondolt legyen, hogy még a magasan terhelt szolgáltatások is zökkenőmentesen és gyorsan működjenek.

Hogyan válasszunk programozási nyelvet?

Előkészületben feladatmeghatározás(a projekt munkadokumentációjának részei), az építész megtervezi az adatbázis-rendszert és a hivatkozásokat, ismerteti az objektumokat és tulajdonságaikat, valamint kidolgozza a szükséges szerver módszereket (kéri, hogy a mobilalkalmazások „használjanak” a szerverrel való kapcsolatfelvételkor).

A dokumentáció és az elhagyott projektek jelentősége

Az Appomarttal meglehetősen gyakran fordulnak meg olyan ügyfelek, akiket más vállalkozók ilyen vagy olyan okból "elhagytak". Valaki más, esetenként hibásan működő projektjét pedig átvesszük, annak ellenőrzését, majd az azt követő felülvizsgálatot, támogatást elvégezzük. A tanulás folyamatában forráskódés a megrendelőtől kapott anyagokat, azzal a ténnyel szembesülünk, hogy sok fejlesztő szándékosan nem dokumentálja a szerver metódusait, hogy magához köthesse az ügyfelet, a projekt másik fejlesztő támogatására történő áthelyezésének munkaerőköltségei összemérhetetlensége miatt. a szerver rész dokumentációjának hiányára, és néha egyszerűen a szakszerűtlenség miatt. Ez a tény sajnos nemcsak szomorú, hanem széles körben elterjedt is. A megrendelőnek ebben az esetben fizetnie kell egy meglévő projekt dokumentációjának kidolgozásáért, valamint a forráskód auditálásáért, mielőtt megítélhetővé válik a projekt támogatásának hatékonysága, kényelme és célszerűsége. Az Appomart a Postman és a Swagger által támogatott formátumban karbantartja a háttérmódszerek elektronikus dokumentációját későbbi felhasználás céljából.

Hogyan ellenőrizhető a vállalkozó a szerződés aláírása előtt?

Javasoljuk, hogy körültekintően válasszon kivitelezőt, és ne csak a csábító árra koncentráljon, hanem a projekttel együtt kapott dokumentumok listájára, valamint a forráskód átvitelének és a kód lefedésének feltételeire is. megjegyzések, adatbázissémák (legyen az Mongo DB vagy MySQL ). A siker kulcsa általában az illetékes munkadokumentáció, amely egyértelműen jelzi az Ön számára átadott anyagok követelményeit a munka egyes szakaszainak befejezése után.

Fejlesztési jellemzők

PHP a hátsó részhez

Az alkalmazások szerveroldalának létrehozása (nem tévesztendő össze a szerverekkel, mint "hardverekkel" vagy számítógépekkel, hiszen szoftveres oldalról beszélünk) speciális szakmai ismereteket és a szerver oldalon használt programozási nyelv ismeretét igényli. Ha a kliens-szerver alkalmazások példáit nézzük, láthatjuk, hogy a PHP népszerű. Vitathatatlanul vezető szerepet tölt be a szerveralkalmazások fejlesztésében. A világ webhelyeinek több mint fele ezen a nyelven készült ilyen vagy olyan konfigurációban. A PHP könnyen fejleszthető és karbantartható, emellett speciális keretrendszerek is felgyorsítják a PHP fejlesztését.

Keretrendszer

Framework (szoftverplatform) - az absztrakció szintjének szervezésére és növelésére szolgál, ami rugalmasabbá és skálázhatóbbá teszi a projektet. Meg kell azonban érteni, hogy a keretet helyesen kell kiválasztani, a projekt munkadokumentációjának mélyreható elemzése alapján, amely nélkül lehetetlen minőségi terméket fejleszteni.

Delphi, JAVA, Python

Vannak más nyelvek is, amelyeket a háttér létrehozásához használnak. Tehát létrehozva Delphi környezet szerver alkalmazások. Segítségével a program továbbfejlesztett hibakeresést kap, könnyen egyedi programokat készíthet a környezetben, vizuális alkotás biztosított, amely lehetővé teszi egy szép, érthető és kényelmes felület készítését. A Java szerver alkalmazások is egyre népszerűbbek. Ezek könnyen kiegészíthetők, könnyen végrehajthatók bármilyen platformon, és megfelelő biztonsági szinttel rendelkeznek. Egy másik népszerű nyelv a Python. Segítségével a szerveralkalmazások gyorsan, egyszerűen, komoly költségek nélkül készülnek.

Terítés

A kliens-szerver alkalmazások létrehozása igényes a vállalati környezetben. Az ilyen programokat gyakran munkacsoportokhoz vagy létrehozáshoz használják információs rendszerek a vállalkozáson belül. Az ügyféllel való kommunikációt fenntartó mobilalkalmazások túlnyomó többsége is hasonló architektúrával rendelkezik. A népszerűség annak a ténynek köszönhető, hogy a szerver képességeinek használata lehetővé teszi a rendszer vezérlésének és integritásának biztosítását, miközben csökkenti a hálózati terhelést.

Kiváló minőségben és időben készítünk kliens-szerver alkalmazást Androidra, iOS-re

Kulcsrakész fejlesztés

Az Appomart programozói tapasztaltak és képzettek különböző szintű feladatok végrehajtására. Egyaránt jók vagyunk a közösségi hálózatok, a nagy terhelésű üzleti projektek megvalósításában vagy a kis startupok szoftveres részének megvalósításában. alatti alkalmazás kliens részét szükség esetén elkészítjük Android vezérlés, iOS a meglévő igények, követelmények szerint.

Háttér az Appomartnál

Programozóink különböző technológiákkal dolgoznak és egyformán jól csinálják. Az Appomartnál megrendelhet kliens-szerver alkalmazást Java, PHP és Node.JS nyelven. A rendszerkövetelményeket minden projekthez külön-külön elemezzük, ami lehetővé teszi a program optimális teljesítményének biztosítását. Java, PHP és Node.JS kliens-szerver alkalmazást készítünk a semmiből, vagy egy meglévőt átveszünk a fejlesztések és frissítések támogatására. Ha érdekli egy új szerverrész fejlesztése vagy egy meglévő támogatása, kérjen egy részletes kalkulációt a munka költségéről és az együttműködési lehetőségekről.

Jelentős része a modern alkalmazások mobil platformokhoz(iOS, Android stb.) a szerverrel párhuzamosan működik. Az elavult adatokkal rendelkező alkalmazás elveszti hasznosságát. Ezért fontos gondoskodni arról, hogy a szerverről az eszközre érkező adatok folyamatosan frissüljenek. Ez azokra az offline alkalmazásokra vonatkozik, amelyeknek internet nélkül kell működniük. Teljesen online alkalmazások, amelyek internet nélkül nem működnek (vagy használhatatlanok) (például Foursquare, Facebook) megvannak a maguk sajátosságai, amelyek túlmutatnak jelen cikk keretein.

Példaként az egyik offline alkalmazásunk segítségével elmondom, milyen megközelítéseket használtunk az adatok szinkronizálására. Az első verziókban fejlesztettünk egyszerű algoritmusokat, és a jövőben a tapasztalatok birtokában továbbfejlesztettük őket. Hasonló sorrendet mutat be a cikk - az egyszerű nyilvánvaló gyakorlatoktól a bonyolultabbakig.

Tisztázni kell, hogy a cikk csak egy irányban foglalkozik az adatátvitellel: a szervertől az eszközig. Itt a szerver az adatforrás.

Általános rendelkezések minden megközelítésre

Például megfontoljuk egy edénykönyvtár („tálak”) átvitelét a készülékre. Feltételezzük, hogy az eszköz kérést küld a „/service/dishes/update” URL-re, a csere a http protokollon keresztül történik JSON formátumban ( www.json.org). A szerveren van egy „tányérok” táblája a következő mezőkkel: id (rekordazonosító), név (étel neve), frissítve (tányér frissítési ideje, jobb, ha azonnal támogatja az időzónát, „ÉÉÉÉ-HH-DDThh:mm:ssTZD”, például „1997 -07-16T19:20:30+01:00”), is_deleted (törölt bejegyzés jele).

Megjegyzés az utolsó mező meglétére vonatkozóan. Alapértelmezés szerint az értéke 0. Azokban az alkalmazásokban, ahol entitások szinkronizálva vannak a kliens és a szerver között, nem ajánlott fizikailag törölni az adatokat a szerverről (hogy ne legyenek hibák). Ezért a törölt ételeknél az is_deleted = 1. Amikor egy is_deleted = 1 értékű entitás érkezik az eszközre, az törlődik az eszközről.

Bármilyen megközelítéssel, amelyet alább tárgyalunk, a szerver visszatér az eszközökhöz json tömb objektumok (lehet üres):

[
(azonosító: ,név: .frissítve: ,törölve: },…
]

Példa a szerverre adott válaszra:

[
(azonosító: 5625,név: "Bread",frissítve: "2013-01-06 06:23:12",törölve: 0),
(azonosító: 23,név: "főtt búzadara",frissítve: "2013-02-01 14:44:21",törölve: 0),(

név: "Halászlé",

frissítve: "2013-08-02 07:05:19",

Az eszközön lévő adatok frissítésének elvei

1. Ha olyan elem érkezett, amely az eszközön van, és isDeleted = 0, akkor az frissül
2. Ha olyan elem érkezett, amely nincs az eszközön, és isDeleted = 0, akkor hozzáadódik
3. Ha olyan elem érkezett, amely az eszközön van és törölve = 1, akkor az törlődik
4. Ha olyan elem érkezik, amely nincs az eszközön, és törölve = 1, akkor nem történik semmi

1. megközelítés: Mindig szinkronizáljon mindent

Ez a legegyszerűbb módszer. A készülék az ételek listáját kéri a szervertől, a szerver pedig elküldi a teljes listát. A teljes lista minden alkalommal előkerül. Nincs válogatva.

Példa kérésre: null vagy "()"

Előnyök:

• a szerver logikája egyszerű – mindig mindent megadunk
• az eszköz logikája egyszerű - mindig mindent felülírunk

Hibák:

• ha gyakran (10 percenként) kéred a listát, akkor nagy lesz az internet forgalom
• ha ritkán (naponta egyszer) kéri a listát, akkor az adatok relevanciája sérül

Alkalmazási terület:

• alacsony forgalmú alkalmazásokhoz
• nagyon ritkán változó adatok továbbítása (városok listája, kategóriák)
• alkalmazásbeállítások átvitele
• a legelső mobilalkalmazás prototípus projektjének kezdetén

2. megközelítés: Csak frissítve

A készülék kéri az előző szinkronizálásból frissített ételek listáját. A lista „frissítés” szerint van rendezve, növekvő sorrendben (nem kötelező, de praktikus). A készülék eltárolja a legutóbb küldött étel „frissített” értékét, és a következő kérésnél a „lastUpdated” paraméterben elküldi a szervernek. A szerver elküldi a „lastUpdated”-nél újabb ételek listáját (frissítve > lastUpdated). A szerverhez intézett első kéréskor a „lastUpdated” = null.

Példa kérésre: ( utolsó frissítés: „2013-01-01 00:00:00” )

Az ábrán: „last_updated” az eszközön tárolt érték. Általában egy külön táblázat jön létre az eszközön, amely tárolja ezeket a „last_updated” értékeket minden entitáshoz (ételek, városok, szervezetek stb.)

Ez a megközelítés alkalmas egyszerű lineáris listák szinkronizálására, amelyek minden eszközre azonos érkezési szabályokkal rendelkeznek. A szelektívebb szinkronizáláshoz lásd: 5. megközelítés: Szinkronizálás annak tudatában, hogy mi van már az eszközön.

Általában ez a megközelítés a legtöbb igényt lefedi. Csak új adatok érkeznek a készülékre, minimum percenként lehet szinkronizálni – kicsi lesz a forgalom. Vannak azonban problémák a mobileszközök korlátaival kapcsolatban. Ezek a memória és a processzor.

3. megközelítés: Szinkronizálás darabokban

A mobil eszközök kevés véletlen hozzáférésű memória. Ha 3000 tál található a könyvtárban, akkor egy nagy json karakterlánc elemzése a szerverről az eszköz objektumaiba memóriahiányt okozhat. Ebben az esetben az alkalmazás vagy összeomlik, vagy nem menti a 3000 ételt. De még ha az eszköz képes is megemészteni egy ilyen karakterláncot, akkor az alkalmazás teljesítménye a háttérben történő szinkronizálás pillanataiban alacsony lesz (interfész késések, nem sima görgetés stb.) Ezért szükséges kérni a listát kisebb adagokban.

Ehhez a készülék egy másik paramétert („amount”) ad át, amely meghatározza az adag méretét. A lista szükségszerűen a „frissített” mező szerint, növekvő sorrendben kerül elküldésre. Az eszköz az előző megközelítéshez hasonlóan megjegyzi az utoljára elküldött entitás „frissített” értékét, és átadja a „lastUpdated” mezőnek. Ha a szerver pontosan ugyanannyi entitást küldött, akkor az eszköz folytatja a szinkronizálást, és újra kérést küld, de a frissített „lastUpdated”-vel. Ha a szerver kevesebb entitást küldött, az azt jelenti, hogy nincs több új adata, és a szinkronizálás véget ér.

A diagramon: „utolsó_frissítés” és „összeg” azok az értékek, amelyekben tárolva van mobilos alkalmazás. „last_item” – a szerverről küldött utolsó entitás (tányér). Újabb ennél az értéknél, hogy a következő lista kerüljön lekérésre.

Példa kérésre: ( utolsó frissítés: „2013-01-01 00:00:00”, összeg: 100 )

Előnyök:

• A készülék annyi adatot fogad, amennyit egyszerre képes feldolgozni. Gyakorló tesztekkel meghatározott adagméret. Az egyszerű entitások egyszerre 1000 szinkronizálhatók. De az is előfordul, hogy entitások nagy mennyiség mezők és összetett tárolási feldolgozási logika szinkronizálása általában legfeljebb 5 darab.

Hibák:

• Ha 250 edény van ugyanazzal a frissítéssel, akkor mennyiség = 100 esetén az utolsó 150 nem kerül kiszállításra a készülékekre. Ez a helyzet meglehetősen valós, és a következő megközelítésben ismertetjük.

4. megközelítés: A darabok helyes időzítése

Az előző megközelítésben előfordulhat, hogy ha 250 étel van az asztalon ugyanazzal a „frissítéssel” (például „2013-01-10 12:34:56”) és az adag mérete 100, akkor csak a jön az első 100 lemez. A fennmaradó 150-et egy kemény állapot (frissítve > lastUpdated) levágja. Miért fog ez megtörténni? Az első 100 rekord lekérdezésekor a lastUpdated értéke „2013-01-10 12:34:56”, a következő lekérdezés feltétele pedig (frissítve > „2013-01-10 12:34:56”). Még a feltétel lágyítása sem segít (frissítve >= “2013-01-10 12:34:56”), mert a készülék ezután vég nélkül kéri az első 100 rekordot.

A helyzet ugyanazzal a „frissítéssel” nem olyan ritka. Például amikor adatokat importál innen szöveges fájl a "frissített" mező NOW() értékre lett állítva. A több ezer sorból álló fájl importálása kevesebb mint egy másodpercet vesz igénybe. Az is megtörténhet, hogy a teljes könyvtárban ugyanaz a „frissítés” lesz.

Ennek kijavításához olyan edénymezőt kell használnia, amely legalább egy pillanaton belül egyedi lesz („frissítve”). Az „id” mező az egész táblázatban egyedi, ezért érdemes a szinkronizáláshoz is használni.

Összefoglalva, ennek a megközelítésnek a megvalósítása a következőképpen néz ki. A szerver „updated” és „id” szerint rendezett listát ad vissza, és az eszközök a „lastUpdated” és az új „lastId” paraméter használatával kérnek adatokat. A szerver számára a kiválasztási feltétel bonyolultabbá válik: ((frissítve > lastUpdated) VAGY (frissítve = lastUpdated és id > lastId)).

A diagramon: „last_updated”, „last_id” és „amount” a mobilalkalmazásban tárolt értékek. „last_item” – a szerverről küldött utolsó entitás (tányér). Újabb ennél az értéknél, hogy a következő lista kerüljön lekérésre.

5. megközelítés: Szinkronizálás a már az eszközön lévő dolgok ismeretével

A korábbi megközelítések nem veszik figyelembe azt a tényt, hogy a szerver nem igazán tudja, milyen sikeresen tárolták az adatokat az eszközön. Az eszköz egyszerűen nem tudta menteni az adatok egy részét megmagyarázhatatlan hibák miatt. Ezért jó lenne visszaigazolást kapni a készüléktől, hogy minden (vagy nem az összes) edény megőrződött.

Ezenkívül az alkalmazás felhasználója beállíthatja az alkalmazást úgy, hogy az adatoknak csak egy részére van szüksége. Például egy felhasználó 10 városból csak 2 város ételeit szeretné szinkronizálni. Ez a fent leírt szinkronizálásokkal nem érhető el.

A megközelítés mögött meghúzódó gondolat a következő. A szerver tárolja (egy külön táblázatban a „tárolt_elemek listája”) információkat arról, hogy milyen ételek vannak az eszközön. Ez lehet csak az „azonosító – frissített” párok listája. Ez a táblázat az összes eszközhöz tartozó „azonosító – frissített” ételpárok összes listáját tárolja.

A készülék információkat küld az eszközön elérhető ételekről (az „id – frissített” párok listáját) a szervernek egy szinkronizálási kéréssel együtt. Kérésre a szerver ellenőrzi, hogy mely ételek legyenek a készüléken, és melyek azok, amelyek jelenleg elérhetők. Ezt követően a különbözet ​​elküldésre kerül az eszközre.

Hogyan határozza meg a szerver, hogy mely ételek legyenek az eszközön? A legegyszerűbb esetben a szerver egy kérést küld, amely az összes étel „azonosító - frissített” párjainak listáját adja vissza (például SELECT id, frissített FROM ételek). A diagramban ez a „WhatShouldBeOnDeviceMethod()” metódussal történik. Ez a megközelítés hátránya - a szervernek ki kell számítania (néha nehéz sql lekérdezéseket hajt végre), hogy mi legyen az eszközön.

Hogyan határozza meg a szerver, hogy milyen edények vannak az eszközön? Lekérdezi az eszköz "stored_item_list" tábláját, és megkapja az "id - frissített" párok listáját.

E két lista elemzésével a szerver eldönti, hogy mit küldjön az eszközre és mit töröljön. A diagramban ez a „delta_item_list”. Ezért a kérésben nincs „lastUpdated” és „lastId”, feladatukat „id - updated” párok látják el.

Honnan tud a szerver a készüléken elérhető ételekről? A szerverhez intézett kéréshez egy új „elemek” paraméter kerül hozzáadásra, amely tartalmazza azon azonosítóelemek listáját, amelyeket a legutóbbi szinkronizálás során küldtek az eszközre („device_last_stored_item_list”). Természetesen elküldheti az eszközön lévő összes étel azonosítójának listáját, és nem bonyolítja az algoritmust. De ha 3000 edény van a készüléken és minden alkalommal elküldik, akkor nagyon magasak lesznek a forgalmi költségek. A szinkronizálások túlnyomó többségében az „elemek” paraméter üres lesz.

A szervernek folyamatosan frissítenie kell a „tárolt_elemek_listáját” az „elemek” paraméterben az eszközről származó adatokkal.

Meg kell valósítania egy mechanizmust a szerveradatok törlésére a stored_item_list listában. Például egy alkalmazás újratelepítése után a szerver feltételezi, hogy az adatok még mindig naprakészek az eszközön. Ezért az alkalmazás telepítésekor az eszköznek valamilyen módon tájékoztatnia kell a szervert, hogy az törölje a tárolt_elem_listát az eszközhöz. Pályázatunkban elküldjük további paraméter"clearCache" = 1 ebben az esetben.

Következtetés

Összefoglaló táblázat e megközelítések jellemzőiről:

№	Megközelítés	Forgalom nagysága(5 - nagy)	A fejlesztés munkaintenzitása(5 - magas)	Eszköz memóriahasználata(5 - magas)	Az eszközön lévő adatok helyessége(5 - magas)	Kiválaszthat egy adott eszközt
1	Mindig minden szinkronban van	5	1	5	5	Nem
2	Csak szinkronizált frissítve	1	2	5	3	Nem
3	Szinkronizálás darabokban	1	3	1	3	Nem
4	Helyes szinkronizálás darabokban	1	3	1	3	Nem
5	Szinkronizálás az eszközön lévő dolgok ismeretével	2	5	2	5	Igen

Az „adathelyesség az eszközön” annak a valószínűsége, hogy az eszköz rendelkezik a szerver által küldött összes adattal. Az 1-es és 5-ös megközelítés esetén 100%-os bizonyosság van arról, hogy az eszköz rendelkezik minden szükséges adattal. Ellenkező esetben nincs ilyen garancia. Ez nem jelenti azt, hogy ne lehetne más megközelítéseket alkalmazni. Csak arról van szó, hogy ha az adatok egy része eltűnik az eszközről, akkor nem fog működni a szerverről történő javítás (és még inkább a szerver oldalon történő tájékozódás).

Talán az internet korlátlan tarifáinak jelenlétében és ingyenesen wifi probléma a mobilalkalmazások által generált forgalom korlátozása kevésbé lesz releváns. Egyelőre azonban mindenféle trükkhöz kell nyúlnunk, több „okos” megközelítést kell kidolgoznunk, amelyek csökkenthetik a hálózati költségeket és növelhetik az alkalmazások teljesítményét. Nem mindig működik. Néha előfordul, hogy „minél egyszerűbb, annál jobb”, a helyzettől függően. Remélem, ez a cikk segít megtalálni azt a megközelítést, amely hasznos lesz.

Meglepően kevés leírás található a szerverszinkronizálásról és mobil eszközök. Sőt, számos alkalmazás működik ennek a sémának megfelelően. Akit érdekel, annak egy-két link.

Cégünk nagy terhelésű környezetben működő mobil üzleti alkalmazások és kliens webszolgáltatások szerver részének létrehozására kínál szolgáltatásokat. Az egyes projektek kidolgozásánál igyekszünk pályázni egyéni megközelítés hogy az így létrejövő termék a vevő konkrét céljainak legoptimálisabb megoldásává váljon.

Ha olyan összetett alkalmazást használ, amely adatokat tárol és/vagy dolgoz fel a kiszolgálón, akkor mögötte van egy háttér - Szoftver csomag, amely egy webszerveren van tárolva, és egy alkalmazáson fut, amelyet jelen esetben Front-endnek hívnak. Egy szerveren tárolt alkalmazás egyszerre több ügyféllel is működhet, ami követelményeket támaszt Magassebességés működésének biztonságát.

Gyakran egy alkalmazás szerveroldala be van írva PHP nyelv, mint a legnépszerűbb az ilyen megoldásoknál. Egyszerű szerverfeladatok megvalósítására használható szabványos rendszerek, de a konkrétabbaknál már kötelező a saját megoldás vagy kiegészítők fejlesztése a szabványos rendszereken keresztül.

Szerver fejlesztésének elvei mobilalkalmazáshoz

Programozóink olyan technológiákkal dolgoznak, amelyek segítségével sokféle megoldást tudunk megvalósítani bármilyen, akár nagyon nagy munkaterhelésre és különböző területekre. Az egyes feladatokhoz külön szervermegoldásokat is készítünk.

Szervezeti ellenőrzés

Minden projektet külön szakértői csoport hoz létre, akik felelősek a fejlesztés minden szakaszáért és a projekt időben történő megvalósításáért.

Programozás

A szerver architektúra megtervezése a legfontosabb lépés, amely során az adatbázisok létrejönnek és a szükséges algoritmusok kialakíthatók.

Tesztelés

Szoftver rész hibák és hibák nélkül kell működnie. Ez a rendszer ellenőrzését végző tesztelők felelőssége.

Technikai támogatás

Munkatársaink a programok teljes körű technikai támogatását végzik, mely lehetővé teszi a hiányosságok gyors kiküszöbölését, frissítését.

Fejlesztési jellemzők

Az alkalmazás szerver részének kompetens fejlesztéséhez bizonyos készségekre és a szerveren használt programozási nyelv ismeretére van szükség. Ahogy a gyakorlat azt mutatja, a kliens-szerver alkalmazások PHP-ben jönnek létre. Ezen a területen ő a vitathatatlan vezető. A világ webhelyeinek több mint fele PHP-ben készült, ez kényelmes a fejlesztéshez és a támogatáshoz.

Keretrendszer

Ez a szoftverplatform lehetővé teszi a projekt skálázhatóságát és rugalmasabbá tételét. Ennek ellenére a keretet a lehető leghelyesebben kell megválasztani, ezért a projekt munkadokumentációjának mélyreható elemzésére van szükség, amely a későbbiekben elősegíti a kiváló minőségű termék kifejlesztését.

A háttérfejlesztéshez más nyelveket is használnak. Népszerűek például a Delphi környezetben létrehozott szerveralkalmazások. Ennek köszönhetően a program javította a hibakeresést. Emellett egyszerűbb egyedi programokat fejleszteni benne, vizuális alkotást biztosít. Mindez lehetővé teszi, hogy világos és kényelmes felületet készítsen.

A Java szerver alkalmazások nem kevésbé népszerűek. Probléma nélkül kiegészítik őket, könnyen végrehajthatók különböző platformokon magas szint Biztonság.

Egy másik gyakran használt nyelv. Ezzel a szerveralkalmazások egyszerűen, gyorsan és extra költségek nélkül készülhetnek.

Szinte minden modern cégek saját virtuális irodájuk van. A weboldal bármelyik lehet hívókártya, vagy portál vagy online katalógus rendelés leadási lehetőséggel.

Az üzleti folyamatok ebben az esetben a webszerverektől függenek, nevezetesen a támadásoknak, hackelési kísérleteknek és külső negatív hatásoknak való ellenálló képességüktől, valamint a sok egyidejűleg beérkező kérés teljesítéséhez elegendő teljesítménytől.

A webszolgáltatás fejlesztésének szakaszai

Különböző piaci szegmensek számára készítünk alkalmazásokat, ennek megfelelően szervezzük munkánkat egyetlen elv– a teljes folyamatot külön lépésekre bontjuk, melyek előrehaladását és eredményét beszámoljuk az ügyfeleknek. Így a mobilalkalmazás szervere is ugyanúgy fejlődik.

1. Ötletfejlesztés

Akár 2 hétig

Ebben a szakaszban az alap létrehozása folyamatban van, amely képet ad arról, hogy mit fognak lefektetni, és milyen irányban fog fejlődni.

2. Projektértékelés

2-3 hét

Szakértőink felmérik a munka idejét és költségét, majd előzetes fejlesztési javaslatot készítenek.

3. Feladat és szerződés

Akár 2 hétig

Miután megbeszéltük az ügyféllel a folyamat összes árnyalatát, és elkészítették a részletes TOR-t, szerződés készül és aláírásra kerül.

4. Interfész fejlesztés

2-3 hét

A tervezők feladata a programmodulok írásakor szükséges interfészek létrehozása.

6. Tesztelés

2-3 hét

Az így létrejött szoftvermegoldás átfogó ellenőrzését a tesztelők végzik el a megfelelő eszközök segítségével.

7. A projekt befejezése

Akár 2 hétig

A megbeszélt időn belül egy kész, alaposan tesztelt webszolgáltatást adunk át a megrendelőnek.

Csapatunk

A kereskedelmi tevékenységek és ügyfeleink igényeinek elemzésével valós termékeket hozunk létre, amelyek számos üzleti probléma megoldását segítik. Használat modern technológiák széles körű lehetőséget biztosít a szerverszoftverek megvalósítására, ami garantálja a megfelelő mobilalkalmazások magas teljesítményét. Csapatunkat képviselik:

Projektmenedzserek

Ezek az alkalmazottak mind az ügyfelekkel, mind a fejlesztőkkel kapcsolatba lépnek, kommunikációt biztosítva köztük. Figyelemmel kísérik mind a már tervezett akciók, mind a szükséges fejlesztések végrehajtását.

Tervezők

Munkájuk során szakembereink figyelembe veszik az üzemeltetéshez szükséges interfészek építésére vonatkozó követelményeket iOS rendszerekés Android, így a kiadott alkalmazások megfelelően működnek a különböző eszközökön.

Fejlesztők

A mobilalkalmazások teljesítményének optimalizálása érdekében a programozók elemzik azokat rendszerkövetelményekés hozzon létre speciális szerverszoftvert.

Tesztelők

Az alapos tesztelés garanciát jelent a késztermék minőségére, valamint a tárolt és feldolgozott adatok biztonságára. Ezek a szakemberek különböző eszközöket és hatékony módszertant alkalmaznak.

Milyen szolgáltatásokat hozunk létre

Beágyazva a webhely szoftverébe ill független program, egy webszolgáltatás a reklámozással, elemzéssel, tervezéssel és üzletfejlesztéssel kapcsolatos feladatok elvégzésére szolgál. Ebben a tekintetben el kell dönteni, hogy milyen típusú erőforrás lesz a legjobb megoldás.

Információs projektek

Változatos tartalom befogadására tervezték.

Tematikus oldalak

Szinte minden oldaluk egy témának van szentelve. Továbbra is elég nagy a kereslet irántuk.

híroldalak

Különféle hírekről tájékoztatnak egy vagy több témakör keretében, az élet főbb területeit tükrözve.

Blogok

Ezeknek az erőforrásoknak a népszerűsége folyamatosan növekszik. A híroldalakhoz hasonlóan ők is eljuttatják ezt vagy azt az információt az internetes közösséghez, de ebben az esetben a szerzők személyes véleményüket nyilvánítják ki.

Társadalmi projektek

Ide tartoznak a speciális szociális hálózatok, közösségek, fórumok stb.

Fórumok

Különféle hírek, termékek/szolgáltatások stb. megvitatására készült. Egyszerre lehetnek szűk fókuszúak és sokfélék.

Közösségi hálózatok

Ezeknek az erőforrásoknak több milliós közönsége van. Fő feladatuk, hogy az internetezőknek lehetőséget biztosítsanak a szöveges online kommunikációra / hangüzenetekés videó kommunikáció.

Különféle webszolgáltatások

Manapság elterjedt, több típusra osztják őket.

Katalógusok

Postai szolgáltatások

Biztosítsa a felhasználókat az összes funkcióval és előnnyel Email, beleértve a levelek és dokumentumok megtekintését, küldését, szerkesztését stb.

Kereső motorok

Oldalak keresésére és különféle információk bizonyos kérésekre.

Hirdetőtáblák

Ezek olyan internetes források, ahol a hálózati felhasználók különféle témákban kínálják szolgáltatásaikat.

Tárhelyoldalak

Fájlok ideiglenes tárolására tervezték. Egy részük lehetőséget biztosít az adatok megismerésére a letöltés előtt.

Gyakran Ismételt Kérdések

Az alábbiakban a szakembereinknek gyakran feltett kérdésekre adunk választ. Ha itt nem találja a keresett információt, kérjük, tegye fel kérdését itt. formaés biztosan válaszolunk rá.

Mennyi ideig tarthat egy alkalmazás és egy webszerver létrehozása?

Ez a munka átlagosan 9-20 hétig tart. Minden a végrehajtandó feladat összetettségétől függ.

A kliens-szerver alkalmazások szerveroldali fejlesztése az architektúra tervezésével kezdődik. Sok múlik az architektúrán: az alkalmazás bővíthetőségétől a teljesítményig és a támogatás/karbantartás egyszerűségéig.

Mindenekelőtt meg kell határoznia, hogy az adatok hogyan kerülnek a szerverre, és hogyan dolgozzák fel a klienstől érkező kéréseket. Át kell gondolni a szerveroldali adatgyorsítótár megszervezését is.

Dönteni kell az adatcsere protokollokról és az adatátviteli formátumokról.

API (alkalmazásprogramozási felület) - alkalmazásprogramozási felület. Ha érthetőbb nyelven fejezzük ki, akkor ez a szerver felé irányuló kérések halmaza, amelyet az utóbbi megért, és megadja a helyes választ. Az API határozza meg a szerverlogika funkcionalitását, míg az API lehetővé teszi, hogy elvonatkoztassa a funkció megvalósításának módját. Más szavakkal, az API a teljes ügyfél-szerver infrastruktúra szükséges része.

Hasonlítsa össze a JSON-t és az XML-t. Adjon példát a protokollokra az alkalmazás típusától függően.

Többszálú

A modern programozás egyik kulcsfontosságú szempontja a többszálú feldolgozás. A multithreading segítségével több szálat különíthetünk el az alkalmazásban, amelyek egyidejűleg különböző feladatokat látnak el.

A többszálúság a platform egyik tulajdonsága (pl. operációs rendszer, Virtuális gép stb.) vagy alkalmazás, ami abból áll, hogy az operációs rendszerben létrejövő folyamat több szálból állhat, amelyek "párhuzamosan", azaz előre meghatározott időben történő végrehajtás nélkül futnak.

A multithreading lényege a kvázi-multitasking egy végrehajtható folyamat szintjén, vagyis az összes szál a folyamat címterében fut le. Ezenkívül egy folyamat minden szálának nem csak közös címtere, hanem közös fájlleírói is vannak. Egy futó folyamatnak legalább egy (fő) szála van.

A multithreading (mint programozási doktrína) nem tévesztendő össze sem a multitaskinggal, sem a multiprocessing-el, annak ellenére, hogy a többfeladatos működést megvalósító operációs rendszerek hajlamosak a többszálas működést is megvalósítani.

A többszálú programozás előnyei a következők:

Egyes esetekben a program egyszerűsítése közös címtér használatával.

A folyamathoz képest kevesebb idő kell a szál létrehozására.

Folyamatteljesítmény javítása a processzorszámítások és az I/O műveletek párhuzamosításával.

Folyam(szál) a végrehajtható kód felügyelt egysége. Egy szál alapú többfeladatos környezetben minden futó folyamatnak szükségszerűen van főszála, de lehet több is. Ez azt jelenti, hogy egyetlen program több feladatot is futtathat aszinkron módon. Például szöveg szerkesztése szöveg szerkesztő nyomtatási időben, mivel a két feladat különböző szálakon fut.

A hagyományos processzorokon a szálkezelést az operációs rendszer kezeli. A szál addig fut, amíg hardveres megszakítás nem történik, rendszerhívás nem történik, vagy amíg az operációs rendszer által a számára kijelölt idő le nem telik. Ezt követően a processzor átvált az operációs rendszer kódjára, amely elmenti a szál állapotát (kontextusát), vagy átvált egy másik szál állapotára, aminek szintén van ideje a végrehajtásra. Ilyen többszálú átdolgozással kellően nagy számú processzorciklust fordítanak a kontextust váltó operációs rendszer kódjára. Ha a száltámogatás hardverben van megvalósítva, akkor maga a processzor képes lesz váltani a szálak között, és ideális esetben több szálat is végrehajtani egyidejűleg minden órajelben.

– Ideiglenes többszálú (egyszálas)

- Egyidejű többszálú feldolgozás (több szál egyszerre)

A többszálú, mint széles körben elterjedt programozási és kódvégrehajtási modell lehetővé teszi több szál futtatását egyetlen folyamaton belül. Ezek a végrehajtási szálak megosztják a folyamat erőforrásait, de önállóan is futhatnak. A többszálú programozási modell kényelmes absztrakciót biztosít a fejlesztőknek a párhuzamos végrehajtásból. A technológia talán legérdekesebb alkalmazása azonban az, amikor egyetlen folyamatra alkalmazzák, ami lehetővé teszi párhuzamos végrehajtását többprocesszoros rendszeren.

A többszálú program ezen előnye lehetővé teszi, hogy gyorsabban fusson rajta számítógépes rendszerek, amelyek több processzorral, több maggal rendelkező processzorral vagy egy gépcsoporttal rendelkeznek - annak a ténynek köszönhetően, hogy a programvégrehajtási szálak természetesen alkalmasak a folyamatok valóban párhuzamos végrehajtására. Ebben az esetben a programozónak nagyon óvatosnak kell lennie, hogy elkerülje a versenykörülményeket és más, nem intuitív viselkedést. Az adatok megfelelő manipulálása érdekében a végrehajtási szálaknak gyakran át kell menniük egy találkozási eljáráson, hogy az adatokat a megfelelő sorrendben dolgozzák fel. A végrehajtási szálakhoz mutexekra is szükség lehet (amelyeket gyakran szemaforokkal valósítanak meg), hogy megakadályozzák a megosztott adatok egyidejű módosítását vagy olvasását a módosítási folyamat során. Az ilyen primitívek hanyag használata holtponthoz vezethet.

A többszálú feldolgozás egy másik felhasználási módja, még egyprocesszoros rendszerek esetében is, hogy az alkalmazás képes válaszolni a bemenetre. Az egyszálú programokban, ha a végrehajtás fő szálát egy régóta futó feladat végrehajtása blokkolja, előfordulhat, hogy az egész alkalmazás lefagyott állapotban van. Ha az ilyen régóta futó feladatokat áthelyezi egy munkaszálra, amely párhuzamosan fut a fő szállal, lehetővé válik, hogy az alkalmazások továbbra is válaszoljanak a felhasználói bevitelre, miközben a feladatok futnak. háttér. Másrészt a legtöbb esetben a többszálú feldolgozás nem az egyetlen módja annak, hogy egy program érzékeny legyen. Ugyanez érhető el aszinkron I/O-val vagy jelekkel UNIX-ban.

Kétféle multitasking létezik: folyamat alapúés folyam alapú. A folyamatalapú és a szál alapú multitasking közötti különbségek a következők: a folyamatalapú többfeladatos a programok párhuzamos végrehajtására, a szál alapú multitasking pedig egy program egyes részeinek párhuzamos végrehajtására szolgál.

Kétféle adatfolyam létezik:

Előtér szálak vagy előtér. Alapértelmezés szerint minden, a Thread.Start() metódussal létrehozott szál automatikusan előtérbe kerül. Ez a típus A szálak védelmet nyújtanak az aktuális alkalmazás számára a leállás ellen. A közös nyelv futtatókörnyezete nem állítja le az alkalmazást, amíg az összes előtér-szál be nem fejeződik.

Háttér szálak. Ez a típus A szálakat, más néven démonszálakat a közös nyelvi futási környezet kiterjeszthető végrehajtási útvonalként kezeli, amely bármikor figyelmen kívül hagyható. Így, ha az összes előtér szál megszakad, akkor az összes háttérszálat automatikusan megsemmisíti az alkalmazási tartomány betöltésekor. Háttérszálak létrehozásához az IsBackground tulajdonságot igazra kell állítani.

Mondja el a szálak állapotát: fut, felfüggesztett, fut, de vár valamire.

Szálszinkronizálási probléma és megosztott erőforrások.

Szál interakció

Többszálú környezetben gyakran adódnak problémák, ha ugyanazokat az adatokat vagy eszközöket párhuzamosan futtatják a szálak. Az ilyen problémák megoldására olyan szálinterakciós módszereket használnak, mint a mutexek, szemaforok, kritikus szakaszok és események.

Mutex egy szinkronizálási objektum, amely speciális jelzésű állapotba van állítva, amikor nem foglalja el egyetlen szál sem. Mindig csak egy szál birtokolja ezt az objektumot, ezért az ilyen objektumok neve (az angol kölcsönösen kizáró hozzáférésből - kölcsönösen kizáró hozzáférés) - a megosztott erőforrásokhoz való egyidejű hozzáférés kizárva. Az összes szükséges művelet után a mutex felszabadul, így a többi szál hozzáférést biztosít a megosztott erőforráshoz. Egy objektum támogathatja a rekurzív rögzítést másodszor is ugyanazon szálon keresztül, növelve a számlálót a szál blokkolása nélkül, majd többszöri felszabadítást igényel. Ilyen például a Win32 kritikus része. Vannak azonban olyan implementációk, amelyek nem támogatják ezt, és a szál holtpontra jut, amikor rekurzív rögzítést próbálnak végrehajtani. Ez a FAST_MUTEX a Windows kernelben.

szemaforok képviseli azokat az elérhető erőforrásokat, amelyeket egyszerre több szál is megszerezhet, amíg az erőforráskészlet ki nem ürül. Ezután a további szálaknak meg kell várniuk, amíg a szükséges mennyiségű erőforrás ismét rendelkezésre áll. A szemaforok nagyon hatékonyak, mivel lehetővé teszik az erőforrásokhoz való egyidejű hozzáférést.

Fejlesztések. Egy objektum, amely 1 bitnyi információt tárol „jelzett vagy nem”, amelyen a „jel”, „visszaállítás nem jelzett állapotba” és „vár” műveletek vannak meghatározva. A jelzett eseményre való várakozás a művelet hiánya a szál végrehajtásának azonnali folytatásával. Ha várakozik egy jel nélküli eseményre, egy szál végrehajtása felfüggesztésre kerül mindaddig, amíg egy másik szál (vagy egy megszakításkezelő második fázisa az operációs rendszer kernelében) nem jelzi az eseményt. Lehetőség van több eseményre várni „bármely” vagy „minden” módban. Lehetőség van olyan esemény létrehozására is, amely az első - és egyetlen - várakozó szál felébresztése után automatikusan visszaáll jelzés nélküli állapotba (ilyen objektum a "kritikus szakasz" objektum megvalósításának alapja). Aktívan használják MS Windowsban, mind felhasználói, mind kernel módban. Van egy hasonló objektum Linux kernel kwait_queue néven.

Kritikus szakaszok szinkronizálást biztosítanak, mint a mutexek, kivéve, hogy a kritikus szakaszokat képviselő objektumok ugyanazon a folyamaton belül elérhetők. Az események, mutexek és szemaforok egyfolyamatos alkalmazásokban is használhatók, azonban néhány operációs rendszerben (például Windows NT) a kritikus szakaszok megvalósítása gyorsabb és hatékonyabb mechanizmust biztosít a kölcsönösen kizáró szinkronizáláshoz - a beszerzéshez és kiadáshoz. A kritikus szakaszon végzett műveletek egyetlen szál esetére vannak optimalizálva (nincs versengés), hogy elkerüljük az operációs rendszer kerneléhez vezető rendszerhívásokat. A mutexekhez hasonlóan a kritikus szakaszt képviselő objektumokat egyszerre csak egy szál használhatja, ami rendkívül hasznossá teszi őket a megosztott erőforrásokhoz való hozzáférés korlátozásában.

Feltétel változók(condvars). Hasonló az eseményekhez, de nem olyan objektumok, amelyek memóriát foglalnak el - csak a változó címét használjuk, a "változó tartalma" fogalma nem létezik, egy tetszőleges objektum címe használható feltételváltozóként. Az eseményektől eltérően a feltételváltozó jelzett állapotba állítása nem jár következményekkel, ha jelenleg nincsenek szálak a változón. Egy esemény beállítása hasonló esetben magában foglalja a "jelzett" állapot tárolását magában az eseményben, ami után a következő szálak, amelyek meg akarnak várni az eseményre, azonnal, megállás nélkül folytatják a végrehajtást. Ahhoz, hogy egy ilyen objektumot teljes mértékben kihasználhassunk, szükséges a „engedje fel a mutexet és várja meg a feltételváltozót atomosan” művelet is. Aktívan használják UNIX-szerű operációs rendszerekben. Az események és feltételváltozók előnyeiről és hátrányairól szóló megbeszélések a Windows és a UNIX előnyeiről és hátrányairól szóló megbeszélések kiemelkedő részét képezik.

I/O befejezési port(IO befejező port, IOCP). Az operációs rendszer kernelében implementált és rendszerhívásokon keresztül elérhető "queue" objektum a következő műveletekkel: "a struktúrát a sor farkába helyezi" és "a következő struktúrát veszi a sor fejéből" - az utolsó hívás felfüggeszti a végrehajtást. ha a sor üres, és amíg más szál nem indítja el a put hívást. Az IOCP legfontosabb jellemzője, hogy a struktúrák nem csak felhasználói módból történő explicit rendszerhívással helyezhetők el benne, hanem implicit módon az OS kernelen belül is, az egyik fájlon végrehajtott aszinkron I / O művelet eredményeként. leírók. E hatás eléréséhez a "fájlleíró társítása IOCP-vel" rendszerhívást kell használnia. Ebben az esetben a sorban elhelyezett struktúra tartalmazza az I / O művelet hibakódját, illetve a művelet sikeressége esetén a ténylegesen bevitt vagy kimeneti bájtok számát. A befejezési port megvalósítása korlátozza azon szálak számát is, amelyek egyetlen processzoron/magon futnak le, miután egy struktúra érkezett a sorból. Az objektum az MS Windowsra jellemző, és lehetővé teszi a bejövő csatlakozási kérelmek és adatdarabok feldolgozását a szerveren szoftver olyan architektúrában, ahol a szálak száma kevesebb lehet, mint a kliensek száma (nincs követelmény, hogy minden új klienshez külön szálat hozzon létre erőforrásköltségekkel).

Menet medence

Mesélj a fonalakról