Dasturiy ta’minot qurilmasi va evolyusiyasi” fanidan 2 amaliy ish mavzu: axborot oqimining funktsional diagrammalari

2.3 “MVVM” arxitektura patterni, uning Android Developmentdagi o’rni
MVVM (Model-View-ViewModel) komponentalar orasidagi zich bog’lanishni yo’qotuvchi arxitektura hisoblanadi. Bu arxitekturada child(bola) to’g’ridan to’g’ri ota(parent)ga murojaat qila olmaydi, aksincha ular faqat observables orqali ma’lumotlarni olishadi.

• 
  Model — Android ilovaning ma’lumotlari va biznes logikasini aks ettiruvchi komponenta hisoblanadi. Biznes logika asosan lokal va server oqali keluvchi ma’lumotlar, model klasslar, repository lardan iborat.
  
• 
  View — bu komponentada UI uchun yoziladigan kod (Activity, Fragment), XML mavjud. U foydalanuvchi harakatini ViewModel ga yuboradi, lekin javobni to’g’ridan to’g’ri olmaydi. Javobni olish uchun esa u ViewModel tomonidan taqdim qilinadigan observables ga ulanishi kerak.
  
• 
  ViewModel — View va Model (biznes logika) o’rtasidagi ko’prik sifatida ko’riladi. View ga tog’ridan tog’ri aloqa yo’qligi sababli, ViewModel ularni qaysi biri undan foydalanayotganini bilmaydi. Demak ViewModel dan foydalanayotgan view haqida u hech qanday habarga ega bo’lishi shart emas. U Model bilan o’zaro aloqa qiladi va View tomonidan kuzatilishi mumkin bo’lgan observables ni taqdim etadi.
  

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.
  

3. 
   “Vazifalar menejeri” dasturiy ta’minot qismi