Tizimli va amaliy dasturlashtirish

O’ZBEKISTON RESPUBLIKASI AXBOROT TEXNOLOGIYALARI VA KOMMUNIKATSIYALARINI RIVOJLANTIRISH VAZIRLIGI MUHAMMAD AL-XORAZMIY NOMIDAGI TOSHKENT AXBOROT TEXNOLOGIYALARI UNIVERSTETI

“TIZIMLI VA AMALIY DASTURLASHTIRISH” KAFEDRASI

“DASTURIY TA’MINOT QURILMASI VA EVOLYUSIYASI”
3 - AMALIY ISH
MAVZU: AXBOROT OQIMINING KOMPONENTLAR DIAGRAMMASI

Bajardi: Jahonov Asilbek

310-19 (guruh)
Tekshirdi: Sharipov Bahodir Akilovich
Savollar

1. 
   MVI arxitekturasi o’zi nima?
   
2. 
   MVI qanday ishlaydi?
   
3. 
   Afzalliklari va kamchiliklari
   

1. MVI arxitekturasi o’zi nima?
MVI “Model-View-Intent” degan ma’noni anglatadi. Bu pattern Android da yaqindagina paydo bo’lib, u Cycle.js frameworkidan ilhomlangan holda bir tomonlama va silindrli oqim printsipi asosida ishlaydi qilib yaratildi.
MVI har bir komponentining vazifasi nima ekanligini ko’rib chiqamiz:

• 
  Model: Boshqa pattern lardan farqli o’laroq, MVI modeli UI holatini ifodalaydi. Masalan, foydalanuvchi interfeysi turli xil state larga ega bo’lishi mumkin: Data Loading, Loaded, foydalanuvchi harakatlari bilan UI o’zgarishi, Error lar, foydalanuvchi ekranining hozirgi holati. Har bir state(holat) obyektga o’xshash tarzda saqlanadi.
  
• 
  View: MVI dagi View bu Activity va fragment larda implement qilinadigan Interface kabidir. Bu turli xil model state larini container da qabul qilib, ularni UI sifatida ko’rsatish deganidir. Foydalanuvchilarning harakatlariga javob berish uchun ular observable intents dan foydalanishadi (Eslatma: Bu Android ning asosiy tushunchasi Intentni anglatmaydi).
  
• 
  Intent: Garchi bu Android tomonidan ilgari aytilgan Intent bo’lmasa ham, foydalanuvchi harakatlarining natijasi Intent ga input qiymati sifatida beriladi. O’z navbatida, biz modellarni Intent larga input sifatida yuboramiz va ular View orqali ishga tushiriladi.
  

2. MVI qanday ishlaydi?

Foydalanuvchi biror bir harakatni bajarganda u Intent bo’ladi → Intent bu input model ko’rinishdagi state → Model state ni saqlaydi va so’ralgan stateni Viewga jo’natadi → View stateni Modeldan yuklaydi → va Userga shu tarzda ko’rsatadi. Agar biz yaxshilab e’tibor bersak, ma’lumotlar har doim user dan tarqaydi va qayta yana Intent orqali shu user bilan tugaydi. Buni boshqacha ko’rinishda bo’lishi mumkin emas, shuning uchun uni bir tomonlama arxitektura deb atashadi. Agar foydalanuvchi yana bir harakat qilsa, xuddi shu sikl takrorlanadi, demak buni Siklik jarayon deb atasak ham bo’ladi.

Afzallik va kamchiliklari

Afzalliklari:

• 
  Bu arxitekturada state ni saqlab qolish qiyin emas, chunki unda bor e’tibor state ga qaratilgan.
  
• 
  Bir tomonlama bo’lganligi sababli ham, ma’lumotlar oqimini osongina kuzatish va tahmin qilish mumkin.
  
• 
  Thread safety ni ta’minlaydi, chunki state obyektlar immutable(o’zgarmasdir).
  
• 
  Xatolik yuz berganda obyekt xolati aniq bo’lgani uchun ham, debug qilish ancha oson.
  
• 
  Har bir komponent o’z vazifasini bajargani uchun, ular alohida alohidaga ajratilgan.
  
• 
  Ilovani test qilib ko’rish ham ancha oson, chunki biz har bir state uchun biznes logika tuzishimiz mumkin.
  

Kamchiliklari

• 
  Bu arxitektura judayam ko’p kod yozishga majburlaydi, chunki biz har bir foydalanuvchi harakati uchun state ni saqlashimiz kerak.
  
• 
  Yuqorida ko’rganimizdek u barcha state lar uchun juda ko’p oyektlarni saqlashiga tog’ri keladi. Bu ilova xotirasini boshqarish uchun juda qimmatga tushadi.
  
• 
  Konfiguratsiya o’zgarishlarini ko’rib chiqish vaqtida alert state larni boshqarish qiyin bo’lishi mumkin. Masalan, agar Internet bo’lmasa, biz snackbarni ko’rsatamiz, konfiguratsiya o’zgarganda, u snackbarni yana Intent state sifatida ko’rsatadi. Qulaylik nuqtai nazaridan, buni hal qilish kerak.