Mobil müştərilər üçün serverin hazırlanması. Mobil müştərilər üçün serverin hazırlanması Mobil proqramın server hissəsinin hazırlanması

Müştəri-server tətbiqinin server tərəfinin inkişafı arxitekturanın dizaynından başlayır. Arxitekturadan çox şey asılıdır: tətbiqin genişlənməsindən tutmuş performansına və dəstək / baxım asanlığına qədər.

İlk növbədə, məlumatların serverə necə yerləşdiriləcəyini və müştəridən gələn sorğuların necə işlənəcəyini müəyyən etməlisiniz. Siz həmçinin server məlumatlarının keşləşdirilməsinin təşkilini nəzərə almalısınız.

Məlumat mübadiləsi protokollarını və məlumat ötürmə formatlarını müəyyən etmək lazımdır.

API (application programming interface) proqram proqramlaşdırma interfeysidir. Daha başa düşülən dildə desək, bu, sonuncunun başa düşdüyü və düzgün cavab verə biləcəyi serverə müraciətlər toplusudur. API server tərəfi məntiqinin funksionallığını müəyyən edir, API isə bu funksionallığın tam olaraq necə həyata keçirildiyini mücərrədləşdirməyə imkan verir. Başqa sözlə, API ümumi müştəri/server infrastrukturunun zəruri hissəsidir.

JSON və XML-i müqayisə edin. Tətbiq növündən asılı olaraq protokolların nümunəsini təqdim edin.

Çoxmilli

Müasir proqramlaşdırmanın əsas aspektlərindən biri çoxillikdir. Multithreading köməyi ilə biz eyni vaxtda müxtəlif tapşırıqları yerinə yetirəcək bir tətbiqdə bir neçə mövzu ayıra bilərik.

Multithreading platformanın (məsələn, əməliyyat sistemi, virtual maşın və s.) və ya tətbiqetmənin xüsusiyyətidir ki, əməliyyat sistemində yaranan prosesin “paralel” işləyən bir neçə ipdən ibarət ola biləcəyi, yəni təyin edilmiş bir xətt olmadan vaxtında sifariş verin.

Çoxmilliliyin mahiyyəti bir icra edilə bilən proses səviyyəsində kvazi-multitapkımdır, yəni prosesin ünvan məkanında bütün iplər icra olunur. Bundan əlavə, prosesdəki bütün mövzular yalnız ümumi ünvan sahəsinə deyil, həm də ümumi fayl deskriptorlarına malikdir. Çalışan prosesdə ən azı bir (əsas) başlıq var.

Multitasking (proqramlaşdırma doktrinası kimi) çoxtəsirli işləmə və ya çoxişləmə ilə qarışdırılmamalıdır, baxmayaraq ki, çoxtaskinliyi həyata keçirən əməliyyat sistemləri çoxişliliyi də həyata keçirir.

Proqramlaşdırmada multithreading üstünlüklərinə aşağıdakılar daxildir:

Ümumi ünvan sahəsinin istifadəsi ilə əlaqədar bəzi hallarda proqramın sadələşdirilməsi.

Axın yaratmaq üçün prosesə nisbətən daha az vaxt tələb olunur.

Prosessor hesablamalarının və giriş/çıxış əməliyyatlarının paralelləşdirilməsi hesabına prosesin performansının artması.

Axın(threаd) icra edilə bilən kodun idarə olunan vahididir. Mövzu əsaslı multitasking mühitində bütün işləyən proseslərin əsas ipi olmalıdır, lakin daha çox ola bilər. Bu o deməkdir ki, bir proqramda bir neçə tapşırıq asinxron şəkildə yerinə yetirilə bilər. Məsələn, çap zamanı mətn redaktorunda mətni redaktə etmək, çünki bu iki tapşırıq müxtəlif mövzularda yerinə yetirilir.

Adi bir prosessorda axına nəzarət əməliyyat sistemi tərəfindən idarə olunur. Aparat kəsilməsi, sistem çağırışı və ya əməliyyat sistemi tərəfindən onun üçün ayrılmış vaxt başa çatana qədər mövzu icra olunur. Bundan sonra prosessor ipin vəziyyətini (onun kontekstini) saxlayan əməliyyat sistemi koduna keçir və ya icra üçün vaxt ayrılan başqa bir ipin vəziyyətinə keçir. Belə çoxilliklərlə, kontekstləri dəyişdirən əməliyyat sistemi koduna kifayət qədər çox sayda prosessor dövrü sərf olunur. Əgər ip dəstəyi aparatda həyata keçirilirsə, o zaman prosessor özü iplər arasında keçid edə biləcək və ideal olaraq hər saat dövrü üçün eyni vaxtda bir neçə ipi yerinə yetirə biləcək.

- Müvəqqəti çox iş parçacığı (bir mövzu)

- Sinxron çox iş parçacığı (eyni anda bir neçə iplik)

Multithreading, geniş yayılmış proqramlaşdırma və kodun icrası modeli kimi, bir proses daxilində birdən çox mövzunun icrasına imkan verir. Bu icra ipləri prosesin resurslarını bölüşür, lakin onlar müstəqil işləyə bilərlər. Çox yivli proqramlaşdırma modeli tərtibatçılara paralel icra üçün rahat abstraksiya təqdim edir. Bununla belə, texnologiyanın bəlkə də ən maraqlı tətbiqi onun çoxprosessorlu sistemdə paralel icrasına imkan verən bir prosesə tətbiq edilməsidir.

Çox yivli proqramın bu üstünlüyü ona çoxsaylı prosessorlara, çoxlu nüvələrə malik prosessorlara və ya maşınlar klasterinə malik olan kompüter sistemlərində daha sürətli işləməyə imkan verir - çünki proqram ipləri təbii olaraq proseslərin həqiqətən paralel icrasını təmin edir. Bu halda, proqramçı yarış şərtlərindən və digər qeyri-intuitiv davranışlardan qaçmaq üçün çox diqqətli olmalıdır. Verilənləri düzgün manipulyasiya etmək üçün, məlumatları düzgün ardıcıllıqla emal etmək üçün icra ipləri tez-tez görüş prosedurundan keçməlidir. Yeniləmə prosesi zamanı paylaşılan məlumatların dəyişdirilməsinin və ya oxunmasının qarşısını almaq üçün icra mövzuları da mutexeslərə (çox vaxt semaforlardan istifadə etməklə həyata keçirilir) ehtiyac duya bilər. Bu cür primitivlərdən ehtiyatsız istifadə dalana dirənə bilər.

Hətta birprosessorlu sistemlər üçün də tətbiq oluna bilən çox iş parçacığının başqa bir istifadəsi tətbiqin girişə cavab vermə qabiliyyətidir. Tək yivli proqramlarda, əsas mövzu uzun müddət davam edən tapşırıqla bloklanırsa, bütün proqram dondurula bilər. Bu cür vaxt aparan tapşırıqları əsas iplə paralel işləyən işçi mövzuya köçürməklə, tapşırıqlar fonda işləyərkən proqramların istifadəçi daxiletmələrinə cavab verməyə davam etməsi mümkün olur. Digər tərəfdən, əksər hallarda, proqramın həssaslığını qorumağın yeganə yolu çoxillik deyil. Eyni şeyi UNIX-də asinxron I/O və ya siqnallar vasitəsilə əldə etmək olar.

Ümumilikdə, iki növ multitasking var: proseslərə əsaslanır və axınlara əsaslanır... Prosesə əsaslanan və mövzuya əsaslanan çoxtasdiqləmə arasındakı fərq aşağıdakılara qədər qaynayır: prosesə əsaslanan çoxtasdiqləmə proqramların paralel icrası üçün təşkil edilir və mövzu əsaslı çoxtaskinlik eyni proqramın ayrı-ayrı hissələrinin paralel icrası üçündür.

Ümumilikdə iki növ axın fərqləndirilir:

Ön plan mövzuları və ya ön plan. Varsayılan olaraq, Thread.Start () metodu ilə yaradılmış hər bir ip avtomatik olaraq ön plana çevrilir. Bu tip iplər cari tətbiqin dayandırılmadan qorunmasını təmin edir. CLR bütün ön plan mövzuları bitənə qədər tətbiqi dayandırmayacaq.

Fon ipləri Bu tip ipliklərə daemon ipləri də deyilir və CLR tərəfindən istənilən vaxt nəzərə alına bilən genişləndirilə bilən icra yolları kimi şərh olunur. Beləliklə, bütün ön plandakı mövzular dayandırılırsa, proqram domeni yükləndikdə bütün fon mövzuları avtomatik olaraq məhv edilir. Fon mövzuları yaratmaq üçün IsBackground xassəsini doğru olaraq təyin edin.

İplərin vəziyyətləri haqqında danışın: qaçan, dayandırılmış, qaçan, lakin bir şey gözləyir.

Mövzunun sinxronizasiya problemi və paylaşılan resurslar.

İplərin qarşılıqlı təsiri

Çox yivli mühitdə paralel icraedici iplər tərəfindən eyni məlumatların və ya cihazların istifadəsi ilə bağlı problemlər tez-tez olur. Bu cür problemləri həll etmək üçün tellərin qarşılıqlı təsirinin mutexes, semaforlar, kritik bölmələr və hadisələr kimi üsullarından istifadə olunur.

Muteks Heç bir mövzu ilə məşğul olmadıqda xüsusi siqnal vəziyyətinə təyin edilmiş sinxronizasiya obyektidir. İstənilən vaxt bu obyektə yalnız bir mövzu sahibdir, buna görə də belə obyektlərin adı (İngilis dilindən qarşılıqlı eksklüziv giriş) - paylaşılan mənbəyə eyni vaxtda giriş istisna edilir. Bütün lazımi tədbirlər görüldükdən sonra mutex buraxılır və digər mövzulara paylaşılan mənbəyə giriş imkanı verilir. Obyekt eyni iplə ikinci dəfə rekursiv ələ keçirməyi dəstəkləyə bilər, ipi bloklamadan sayğacı artıraraq və sonra çoxlu boşalma tələb edir. Bu, məsələn, Win32-də kritik hissədir. Bununla belə, bunu dəstəkləməyən bəzi tətbiqlər var və rekursiv tutma cəhdi zamanı mövzunun kilidlənməsinə səbəb olur. Bu, Windows nüvəsindəki FAST_MUTEX-dir.

Semaforlar resurs hovuzu boş olana qədər eyni anda birdən çox mövzu tərəfindən əldə edilə bilən mövcud resurslardır. Sonra əlavə mövzular tələb olunan miqdarda resurs yenidən mövcud olana qədər gözləməlidir. Semaforlar çox səmərəlidir, çünki onlar resurslara eyni vaxtda daxil olmağa imkan verir.

İnkişaflar... "siqnallı və ya olmayan" 1 bit məlumatı saxlayan obyekt, üzərində "siqnal", "siqnalsız vəziyyətə qayıt" və "gözlə" əməliyyatları müəyyən edilir. Siqnallı bir hadisəni gözləmək, ipin icrasının dərhal davamı ilə əməliyyatın olmamasıdır. Seçilməmiş hadisəni gözləmək, başqa bir başlıq (və ya ƏS nüvəsindəki kəsmə işləyicisinin ikinci mərhələsi) hadisəyə siqnal verənə qədər mövzunun dayandırılmasına səbəb olur. "Hər hansı" və ya "hamısı" rejimlərində bir neçə hadisəni gözləmək mümkündür. İlk və yeganə gözləyən ipi oyandıqdan sonra avtomatik olaraq qeyri-siqnal vəziyyətinə qaytarılan hadisə yaratmaq da mümkündür (belə obyekt "kritik bölmə" obyektinin həyata keçirilməsi üçün əsas kimi istifadə olunur). Onlar MS Windows-da həm istifadəçi rejimində, həm də nüvə rejimində fəal şəkildə istifadə olunur. Linux nüvəsində kwait_queue adlı oxşar obyekt var.

Kritik bölmələr kritik bölmələri təmsil edən obyektlərin eyni proses daxilində mövcud olması istisna olmaqla, mutexlərə bənzər sinxronizasiya təmin edir. Hadisələr, mutekslər və semaforlar tək proses tətbiqində də istifadə edilə bilər, lakin bəzi əməliyyat sistemlərində (məsələn, Windows NT kimi) kritik bölmə tətbiqləri daha sürətli və daha səmərəli qarşılıqlı eksklüziv sinxronizasiya mexanizmini təmin edir - kritik bölmədə əməliyyatları əldə edin və buraxın OS nüvəsinə aparan hər hansı sistem çağırışlarının qarşısını almaq üçün tək başlıq (mübahisəsiz) üçün optimallaşdırılmışdır. Mutekslər kimi, kritik bölməni təmsil edən obyekt eyni anda yalnız bir mövzu tərəfindən istifadə edilə bilər ki, bu da onları paylaşılan resurslara girişi məhdudlaşdırmaq üçün son dərəcə faydalı edir.

Şərti dəyişənlər(condvars). Onlar hadisələrə bənzəyir, lakin yaddaşı tutan obyektlər deyil - yalnız dəyişənin ünvanı istifadə olunur, "dəyişənin məzmunu" anlayışı mövcud deyil, ixtiyari obyektin ünvanı şərti dəyişən kimi istifadə edilə bilər. . Hadisələrdən fərqli olaraq, hal-hazırda dəyişəndə gözləyən mövzular yoxdursa, şərt dəyişəninin siqnallı vəziyyətə təyin edilməsi heç bir nəticə vermir. Oxşar vəziyyətdə hadisənin təyin edilməsi hadisənin özündə "siqnallı" vəziyyətin saxlanmasını nəzərdə tutur, bundan sonra hadisəni gözləmək istəyən növbəti iplər dayanmadan dərhal icrasını davam etdirir. Belə obyektdən tam istifadə etmək üçün həm də mutexi buraxmaq və şərti dəyişəni atomik olaraq gözləmək lazımdır. Onlar UNIX kimi əməliyyat sistemlərində geniş istifadə olunur. Hadisələrin və şərti dəyişənlərin üstünlükləri və çatışmazlıqları haqqında müzakirələr Windows və UNIX-in üstünlükləri və çatışmazlıqları haqqında müzakirələrin əsas hissəsini təşkil edir.

I/O tamamlama portu(IO tamamlama portu, IOCP). ƏS ləpəsində həyata keçirilən və sistem çağırışları vasitəsilə “strukturu növbənin quyruğuna qoymaq” və “növbənin başından növbəti strukturu götürmək” əməliyyatları ilə əldə edilən “növbə” obyekti – sonuncu zəng icrasını dayandırır. Növbə boşdursa və başqa bir mövzu "qoymaq" üçün zəng etməyəcək qədər. IOCP-nin ən vacib xüsusiyyəti ondan ibarətdir ki, strukturlar ona yalnız istifadəçi rejimindən açıq sistem çağırışı ilə deyil, həm də fayl deskriptorlarından birində tamamlanan asinxron I/O əməliyyatı nəticəsində dolayısı ilə OS nüvəsi daxilində yerləşdirilə bilər. Bu effekti əldə etmək üçün siz "IOCP-yə fayl deskriptorunu bağlamaq" sistem çağırışından istifadə etməlisiniz. Bu halda növbəyə yerləşdirilən strukturda I/O əməliyyatının səhv kodu, həmçinin bu əməliyyat uğurlu olarsa, faktiki daxil edilmiş və ya çıxan baytların sayı da var. Tamamlama portunun tətbiqi struktur növbəyə qoyulduqdan sonra tək prosessorda/nüvədə işləyən tellərin sayını da məhdudlaşdırır. Obyekt MS Windows-a xasdır və server proqram təminatında daxil olan əlaqə sorğularını və məlumat hissələrini emal etməyə imkan verir, burada mövzuların sayı müştərilərin sayından az ola bilər (resurs xərcləri ilə ayrıca mövzu yaratmaq tələbi yoxdur). hər yeni müştəri).

İplər hovuzu

İp hovuzu haqqında danışın

Müasirlərin çoxu mobil platformalar üçün proqramlar(iOS, Android və s.) serverlə tandemdə işləyir. Köhnəlmiş məlumatları olan proqram öz faydalılığını itirir. Buna görə də, serverdən cihaza məlumatların daim yenilənməsini təmin etmək vacibdir. Bu, İnternet olmadan işləməli olan oflayn tətbiqlərə aiddir. İnternet olmadan işləməyən (və ya yararsız) tamamilə onlayn proqramlar üçün (məsələn, Foursquare, Facebook) bu məqalənin əhatə dairəsindən kənarda olan xüsusiyyətlər var.

Oflayn tətbiqlərimizdən birinin nümunəsindən istifadə edərək, məlumatları sinxronlaşdırmaq üçün hansı yanaşmalardan istifadə etdiyimizi sizə xəbər verəcəyəm. İlk versiyalarda inkişaf etdirmişik sadə alqoritmlər və gələcəkdə təcrübə ilə onları təkmilləşdirdik. Bənzər bir ardıcıllıq məqalədə təqdim olunur - sadə aşkar təcrübələrdən daha mürəkkəb olanlara qədər.

Aydınlaşdırmaq lazımdır ki, məqalə məlumatların yalnız bir istiqamətdə ötürülməsindən bəhs edir: serverdən cihaza. Burada server məlumat mənbəyidir.

Bütün yanaşmalar üçün ümumi müddəalar

Məsələn, biz “qablar” kataloqunu cihaza ötürməyi nəzərdən keçirəcəyik. Güman edirik ki, cihaz "/ xidmət / yeməklər / yeniləmə" URL-i üçün sorğu edir, mübadilə JSON formatında http protokolu vasitəsilə həyata keçirilir ( www.json.org). Serverdə aşağıdakı sahələrə malik "yeməklər" cədvəli var: id (qeyd identifikatoru), ad (yeməyin adı), yenilənmiş (yemək yeniləndiyi anda, saat qurşağını dərhal dəstəkləmək daha yaxşıdır, "YYYY-AA-GGThh : mm: ssTZD”, məsələn, “1997 -07-16T19: 20: 30 + 01: 00 ”), silindi (silinmiş qeydin işarəsi).

Son sahənin mövcudluğu ilə bağlı qeyd. Varsayılan olaraq, onun dəyəri 0-dır. Müştəri və server arasında obyektlərin sinxronlaşdırıldığı proqramda verilənlərin serverdən fiziki olaraq silinməsi tövsiyə edilmir (səhvlərin qarşısını almaq üçün). Buna görə də, silinmiş yeməklər üçün is_deleted = 1 təyin edilir. is_deleted = 1 olan obyekt cihaza gəldikdə, o, cihazdan silinir.

Aşağıda nəzərdən keçiriləcək hər hansı bir yanaşma ilə server JSON cihazlarına bir sıra obyektlər qaytarır (boş ola bilər):

[
(id: , adı: , yenilənib: , silindi: },…
]

Server cavab nümunəsi:

[
(id: 5625, ad: "Çörək", yenilənib: "2013-01-06 06:23:12", silindi: 0),
(id: 23, ad: "Bişmiş irmik", yenilənib: "2013-02-01 14:44:21", silindi: 0), (

adı: "Balıq şorbası",

yeniləndi: "2013-08-02 07:05:19",

Cihazda məlumatların yenilənməsi prinsipləri

Cihazda olan bir element gəldi və Silindi = 0 olarsa, o, yenilənir
Əgər cihazda olmayan element gəlibsə və Silinmiş = 0 olarsa, o, əlavə olunur
Cihazda olan bir element gəldi və Silindi = 1 olarsa, o, silinir
Əgər cihazda olmayan element gəlibsə və Silinmiş = 1-dirsə, heç nə edilmir

1-ci yanaşma: Hər şey həmişə sinxronlaşdırılır

Bu, ən asan üsuldur. Cihaz serverdən yeməklərin siyahısını tələb edir və server bütün siyahını göndərir. Hər dəfə bütün siyahı gəlir. Sıralanmadı.

Sorğu nümunəsi: null və ya “()”

Üstünlüklər:

serverdəki məntiq sadədir - biz həmişə hər şeyi veririk
cihazdakı məntiq sadədir - biz həmişə hər şeyin üzərinə yazırıq

Dezavantajları:

siyahını tez-tez tələb etsəniz (hər 10 dəqiqədən bir), onda çoxlu İnternet trafiki olacaq
siyahı nadir hallarda (gündə bir dəfə) tələb olunarsa, məlumatların aktuallığı pozulacaq

Tətbiq sahəsi:

aşağı trafik tətbiqləri üçün
çox nadir hallarda dəyişən məlumatların ötürülməsi (şəhərlərin, kateqoriyaların siyahısı)
proqram parametrlərinin ötürülməsi
mobil proqramın ilk prototipi üçün layihənin əvvəlində

2-ci yanaşma: yalnız yenilənmişləri sinxronlaşdırın

Cihaz əvvəlki sinxronizasiyadan yenilənmiş yeməklərin siyahısını tələb edir. Siyahı artan qaydada "yeniləndi" ilə sıralanır (isteğe bağlıdır, lakin rahatdır). Cihaz ən son göndərilən çanağın "yenilənmiş" dəyərini saxlayır və növbəti sorğuda onu "son yeniləmə" parametrində serverə göndərir. Server “lastUpdated”dən daha yeni olan yeməklərin siyahısını göndərir (yeniləndi> LastUpdated). Serverə ilk sorğuda “lastUpdated” = null.

Sorğu nümunəsi: (son yenilənmə: “2013-01-01 00:00:00”)

Diaqramda: “last_updated” cihazda saxlanılan dəyərdir. Adətən, hər bir obyekt (yemək, şəhər, təşkilat və s.)

Bu yanaşma bütün cihazlar üçün eyni gəliş qaydalarına malik sadə xətti siyahıları sinxronlaşdırmaq üçün uyğundur. Daha çox seçici sinxronizasiya üçün 5-ci yanaşmaya baxın: Artıq cihazda olanlar haqqında məlumatla sinxronizasiya edin.

Bu yanaşma adətən əksər ehtiyacları əhatə edir. Cihaza yalnız yeni məlumatlar gəlir, ən azı hər dəqiqə sinxronizasiya edə bilərsiniz - trafik kiçik olacaq. Bununla belə, mobil cihazların məhdudiyyətləri ilə bağlı problemlər var. Bunlar yaddaş və prosessordur.

3-cü yanaşma: Partiyalarda sinxronizasiya edin

Mobil cihazların RAM-ı azdır. Əgər kataloqda 3000 yemək varsa, o zaman serverdən böyük json sətirini cihazdakı obyektlərə təhlil etmək yaddaş çatışmazlığına səbəb ola bilər. Bu halda, proqram ya çökəcək, ya da bu 3000 yeməyi saxlamayacaq. Ancaq cihaz belə bir simli həzm edə bilsə belə, fonda sinxronizasiya anlarında tətbiqin performansı aşağı olacaq (interfeys gecikmələri, hamar sürüşmə və s.) Buna görə də siyahını daha kiçik şəkildə tələb etmək lazımdır. porsiyalar.

Bunu etmək üçün cihaz hissənin ölçüsünü təyin edən daha bir parametr ("miqdar") keçir. Siyahı artan qaydada "yenilənmiş" sahəsinə görə çeşidlənərək göndərilməlidir. Əvvəlki yanaşmaya bənzər cihaz, sonuncu göndərilən obyektin “yenilənmiş” dəyərini xatırlayır və onu “son yeniləmə” sahəsinə ötürür. Əgər server eyni sayda obyekt göndəribsə, o zaman cihaz sinxronizasiyaya davam edir və yenidən sorğu göndərir, lakin yenilənmiş "son yeniləmə" ilə. Əgər server daha az obyekt göndəribsə, bu o deməkdir ki, onun daha çox yeni məlumatı yoxdur və sinxronizasiya başa çatır.

Diaqramda: “son_yenilənilən” və “miqdar” saxlanılan dəyərlərdir. mobil proqram... "Son_element" - serverdən göndərilən sonuncu varlıq (yemək). Bu dəyərdən daha yenidir ki, növbəti siyahı tələb olunacaq.

Sorğu nümunəsi: (son yenilənib: “2013-01-01 00:00:00”, məbləğ: 100)

Üstünlüklər:

Cihaz bir anda emal edə bildiyi qədər məlumat alır. Xidmət ölçüsü praktiki sınaqlarla müəyyən edilir. Sadə obyektlər bir anda 1000 sinxronlaşdırıla bilər. Ancaq çoxlu sayda sahələri və mürəkkəb saxlama emal məntiqi olan obyektlərin normal olaraq 5 ədəddən çox olmayan sinxronizasiyası da olur.

Dezavantajları:

Eyni yenilənmiş 250 yemək varsa, məbləğ = 100 ilə, son 150-si cihazlara göndərilməyəcək. Bu vəziyyət olduqca realdır və aşağıdakı yanaşmada təsvir edilmişdir.

4-cü yanaşma: Dəstəyin vaxtını düzgün təyin edin

Əvvəlki yanaşmada mümkündür ki, cədvəldə eyni “yenilənmiş” 250 yemək varsa (məsələn, “2013-01-10 12:34:56”) və porsiya ölçüsü 100-dürsə, onda yalnız ilk 100 qeyd gələcək. Qalan 150-si sərt şəkildə kəsiləcək (yeniləndi> son yeniləndi). Bu niyə baş verəcək? İlk 100 qeyd tələb olunduqda, lastUpdated "2013-01-10 12:34:56" olaraq təyin ediləcək və növbəti sorğunun şərti olacaq (yeniləndi> "2013-01-10 12:34:56"). Hətta vəziyyəti yumşaltmaq belə (yeniləndi> = “2013-01-10 12:34:56”) kömək etməyəcək, çünki cihaz bundan sonra sonsuz olaraq ilk 100 qeydi tələb edəcək.

Eyni "yenilənmiş" vəziyyət o qədər də nadir deyil. Məsələn, mətn faylından məlumat idxal edərkən, "yenilənmiş" sahəsi NOW () olaraq təyin edildi. Minlərlə sətirdən ibarət faylı idxal etmək bir saniyədən az çəkə bilər. Bütün kataloqun eyni "yenilənmiş" olması da baş verə bilər.

Bunu düzəltmək üçün ən azı bir an ərzində unikal olacaq bəzi yemək sahəsindən istifadə etməlisiniz (“yenilənmiş”). “İd” sahəsi bütün cədvəldə unikaldır, ona görə də siz onu sinxronizasiyada əlavə olaraq istifadə etməlisiniz.

Beləliklə, bu yanaşmanın həyata keçirilməsi belə görünür. Server "yenilənmiş" və "id" üzrə çeşidlənmiş siyahını qaytarır və cihazlar "lastUpdated" və yeni "lastId" parametrindən istifadə edərək məlumat tələb edir. Serverdə seçim şərti daha mürəkkəbdir: ((yenilənilmiş> sonuncu Yenilənmiş) VEYA (yenilənmiş = lastUpdated və id> lastId)).

Diaqramda: “son_yenilənilən”, “son_id” və “məbləğ” mobil proqramda saxlanılan dəyərlərdir. "Son_element" - serverdən göndərilən sonuncu varlıq (yemək). Bu dəyərdən daha yenidir ki, növbəti siyahı tələb olunacaq.

5-ci yanaşma: Artıq cihazda olanlara dair biliklərlə sinxronizasiya edin

Əvvəlki yanaşmalar, serverin məlumatların cihazda nə qədər uğurla saxlandığını həqiqətən bilməməsi faktını nəzərə almır. Cihaz izah olunmayan xətalara görə sadəcə olaraq bəzi məlumatları saxlaya bilmədi. Buna görə də, cihazdan qabların hamısının (və ya hamısının) qorunub saxlandığına dair təsdiq almaq yaxşı olardı.

Bundan əlavə, proqram istifadəçisi proqramı elə konfiqurasiya edə bilər ki, ona məlumatların yalnız bir hissəsi lazımdır. Məsələn, istifadəçi 10 şəhərdən yalnız 2-də yeməkləri sinxronlaşdırmaq istəyir. Buna yuxarıda təsvir edilən sinxronizasiyalarla nail olmaq mümkün deyil.

Yanaşma ideyası aşağıdakı kimidir. Server cihazda hansı yeməklərin olması barədə məlumatı ("saxlanan_element_siyahısı" ayrı cədvəlində) saxlayır. Bu, sadəcə olaraq “id - yenilənmiş” cütlərin siyahısı ola bilər. Bu cədvəl bütün cihazlar üçün “id - yenilənmiş” qab cütlərinin bütün siyahılarını ehtiva edir.

Cihaz sinxronizasiya sorğusu ilə birlikdə cihazda mövcud olan yeməklər haqqında məlumatı (“id - yenilənmiş” cütlərin siyahısı) serverə göndərir. Tələb olunduqda, server cihazda hansı qabların olması lazım olduğunu və indi nə olduğunu yoxlayır. Sonra fərq cihaza göndərilir.

Cihazda hansı qabların olması lazım olduğunu server necə müəyyənləşdirir? Ən sadə halda, server bütün yeməklərin “id - yenilənmiş” cütlərinin siyahısını qaytaracaq sorğu göndərir (məsələn, SELECT id, yeməklərdən yenilənmiş). Diaqramda bu, “WhatShouldBeOnDeviceMethod ()” metodu ilə həyata keçirilir. Bu yanaşmanın dezavantajıdır - server cihazda nə olması lazım olduğunu hesablamalıdır (bəzən ağır sql sorğuları edir).

Server hansı qabların cihazda olduğunu necə müəyyənləşdirir? O, bu cihaz üçün "saxlanan_element_siyahısı" cədvəlinə sorğu verir və "id - yenilənmiş" cütlərin siyahısını əldə edir.

Bu iki siyahını təhlil edərək, server cihaza nə göndərilməli və nəyin silinməli olduğuna qərar verir. Diaqramda bu “delta_element_list”dir. Buna görə sorğuda "lastUpdated" və "lastId" yoxdur, onların tapşırığı "id - yenilənmiş" cütləri tərəfindən yerinə yetirilir.

Server cihazda mövcud olan yeməklər haqqında necə bilir? Serverə edilən sorğuda, son sinxronizasiyada cihaza göndərilən yeməklərin id siyahısını ehtiva edən yeni parametr "elementlər" əlavə olunur ("device_last_stored_item_list"). Əlbəttə ki, cihazda olan bütün yeməklərin id siyahısını göndərə bilərsiniz və alqoritmi çətinləşdirməyin. Ancaq cihazda 3000 qab varsa və hamısı hər dəfə göndərilirsə, trafik xərcləri çox yüksək olacaq. Sinxronizasiyaların böyük əksəriyyətində "elementlər" parametri boş olacaq.

Server “saxlanan_element_siyahısı”nı “elementlər” parametrində cihazdan gələn məlumatlarla daim yeniləməlidir.

Siz saxlanılan_element_listində server məlumatlarının təmizlənməsi mexanizmini tətbiq etməlisiniz. Məsələn, bir tətbiqi cihazda yenidən quraşdırdıqdan sonra server cihazın hələ də yeni olduğunu güman edəcək. Buna görə də, proqramı quraşdırarkən, cihaz bu cihaz üçün saxlanılan_element_siyahısını təmizləməsi üçün serverə bir şəkildə məlumat verməlidir. Tətbiqimizdə bu halda əlavə “clearCache” = 1 parametrini göndəririk.

Nəticə

Bu yanaşmaların xüsusiyyətlərinin xülasə cədvəli:

№	Bir yanaşma	Trafik həcmi(5 - böyük)	İnkişafın əmək intensivliyi(5 - yüksək)	Cihaz yaddaşının istifadəsi(5 - yüksək)	Cihazdakı məlumatların düzgünlüyü(5 - yüksək)	Müəyyən bir cihaz seçə bilərsiniz
1	Hər şey həmişə sinxronlaşdırılır	5	1	5	5	Yox
2	Yalnız yenilənmiş	1	2	5	3	Yox
3	Dəstələrdə sinxronizasiya	1	3	1	3	Yox
4	Dəstələrdə düzgün sinxronizasiya	1	3	1	3	Yox
5	Artıq cihazda olanların biliyi ilə sinxronizasiya	2	5	2	5	Bəli

“Cihazdakı məlumatların düzgünlüyü” cihazın server tərəfindən göndərilmiş bütün məlumatları ehtiva etməsi ehtimalıdır. № 1 və № 5 yanaşmalar vəziyyətində, cihazın ehtiyac duyduğu bütün məlumatlara malik olduğuna 100% əminlik var. Digər hallarda belə bir zəmanət yoxdur. Bu o demək deyil ki, başqa yanaşmalardan istifadə etmək olmaz. Sadəcə olaraq, məlumatların bir hissəsi cihazda itirilsə, o zaman onu serverdən düzəltmək işləməyəcək (və bu barədə server tərəfində daha çox məlumat əldə etmək üçün).

Ola bilsin ki, limitsiz İnternet tarifləri və pulsuz WiFi mövcud olduqda, mobil tətbiqetmənin yaratdığı trafikin məhdudlaşdırılması problemi daha az aktuallaşacaq. Ancaq hər cür fəndlərə getməli olduğunuz halda, şəbəkə xərclərini azalda və tətbiq performansını artıra bilən daha ağıllı yanaşmalar tapın. Həmişə işləmir. Bəzən vəziyyətdən asılı olaraq "daha sadə, daha yaxşı" olur. Ümid edirik ki, bu məqalədən sizə lazımlı bir yanaşma seçə bilərsiniz.

İnternetdə server sinxronizasiyasının təəccüblü dərəcədə az təsviri var və mobil cihazlar... Üstəlik, bu sxemə uyğun işləyən bir çox proqram var. Maraqlananlar üçün bir neçə link.

Ehtiyat

Mobil platformada ehtiyat nüsxələrə niyə ehtiyacınız var?

Mütəxəssislər, 1C-də bəzən etibarsız mobil tətbiqlərin necə olduğunu bilirlər: səhvlər istənilən vaxt baş verə bilər, buna görə istifadəçi bazası sadəcə çökəcək. Eyni zamanda, biz cihazların özlərinin etibarsızlığı ilə qarşılaşırıq: onlar qırıla, itirilə, oğurlana bilər və istifadəçilər öz məlumatlarını saxlamaq istəyirlər. Və 8.3.9 versiyasına qədər ehtiyat nüsxəsini saxlamaq üçün platforma mexanizmimiz yox idi.

İstifadəçilərdə əvvəllər “nüsxəni saxla” düyməsi olmadığından, Boss proqramının tərtibatçıları öz ehtiyat nüsxələrini yaratmalı olublar. Biz bunu necə etdik?

Verilənlər bazasının məlumatlarını XML şəklində saxlayırıq.

İstifadəçiyə nüsxələrin saxlanması üçün bir neçə variant təklif etmək məqsədəuyğundur - ilk növbədə, bu, müştərilər üçün əlverişlidir, onlar özləri üçün ən yaxşı variantı seçə bilərlər: buludlara yükləmək, poçtlarına göndərmək, cihazda saxlamaq.

Beləliklə, tərtibatçılar əlavə olaraq özlərini sığortalayırlar. Bir şey səhv olarsa və Google Diskdə və ya Yandex Diskdə nüsxələrin yaradılması mexanizmi qəfil pozulubsa, istifadəçiyə hər zaman deyə bilərsiniz ki, hazırda tərtibatçı səhvlə məşğuldur, lakin hələlik o, məlumatları alternativ olaraq saxlaya bilər. yol. İstifadəçilər razıdırlar, çünki məlumatlarına arxayın ola bilərlər.

Mütləq bulud xidmətlərinə diqqət yetirmək lazımdır, çünki cihaz itirilsə və ya xarab olarsa və istifadəçi bir nüsxəni eyni cihazda saxlayıbsa, o zaman məlumatlar itəcək.

Həmçinin biz istifadəçiyə ehtiyat nüsxələri yaratmağın zəruriliyini xatırlatdığınızdan əmin olun.

Konfiqurasiya dəyişdikdə nüsxələri necə saxlamaq olar?

Kütləvi həlldən, daim dəyişən, inkişaf edən və təkmilləşən tətbiqdən danışarkən müştərilərin davranışını nəzərə almalıyıq. İstifadəçi heç bir detalı olmayan tətbiqin köhnə versiyasında saxlanan ehtiyat nüsxəsini bərpa etmək istəyə bilər. Və sonra vəzifə yaranır: məlumatları oxumaq, sonra tətbiqin köhnə versiyasından yeniləmə məntiqinə uyğun olaraq məlumatları doldurmaq. Bunu necə etmək olar? Verilənlərə əlavə olaraq, məlumat strukturunun özünü də saxlayın ki, sonradan onu necə oxuyacağınızı biləsiniz.

Bu məlumat strukturunun saxlanması üçün bir neçə variant var, o cümlədən konfiqurasiyanın özündə saxlanıla bilər. Yəni hər dəfə yeni versiya çıxanda əvvəlki versiyanın metadata strukturunu konfiqurasiyada layoutda saxlayın.

Unutmayın ki, mobil proqramda konfiqurasiya elə böyüməməlidir, biz onun içindəki yeri dəyərləndirməliyik, onu mümkün qədər yığcamlaşdırmalıyıq. Ancaq tətbiq inkişaf edir və bu cür planlar çox olacaq və zaman keçdikcə daha çox olacaqlar.

Buna görə də, mobil proqram vəziyyətində başqa bir yola üstünlük verilir - metadata strukturunu birbaşa məlumat faylında saxlayın... Çıxışda biz belə bir fayl alırıq, burada əvvəlcə bəzi köməkçi məlumatları - konfiqurasiya versiyasını, konfiqurasiya sxemini, ardıcıllığın sərhədlərini saxlayırıq və bundan sonra istifadəçi məlumatlarının özünü XML formatında yazırıq. Bundan əlavə, faylın "Yardımcı məlumatlar" bölməsində nədənsə XML-ə yazıla bilməyən digər vacib məlumatları da saxlaya bilərsiniz.

Biz faylda saxlanılan məlumat sxemini götürürük və onun əsasında faylı oxumaq üçün XDTO paketi qururuq. Biz verilənlər bazasında oxşar obyekt yaradırıq, onu doldururuq, yeniləmə zamanı təkrar doldurma emalını həyata keçiririk və artıq hazır olan obyekti verilənlər bazasında saxlayırıq.

Aşağıdakı şəkildə bu konfiqurasiyaların XDTO modelini necə gözəl yazmaq barədə ipucu görə bilərsiniz. Boss tətbiqini buraxan şirkət bununla sınaqdan keçirdi, bir neçə yol tapdı, lakin metadata sxemini qeyd etmək üçün bu seçim üzərində qərar verdi. Məlumat faylının özünü açdığınız zaman, bütün tətbiq metadatalarını sadalayan oxuna bilən adi strukturlaşdırılmış XML-i görə bilərsiniz.

// ModelXDTO = FactoryXDTO.ExportModelsXDTO konfiqurasiya sxemini yazın ("http://v8.1c.ru/8.1/data/enterprise/current-config"); XDTO Factory.WriteXML (Yükləmə Faylı, XDTO Modeli); // Konfiqurasiya sxeminin oxunması Model XDTO = Fabrika XDTO. XML oxu (XML oxu, Fabrika XDTO. Növ ("http://v8.1c.ru/8.1/xdto", "Model")); UnloadFactory = Yeni XDTOFactory (XDTOModel);

İstifadəçini qorumaq üçün ondan ehtiyat nüsxəsini bərpa etməli olub-olmadığını yenidən soruşmaq lazımdır. Ola bilsin ki, o, sadəcə sınaqdan keçirib tətbiqdəki bütün düymələrə basırdı :) İndi isə onun cari məlumatları itə bilər. Buna görə də, potensial "təhlükəli" hərəkətləri yerinə yetirərkən, biz həmişə onun həqiqətən bunu istədiyini və bunun necə edilməli olduğunu dəqiqləşdiririk. İstifadəçi öz hərəkətlərindən xəbərdar olmalıdır.

Avtonom bir həll haqqında danışarkən, istifadəçinin bütün məlumatları yalnız mobil cihazda saxladığı zaman ehtiyat nüsxələrin yaradılması mexanizmi olmalıdır: istifadəçi öz cihazını itirə bilər, sonra isə məlumatlar itiriləcək. Və belə görünür ki, proqram avtonom şəkildə işləmirsə, lakin mərkəzi serverə qoşulubsa, o zaman istifadəçinin belə bir problemi olmamalıdır, çünki cihaz itirilsə, serverə qoşulacaq, bütün məlumatlarını alacaq. yenidən serverdən və hər şey yaxşı olacaq.

Bununla belə, istifadəçilər heç də həmişə ehtiyat nüsxələrindən bizim gözlədiyimiz kimi istifadə etmirlər :) Onlar çox vaxt onlardan sadəcə məlumatları “geri qaytarmaq” üçün istifadə edirlər. Bu, həqiqətən də çox qəribə davranışdır, lakin mobil proqramların istifadəçiləri məlumat daxil edərkən harada səhv edə biləcəklərini anlamaqda çox tənbəl olurlar və sadəcə olaraq məlumatları geri qaytarır və cari gün üçün məlumatları yenidən daxil edirlər. Boss tətbiqi ilə işləmə statistikasını təhlil etdikdən sonra bunun normal bir təcrübə olduğunu və bu istifadəçi davranışının gözlədiyimizdən daha çox yayıldığını başa düşdük.

Digər cihazlarla sinxronizasiyadan istifadə edirsinizsə, onda siz onu idarə etməlisiniz. Burada bir neçə həll yolu var:

ondakı məlumatların eyni qalacağını və surətin yalnız istifadəçinin cihazında bərpa ediləcəyini bildirərək serverlə əlaqəni kəsmək;
istifadəçiyə əvvəllər bu cür mexanizmləri təyin edərək, bütün cihazlarda bir nüsxəni dərhal bərpa etməyə icazə verməsi daha yaxşıdır.

Burada daha bir şey var. İndiyə qədər biz özümüz ehtiyat nüsxələri saxlayırdıq, bütün prosesə nəzarət edirdik və istifadəçinin “surəti saxla” düyməsini sıxdığı zaman onun hərəkətlərini birbaşa kodda tuturduq. Bütün bunlar daha sonra emal edilə bilər. 8.3.9 platformasında ehtiyat nüsxələri məhz platforma vasitəsilə saxlamaq mümkün oldu. İstifadəçi bunu bizim xəbərimiz olmadan edir. Əgər mərkəzi verilənlər bazası ilə sinxronizasiya istifadə olunursa, belə bir ssenari ilə məşğul olmaq lazımdır. Biz serverimizdə istifadəçinin əvvəllər saxlanmış nüsxəni bərpa etdiyini və ona bir növ həll yolu verəcəyini öyrənməliyik. Biz datanın sinxronizasiyasını ödəyə bilmərik.

MÜZAYƏT

Biz mobil platformada özəl həll yolu haqqında danışarkən, adətən, məsələn, satış agentləri üçün mobil platformadan istifadə etmək və mərkəzi verilənlər bazası ilə məlumat mübadiləsi aparmaq istəyən müştərimiz olur. Burada hər şey sadədir: bir verilənlər bazası, bir neçə cihaz, siz serveri qaldırırsınız, onunla əlaqə qurursunuz. Beləliklə, cihazlar arasında mübadilə problemini həll etmək asandır.

Ancaq hər birinin çox sayda istifadəçisi olan çoxlu verilənlər bazası olan kütləvi tətbiqdən danışırıqsa, vəziyyət daha da mürəkkəbləşir. İstifadəçilər proqramı bazardan yükləyiblər və onlar bir-biri ilə sinxronizasiya etmək istəyirlər. Məsələn, bir ər şəxsi maliyyə proqramını yüklədi və indi o, arvadının da qoşulmasını istəyir və onlar eyni proqramda birlikdə işləyirlər. Çox sayda istifadəçi var, proqram inkişaf edir, böyüyür və çoxlu sayda verilənlər bazasına ehtiyac var. Bütün bunları necə təşkil etmək olar? İstifadəçilər onlar üçün ayrıca verilənlər bazası yaratmaq və sinxronizasiyanı aktivləşdirmək üçün tərtibatçılarla şəxsən əlaqə saxlamayacaqlar. Onlar düyməni basıb onu dərhal işə salmaq istəyirlər. Eyni anda.

Necə davam etmək olar? Burada məlumat mübadiləsi mexanizmi xilasetmə işinə gəlir. Bu, bir ümumi konfiqurasiyanın olduğu, lakin eyni zamanda, bir ümumi verilənlər bazasında qeyri-məhdud sayda istifadəçi bazalarının saxlandığı bir verilənlər bazası təşkil etməyə imkan verir.

Ən yaxşı tərəfi odur ki, siz bizim iştirakımız olmadan dinamik, proqramlı şəkildə istifadəçilər əlavə edə bilərsiniz. Reallıqda istifadəçilər sadəcə olaraq “serverdə qeydiyyatdan keç” düyməsini sıxırlar və hər şey öz-özünə baş verir: serverdə onun üçün şəxsi məlumat bazası yaradılır və o, dərhal orada işə başlaya bilər.

Bunu necə etmək olar? İlk və ən asan həll yolu bu mexanizmlə öz server bazanızı yazmaqdır. Şirkətimiz Boss tətbiqini yaratmağa və orada mübadilə etməyə başlayanda, ilk versiyada biz bunu etdik: məlumat mübadiləsi mexanizmi ilə server verilənlər bazası yazdıq. Hər şey işlədi, xüsusən də mürəkkəb bir şey olmadığı üçün - əsas ayırıcı ümumi bir rekvizitdir.

Amma sonra anladıq ki, çarxı yenidən ixtira edirik :) Əslində, hazır həll yolu var və o, bizim hələ düşünmədiyimiz məqamları artıq nəzərə alıb. Bu 1C: Təzədir.

Xidmətin miqyası burada düşünülür: çoxlu məlumat və verilənlər bazası olduqda nə etməli, bütün bunlarla necə böyümək olar. Məlumat sahələrinin ehtiyat nüsxələrinin yaradılması ilə bağlı bir məqam var: yəni biz yalnız bir ümumi verilənlər bazasının ehtiyat nüsxəsini çıxarmırıq, konkret istifadəçinin surətlərini çıxarırıq. Üstəlik, orada mexanizm elədir ki, nüsxələr yalnız həqiqətən lazım olduqda hazırlanır. Əgər istifadəçi bir həftə ərzində verilənlər bazasına daxil olmayıbsa, onda biz onun surətini çıxarmırıq, çünki orada heç nə dəyişməyib. Fresh-in başqa bir xüsusiyyəti, xidmətin serverə yükü azaltmaq mexanizmini tətbiq etməsidir ki, bu da çoxlu verilənlər bazanız olduqda çox vacibdir.

Ümumiyyətlə, Fresh bizim üçün yeni və maraqlı bir şeydir. Biz bunu yavaş-yavaş anlamağa çalışırıq, lakin əksər hallarda onun işindən razıyıq.

Məlumat ötürülməsi. Cihazlar arasında mübadilə üçün onu necə həyata keçirmək olar

Platforma iki mexanizm təqdim edir - SOAP və http xidmətləri. Məlumat mübadiləsi mexanizmi işə düşərkən bu xidmətlərə necə daxil olmağın nüansları var. Xüsusilə, daxil olduğunuz ərazinin xüsusi sayını göstərən parametrlər əlavə etməlisiniz, çünki platforma istifadəçi adı ilə hansı verilənlər bazasına daxil olacağını müəyyən edə bilmir. Bundan əlavə, bir və eyni istifadəçi bir verilənlər bazası daxilində bir neçə verilənlər bazası ilə işləyə bilər (şəkilə bax).

Xidmətlərə gəldikdə, Boss proqramı ani mübadilə həyata keçirir: bir istifadəçi məlumatları daxil edir, digəri isə onu alır. Mobil proqramların istifadəçiləri hər şeyin bir anda baş verdiyinə öyrəşiblər, ona görə də hansı xidmətdən istifadə etməyin daha yaxşı olduğunu düşündük - SOAP və ya http. Bağlantı sürəti əsas rol oynadı. http-də qoşulma sürəti xeyli yüksəkdir və SOAP vasitəsilə qoşulduqda biz xidmətin təsvirini alırıq ki, bu da ağırdır və yüklənməsi çox vaxt aparır. Platformada xidmətin təsvirini saxlamaq üçün bir yol var, lakin dinamik olaraq əlavə etdiyimiz parametrlərə görə WS istinadlarından istifadə edə bilmirik. Bundan əlavə, http xidmətlərinə daxil olmaq bizim təcrübəmizə görə daha rahat və çevikdir.

Beləliklə, bizim məqsədimiz mübadiləni real vaxt rejimində həyata keçirməkdir. Yəni biz çalışırıq ki, istifadəçi harasa getməyə məcbur olmasın, düyməni sıxsın, onun məlumatlarının nə dərəcədə aktual olduğunu, onu yeniləməli olub-olmadığını fikirləşin... Məlumatlar həmişə istifadəçilər üçün aktual olmalıdır. Onlar ani messencerlərdə işləməyə o qədər öyrəşiblər - biri məlumatları göndərdi, digəri dərhal qəbul etdi. Hər şey dərhal baş verir. Eyni şey bizneslə bağlı müraciətlərə də aiddir: bir satıcı satış elan edib, digəri heç bir tədbir görmədən dərhal mövcud vəziyyəti görməlidir.

Buna görə də, Boss proqramı mübadilələr üçün fon işlərindən istifadə edir. Hər bir məlumat verilənlər bazasına yazıldıqdan sonra mübadiləni başlatan fon işi başlayır. Birinci hissə məlumatların serverə göndərilməsidir. Sonra digər qurğular yeni məlumatların olduğunu bilməlidir. Bunun üçün PUSH bildirişlərindən istifadə edirik. Bu sxem artıq işləyir və kifayət qədər sürətli işləyir.

Amma biz bunu daha da tez istəyirdik, çünki biz real vaxt rejimində işləyirik və adətən məlumatımız azdır. Kiçik XML-imiz var, lakin eyni zamanda biz bu məlumatla ilk cihazdan serverə mesaj göndəririk, server başqa cihaza PUSH göndərir, sonra ikinci cihaz PUSH aldıqdan sonra öz tərəfdən mübadilə etməyə başlayır, serverə müraciət edir və məlumatları tələb edir, bu məlumatları alır və sonra məlumatın qəbul edildiyinə dair cavab göndərir. Bu, uzun müddətdir, lakin məlumatların özü çox kiçik idi.

Biz bu prosesi necə sürətləndirmək barədə düşündük.

Bunun üçün PUSH-un nəyi ehtiva etdiyini, hələ də necə istifadə oluna biləcəyini anladıq. Məlum oldu ki, PUSH-da verilənlər və mətn kimi sahələr var. iOS və Android sənədlərində PUSH mesajlarının ölçüsünə məhdudiyyətlər var, lakin bu, bizə kifayət etmədi və biz bunu empirik şəkildə anlamaq istədik. Və biz yoxladıq ki, iOS üçün etibarlı simvolların cəmi 981 simvol, Android üçün isə 3832 simvoldur. Sonuncu vəziyyətdə, məhdudiyyətdən istifadə etmək olduqca mümkündür, bir və ya bir neçə əsas obyekt belə bir həcmə sıxışdırıla bilər. Və sonra şirkətin tərtibatçıları sxemi bir az dəyişdirdilər. Məlumat az olduqda, biz onu bir cihazdan göndəririk, serverdə qəbul edirik, orada PUSH-a yığırıq və birbaşa digər cihaza göndəririk. Sxem qısaldıldı və mübadilə daha da sürətli oldu :)

PUSH istifadə etməyin vacib məqamı istifadəçiləri qıcıqlandırmamaqdır.

Bu vəziyyətdən xilas olmaq çox asandır: sadəcə istifadəçiyə çox PUSH mesajı göndərməyin :) Əgər o, hazırda proqramda işləyirsə, çoxlu mesaj göndərə bilərsiniz. Platforma işləyərkən istifadəçi PUSH görmür, hər şey avtomatik olaraq baş verir. Ancaq proqram bağlandıqda, müştəridə çoxlu oxunmamış mesajlar olur. Buna görə də, heç bir halda, proqramın işlədiyi, aktiv olduğu və əvvəlki PUSH-un artıq işləndiyi barədə cihazdan cavab alınana qədər növbəti PUSH göndərilməməlidir.

Mübadilənin başqa bir nüansı internet vasitəsilə işləməkdir. Biz asinxroniyadan maksimum istifadə etməliyik. Siz həmişəki kimi işləyə bilməzsiniz - kodu yazın - funksiyaya zəng edin - onun yerinə yetirilməsini gözləyin - cavabı alın - və hər şey qaydasındadır. İnternet üzərində işləsəniz, hələ də müəyyən məhdudiyyətlərlə üzləşəcəksiniz, məsələn, qeyri-sabit İnternet, uzun əməliyyatları yerinə yetirərkən tetiklenen fasilələr. Buna görə də memarlıq üzərində əvvəlcədən düşünmək lazımdır.

Bir cihazın qeydiyyata alınması nümunəsinə baxaq, istifadəçi qeydiyyatdan keçmək istədikdə tətbiqdə nə baş verir. Bir müddət qeydlər aparır, çoxlu məlumatlar daxil etdi, amma sonra satıcının da bu baza ilə işləməsini istəyir. İstifadəçi “qeydiyyatdan keç” düyməsini sıxır. Əvvəlcə hər şey çox sadə idi: onun məlumatlarını götürdülər, serverdə qeyd etdilər və zəhmət olmasa, işləyə və istifadəçiləri birləşdirə bilərsiniz. Ancaq sonra elə bir vəziyyətlə qarşılaşdıq ki, bəzi istifadəçilər üçün qeydiyyat zamanı cihazdakı verilənlər bazası artıq çox böyümüşdü. Və bu sxem artıq işləmədi, çünki bütün verilənlər bazası serverdə qeydə alınarkən, qoşulma fasiləsi işə salındı və ya İnternet sadəcə olaraq kəsildi. Buna görə də bir sinxron zəngi bir çox qısa zənglərlə əvəz etdik. İndi məlumatlar bir anda ötürülməkdənsə, paylaşılır. Biz heç bir şəkildə serverin məlumatları emal etməsini və qeyd etməsini gözləmirik. Məlumat göndərdik, məlumatın alındığına dair cavab aldıq, əlaqəni bağladıq. Periyodik olaraq, serverdə nə baş verdiyini və necə baş verdiyini sorğulamalısınız və bu vaxt serverdə alınan məlumatları qeyd edən fon işi işləyir. Bu yolla biz çoxlu server zəngləri alırıq, lakin hər şeyin yaxşı olacağına zəmanətimiz var. Və nə fasilələr, nə də İnternet qeyri-sabitliyi bütün məlumatları serverə yükləməyinizə mane olmayacaq.

YENİLİKLƏR

Tətbiqin müxtəlif versiyaları olan cihazlar arasında mübadilə

Söhbət bazarlara çıxarılan kütləvi tətbiqdən getdiyimiz üçün yeniləmə və məlumat mübadiləsi prosesinin bəzi xüsusiyyətlərini nəzərə almalıyıq.

Bir müəssisə üçün bir proqram buraxdınız və onu yeniləmək qərarına gəldinizsə, adətən bütün işçilərə yeni proqramı birlikdə quraşdırmaq əmrini verirsiniz. Proqramı bazardan endirmiş istifadəçilərlə bunu etmək olmaz. Onlara ümumiyyətlə nə edəcəyini deyə bilməzsən. Məsələn, onlar proqramda işləyirlər və onu nə indi, nə də heç vaxt yeniləmək istəmirlər. Onların avtomatik yeniləməsi yoxdur, buna görə də bir neçə cihazın mərkəzi bazaya qoşulması olduqca yaygın bir vəziyyətdir və hamısı fərqli versiyalardadır. Bu fenomenin başqa bir səbəbi bazarlarda nəşr vaxtıdır: iOS və Android üçün fərqlidir. Biz tez-tez əsas şeyləri həyata keçiririk, məsələn, kritik səhvləri düzəldirik və iki həftə iOS-un yeni versiyanı yoxlamasını gözləmək istəmirik, ən azı yalnız Android üçün istəyirik, lakin yeniləməni elə indi buraxırıq.

İstifadəçilərə əmr vermək hüququmuz yoxdur. İstəsələr yenilənirlər, istəməsələr heç nə etmirlər. Şəkildə GooglePlay-də versiyalar üzrə Boss proqram quraşdırmalarının nisbəti, eləcə də serverimizin statistik məlumatları göstərilir - son həftə ərzində serverlə məlumat mübadiləsi aparan cihazlarda quraşdırılmış proqram versiyalarının real nisbəti. Burada işləmək üçün bir dəst var. Bunlar fərqli versiyalar və fərqli metadatalardır. Və eyni zamanda normal mübadilə təşkil etməliyik :)

Tərtibatçılar aşağıdakı vəzifələrlə üzləşirlər:

Bütün bunlar işləmək lazımdır. İstifadəçilər təkmilləşdirməyi unutduqları üçün narahatlıq hiss etməməlidirlər. Onlar bunu qətiyyən fərq etməməlidirlər. Yenilənib - daha yaxşı, yaxşı və yaxşıdır.
Biz məlumatların təhlükəsizliyini təmin etməliyik. Məsələn, bir istifadəçinin kataloqu və yeni rekvizitləri var, digərində isə hələ yoxdur. Eyni zamanda, yeni təfərrüatları olmayan istifadəçi öz cihazında nəyisə dəyişdirirsə, digər cihazlarda məlumatlar itirilməməlidir.
Yeni versiyaya yüksəldərkən məlumatların yenilənməsini təmin etməliyik. İstifadəçi yeniləməyə hazır olduğuna qərar verdikdə, avtomatik olaraq köhnə versiyaya malik olmadığı üçün bütün yeni məlumatlara sahib olmalıdır.

Biz bunu necə etdik?

1. Serverdə 2 mübadilə planından istifadə edirik. Birincisi cihazlar arasında paylaşmaq üçün, ikincisi isə yeniləmələr üçündür. Məsələn, istifadəçiyə təlimat göndərdik, lakin onun ölçü vahidləri, yəni natamam məlumatlar yoxdur. Biz bunu yadda saxlamalıyıq. Və o, yeniləndikdə, onda olmayan bütün məlumatları ona göndərməliyik. İkinci mübadilə planının məqsədi budur.

2. Obyektləri yazmaq və oxumaq üçün biz ehtiyat nüsxələri üçün istifadə olunan eyni mexanizmdən istifadə edirik, yəni metadata versiyasını saxlayırıq. Bu halda, biz serverlə işləyirik və biz istədiyimiz hər şeyi birbaşa konfiqurasiyaya əlavə edə bilirik, ona görə də proqram inkişaf etdikcə konfiqurasiyaya sadəcə metadata sxemlərini düzənlər şəklində əlavə edirik.

Mübadilə zamanı və serverdə böyük səhvləri necə izləmək olar

Birincisi, serverin özünün mövcudluğuna nəzarət etməlisiniz. Bu serverlərdə olur - onlar düşür. Biz monitorinq üçün xüsusi bir şey icad etmədik, sadəcə olaraq teleqramda nəsə səhv olarsa qışqıran bir bot tapdıq. O, hər dəqiqə serverin işini yoxlayır və birdən server əlçatmaz olarsa qışqırmağa başlayır, adminlər bunu görüb serveri gündəmə gətirirlər.

Biz də xəta jurnalını jurnaldan toplayırıq. Həm də fövqəltəbii bir şey yoxdur - biz sadəcə olaraq hər üç saatdan bir səhvlər jurnalını toplayır, onları poçta göndərir, vaxtaşırı nəzərdən keçiririk. Bu, ümumi problemləri və bəzi müstəsna halları görməyə kömək edir. Məktubunuzu oxumaq, izləmək və səhvləri tez bir zamanda düzəltmək çətin deyil. Lakin bu, verilənlər bazalarının böyüməsi ilə böyüyə biləcək problemləri tez bir zamanda müəyyən etməyə və həll etməyə imkan verir.

Başqa bir vacib məqam - istifadəçiyə "şikayət etmək" imkanı verdiyinizə əmin olun. Onların gözündə statusumuzu yaxşılaşdırır və bizi xilas edir. Elə istifadəçilər var ki, bizim onları adlandırdığımız “isteriklər” ən kiçik bir səhvdə bizə poçtla bir dəstə mesaj göndərməyə başlayırlar ki, heç nə işləmir, verilənlər bazası yüklənmir, hər şey dəhşətli dərəcədə pisdir. Ancaq bəzən bizi həqiqətən xilas edirlər, çünki bəzən elə səhvlər tapırlar ki, başqalarının möcüzəvi şəkildə tapmadığı ciddi səhvlər.

İstifadəçi qorxa bilməz. Qorxulu mesajlar deyil, başqa heç nə. Hər şeyi gözəl izah edib şikayət etməyi təklif etməlidirlər. Və hər şeyi həll edəcəyimizə söz veririk. O zaman istifadəçilər sevinirlər, çünki onlara qayğı göstərildiyini görür və dərhal kömək olunacağına inanırlar :)

Bu məqalə INFOSTART EVENT 2016 DEVELOPER konfransında oxunan hesabatın nəticələrinə əsasən yazılmışdır. Daha çox məqalə oxumaq olar.

2020-ci ildə biz hər kəsi 7 regional görüşdə, eləcə də Moskvada keçiriləcək yubiley INFOSTART EVENT 2020-də iştirak etməyə dəvət edirik.

Mobil müştərilərin dezavantajı serverdir.

Əlavə tələblər tətbiqin xüsusiyyətlərindən asılıdır:
server miqyası - SaaS, sosial proqramlar üçün, ideal olaraq, böyük bir ziyarətçi axını gözlənildikdə, bu şərt məcburidir. İstifadəçilərin sayına məhdudiyyətlərin olduğu və ya sayının proqnozlaşdırıldığı biznes proqramları üçün bu xüsusiyyət tələb olunmur;
interaktivlik: bir sıra tətbiqləri bildiriş mexanizmi ilə təmin etmək lazımdır - müəyyən hadisələrin baş verməsi barədə tətbiqə (istifadəçiyə) məlumat verin, istifadəçiyə mesaj göndərin. Bu əmlak, məsələn, mübadilə sistemi və ya avtomatik taksi dispetçerində olmalıdır.
açıq API: üçüncü tərəf tərtibatçılarının sənədləşdirilmiş protokol vasitəsilə sistemin funksionallığından istifadə edə biləcəyi güman edilir. Axı, müştəri ya mobil, ya da xarici server proqramı ola bilər.
digər tələblər...

Əmr

Sistemin inkişafı üçün layihə komandasının tərkibi ideal olaraq aşağıdakı kimi ola bilər:
layihə meneceri: layihəni idarə edir, ona nəzarət edir, müştəri ilə birbaşa əlaqə saxlayır;
server proqram tərtibatçısı: biznes məntiqi serveri, verilənlər bazası, şəbəkə protokolu hazırlayır;
administrator proqram tərtibatçısı: Veb proqram, server proqramını konfiqurasiya etmək və idarə etmək üçün istifadəçi interfeysi hazırlayır;
Android üçün müştəri proqram tərtibatçısı;
iOS müştəri proqram tərtibatçısı;
üçün müştəri proqram tərtibatçısı...
tester: admin tətbiqini və müştəri tətbiqlərini sınaqdan keçirir.

Diqqətli oxucu qeyd edəcək ki, qrafik interfeysi olan bir server proqramı yazsanız, məsələn, HTML5-də pula qənaət edə bilərsiniz. Bu halda, müştəri proqramlarının inkişafı tələb olunmur - istifadəçi interfeysi brauzer tərəfindən təmin edilir. Bu məqalədə belə bir hal nəzərdə tutulmur, söhbət mobil qurğular üçün “doğma” (doğma) proqramların hazırlanmasından gedir.

Mən tam heyətlə komandada işləmişəm, amma realist olacağam – heç də həmişə insan resursları və büdcə belə bir komanda yığmağa imkan vermir. Və bəzən rollar birləşdirilməlidir: layihə meneceri + server proqram tərtibatçısı, müştəri proqram tərtibatçısı + tester.

Texnologiyalar, alətlər, kitabxanalar

Mobil müştərilər üçün server hazırlamaq üçün mən adətən aşağıdakı "pulsuz" texnologiyalar yığınından istifadə edirəm:
Apache Tomcat servlet konteyneridir;
MySQL - DBMS;
Subversion versiyaya nəzarət sistemidir;
Maven - layihə qurmalarının avtomatlaşdırılması üçün çərçivə;
JUnit - təmin edəcək;
Apache Log4j - giriş kitabxanası;
Jenkins - davamlı inteqrasiya sistemi;
Hibernate - ORM (parametrlər, xassələrdə konfiqurasiya, xml faylları və qeydlər);
hibernate-generic-dao - Google-dan DAO-nun tətbiqi, verilənlər bazası məlumatları ilə işləmək üçün əsas üsulları həyata keçirir, üsullarda filtrləmə və çeşidləmənin həyata keçirilməsini asanlaşdırır;
- autentifikasiya və avtorizasiyanın həyata keçirilməsi (təhlükəsizlik), xidmətlər və lobya konteynerləri (xml fayllarında və annotasiyalarda konfiqurasiya), biz də testlər yaratarkən istifadə edirik.

Sistemin xüsusiyyətlərindən və ona olan tələblərdən asılı olaraq, məlumat mübadiləsi protokolunun həyata keçirilməsi üçün 2 variantdan birini istifadə edirəm.
Çarpaz platforma, performans, sadəlik, səmərəlilik, miqyaslılıq, açıq API tələb olunduqda, mən Jersey - REST Veb xidmətlərinin (RESTful Web xidmətləri) həyata keçirilməsini götürürəm. Bu kitabxana sizə JSON və/və ya XML məlumatlarının serializasiyasından istifadə etməyə imkan verir. REST konfiqurasiyası annotasiyalar vasitəsilə həyata keçirilir. Mobil cihazlarla mübadilə üçün JSON formatı müştəri tərəfində daha sadə tətbiqə malik olduğu üçün götürülüb (bu səbəbdən biz “klassik” Veb xidmətlərindən istifadə etmirik), daha az trafik yaranır. Jersey sizə ən uyğun JSON "görünüşünə" uyğunlaşmağa imkan verir.
Əks halda, əgər sizə çarpaz platforma, yüksək performans, sadəlik, səmərəlilik, interaktivlik lazımdırsa, mən
Apache MINA şəbəkə proqramları qurmaq üçün çərçivədir,
Google protobuf strukturlaşdırılmış məlumat kodlaşdırması və deşifrə kitabxanasıdır. Məlumat strukturu * .proto başlıq faylları ilə müəyyən edilir, kompilyator onlardan Java siniflərini yaradır (həmçinin digər proqramlaşdırma dilləri üçün generasiya imkanı var: C ++, Objective-C və s., çarpaz platforma təmin edir. əmlak);
java.util.concurrent - standart paketdən istifadə edirik.
Bu seçim miqyaslı ola bilər, lakin bu, biznes məntiqi nəzərə alınmaqla memarlıq səviyyəsində dizayn mərhələsində qoyulmalıdır.

Həqiqi SaaS xidməti üçün texnologiyaların seçilməsi nümunəsindən istifadə edərək hipotetik bir problemi nəzərdən keçirək - insanlara tələb olunan xidmətlərin və ya işlərin yerinə yetirilməsi üçün sifariş verməyə imkan verən "Auknem xidmətlərinin auksionu" və təşkilatlar öz növbəsində tərk edirlər. onlar üçün öz təklifləri. Biz standart olaraq bütün əsas tələbləri qəbul edirik. Bu sistemdə qeydiyyat pulsuz və pulsuz olduğundan, onlara miqyaslılıq əlavə etmək mütləq lazımdır. Bəs interaktivlik? Podratçıları (icraçıları) yeni sifarişlərin yaradılması haqqında məlumatlandırmaq və müştərilərə eyni anda daxil olan təkliflər barədə yalnız elektron poçtla deyil, ərizədə məlumat vermək çox yaxşı olardı. Bunun əsasında biz Apache MINA, Google protobufunun tətbiqini götürürük. Növbəti xüsusiyyətə baxırıq - açıq API. Xidmət ictimaiyyət üçün əlçatandır, ona görə də tutaq ki, xarici tərtibatçılar onunla inteqrasiya etməkdə maraqlı ola bilərlər. Bir dəqiqə gözlə! O qədər də sadə deyil. Apache MINA-ya əsaslanan protokol nüansları bilmədən həyata keçirməkdən və inteqrasiyadan tamamilə asılıdır. Belə bir vəziyyətdə hansı amilin daha vacib olduğunu ölçməli və seçim etməli olacaqsınız.

Nəticə

Bilmək istərdim ki, mobil qurğular və ya oxşar sistemlər üçün server hazırlayarkən hansı texnologiya və kitabxanalardan istifadə etmisiniz? Hər şey dəyişir, heç nə əbədi deyil, hər səviyyədə öz üstünlükləri və mənfi cəhətləri olan alternativlər var: MySQL -

Proqramın server tərəfinin inkişafı

Giriş

İnternet mövcudluğu bugünkü biznes üçün bir zərurət halına gəldi. Bunsuz müştərilərlə tam hüquqlu qarşılıqlı əlaqə qurmaq mümkün deyil. Çox vaxt belə bir problemi həll etmək üçün müştəri-server proqramlarının yaradılmasına müraciət edirlər. Onların hər biri müştəri tərəfi və Back-enddən ibarətdir. Son termin proqramın server tərəfinə aiddir. Gələcəkdə mobil proqramın məzmununu müstəqil şəkildə dəyişdirmək lazımdırsa, o zaman Back-end xüsusilə yüksək keyfiyyətlə yaradılmalıdır. Appomart verilən tapşırıqların tələblərə uyğun yerinə yetirilməsinə zəmanət verir. Buna görə də, server proqramlarının yaradılmasına sifariş verərkən, düzgün nəticəyə əmin ola bilərsiniz.

Back-end nə üçündür?

Müştəri-server proqramlarının inkişafı iki hissədən ibarətdir. Birinci, Front-end, istifadəçilərin sorğularını qəbul edir. Bu, müştərilərin mobil cihazlarının ekranlarından görünür. İkincisi, server proqramı, qəbul edilən sorğuları emal edir və inzibati panel rolunu oynayır. Burada verilənlər bazası, proqram məntiqi saxlanılır. Bu olmadan heç bir müştəri-server proqramı işləməyəcək. Əslində, Back-end proqramın ürəyidir. Bu, müştəri sorğularının işlənməsinə, tətbiqin sürətinə cavabdeh olan kəşfiyyatdır. Buna görə də, server proqramının arxitekturasının ən xırda təfərrüatlarına qədər düşünülmüş olması vacibdir ki, hətta yüksək yüklənmiş xidmətlər də rəvan və tez işləsin.

Proqramlaşdırma dilini necə seçmək olar?

Texniki tapşırığın hazırlanması zamanı (layihə üçün işçi sənədlərin bir hissəsi) memar verilənlər bazası sistemini və bağlantılarını layihələndirir, obyektləri və onların xassələrini təsvir edir, həmçinin lazımi server üsullarını (istifadə ediləcək sorğular) hazırlayır. serverə istinad edən mobil proqramlar).

Sənədləşmənin və tərk edilmiş layihələrin əhəmiyyəti

Appomart-a tez-tez bu və ya digər səbəbdən digər podratçılar tərəfindən tərk edilmiş müştərilər müraciət edirlər. Və biz başqasının, bəzən hətta səhv işləyən layihəsini götürürük, onun auditini həyata keçiririk və sonradan yoxlanılır və dəstəklənir. Müştəridən alınan mənbə kodunu və materialları öyrənmək prosesində, bir çox tərtibatçının layihənin ötürülməsi üçün əvəzolunmaz əmək xərcləri səbəbindən müştərini özlərinə bağlamaq üçün server üsullarını qəsdən sənədləşdirməməsi ilə qarşılaşırıq. server tərəfi üçün sənədlərin olmaması və bəzən sadəcə peşəkarlığın olmaması səbəbindən başqa bir tərtibatçıya dəstək olmaq. Bu fakt, təəssüf ki, təkcə kədərli deyil, həm də geniş yayılmışdır. Müştəri, bu halda, layihə dəstəyinin işləkliyini, rahatlığını və məqsədəuyğunluğunu mühakimə etmək mümkün olmamışdan əvvəl, mövcud layihə üçün sənədlərin hazırlanması, həmçinin mənbə kodunun auditi üçün pul ödəməlidir. Appomart işçiləri həmişə sonrakı istifadə üçün Postman və Swagger tərəfindən dəstəklənən formatda arxa uç metodlarının elektron sənədlərini saxlayırlar.

Müqavilə imzalamadan əvvəl podratçını necə yoxlamaq olar?

Sizi diqqətlə podratçı seçməyə və yalnız cəlbedici qiymətə deyil, həm də layihə ilə alacağınız sənədlərin siyahısına, həmçinin mənbə kodunun ötürülməsi şərtlərinə və kodun əhatə dairəsinə diqqət yetirməyə çağırırıq. şərhlərlə, verilənlər bazası sxemləri ilə (istər Mongo DB, istərsə də MySQL). Müvəffəqiyyətin açarı, bir qayda olaraq, işin hər bir mərhələsi başa çatdıqdan sonra sizə verilən materiallara olan tələbləri aydın şəkildə göstərən səlahiyyətli iş sənədlərinə çevrilir.

İnkişaf xüsusiyyətləri

Server tərəfi üçün PHP

Tətbiqlərin server tərəfinin yaradılması (söhbət proqram təminatı hissəsindən getdiyi üçün serverləri "hardware" və ya kompüterlər kimi qarışdırmamaq lazımdır) server tərəfində istifadə olunan proqramlaşdırma dilinin xüsusi peşəkar bacarıqlarını və biliklərini tələb edir. Müştəri-server proqramlarının nümunələrinə nəzər salsaq görərik ki, PHP populyardır. O, server proqramlarının inkişafında şəksiz liderdir. Dünya saytlarının yarıdan çoxu bu və ya digər konfiqurasiyada bu dildə yazılıb. PHP-ni inkişaf etdirmək və saxlamaq asandır və PHP-nin inkişafını sürətləndirmək üçün xüsusi çərçivələr mövcuddur.

Çərçivə

Çərçivə (proqram platforması) - layihəni daha çevik və genişlənə bilən abstraksiya səviyyələrini təşkil etmək və artırmaq üçün istifadə olunur. Bununla belə, başa düşmək lazımdır ki, layihənin işçi sənədlərinin dərin təhlili əsasında çərçivə düzgün seçilməlidir, onsuz keyfiyyətli məhsul hazırlamaq mümkün deyil.

Delphi, JAVA, Python

Back-end yaratmaq üçün istifadə olunan başqa dillər də var. Belə ki, Delphi mühitində yaradılmış server proqramları geniş yayılmışdır. Onun köməyi ilə proqram təkmilləşdirilmiş ayıklama alır, ətraf mühitdə unikal proqramlar yaratmaq da asandır, vizual yaradılış təmin edilir, bu da gözəl, başa düşülən və rahat interfeys yaratmağa imkan verir. Java server proqramları da populyarlıq qazanmışdır. Bunlar asanlıqla əlavə olunur, istənilən platformada asanlıqla yerinə yetirilir və layiqli təhlükəsizlik səviyyəsinə malikdir. Digər populyar dil Python-dur. Onun köməyi ilə server proqramları tez, sadəcə olaraq, ciddi xərclər olmadan yaradılır.

Yayılma

Korporativ mühitdə müştəri-server proqramlarının yaradılması tələb olunur. Çox vaxt belə proqramlar işçi qrupları və ya müəssisə daxilində informasiya sistemlərinin yaradılması üçün istifadə olunur. Müştəri ilə əlaqə saxlamaq üçün mobil proqramların böyük əksəriyyəti də oxşar arxitekturaya malikdir. Populyarlıq onunla bağlıdır ki, server imkanlarından istifadə şəbəkəyə yükü azaltmaqla yanaşı, sistemin idarə olunmasını və bütövlüyünü təmin etməyə imkan verir.

Android, iOS üçün yüksək keyfiyyətlə və vaxtında müştəri-server tətbiqi yaradacağıq

Açar təslim inkişaf

Appomart proqramçıları müxtəlif səviyyəli tapşırıqları yerinə yetirmək üçün təcrübəli və ixtisaslıdırlar. Biz sosial şəbəkələri, yüksək yüklü biznes layihələrini və ya kiçik startaplar üçün proqram təminatı hissəsini həyata keçirməkdə eyni dərəcədə yaxşıyıq. Lazım gələrsə, mövcud ehtiyac və tələblərə uyğun olaraq Android, iOS sistemləri ilə işləyən tətbiqin müştəri hissəsini yaradacağıq.

Appomart-da arxa tərəf

Proqramçılarımız müxtəlif texnologiyalarla işləyir və bunu eyni dərəcədə yaxşı edirlər. Appomart-da siz Java, PHP və Node.JS dillərində müştəri-server proqramı sifariş edə bilərsiniz. Optimal proqram performansını təmin etmək üçün sistem tələbləri hər bir layihə üçün ayrıca təhlil edilir. Gəlin sıfırdan müştəri-server Java, PHP və Node.JS tətbiqini yaradaq və ya təkmilləşdirmələr və yeniləmələr üçün mövcud olanı götürək. Yeni bir server hissəsinin hazırlanmasında və ya mövcud olanı dəstəkləməkdə maraqlısınızsa, işin dəyərinin və əməkdaşlıq variantlarının ətraflı hesablanması üçün sorğu buraxın.

Kateqoriyalar

Məşhur