Mavzu : Android ot da dastur arxitekturasi, Android Java virtual mashina, Android ot da ilovalar yaratish, Android sdk unda ilova yaratish va uning rivojlanishi

Loyiha kodi mustaqil modullarga bo'linishi kerak, ular bir-biri bilan yaxshi moylangan mashina kabi ishlaydi - Chester Alvares fotosurati.
Androidni ishlab chiqish vositalarining ekotizimlari juda tez sur'atlar bilan rivojlanmoqda. Har hafta kimdir yangi vositalar yaratadi, mavjud kutubxonalarni yangilaydi, yangi maqolalar yozadi yoki nutq so'zlaydi. Agar siz bir oy davomida ta'tilga chiqsangiz, qaytib kelganingizda, u allaqachon nashr etiladi yangi versiya Qo'llab-quvvatlash kutubxonasi va/yoki Google Play xizmatlar.
Men so'nggi uch yil davomida ribot-da Android ilovalarini ishlab chiqdim va shu vaqt ichida ilovalarimiz arxitekturasi ham, biz foydalanadigan texnologiyalar ham doimo rivojlanib bordi va takomillashtirildi. Ushbu maqola sizni biz bosib o'tgan yo'ldan o'tkazadi, biz olgan saboqlar, biz qilgan xatolar va barcha bu me'moriy o'zgarishlarning sabablarini ko'rsatadi.
Yaxshi eski vaqtlar
2012-yilda loyihalarimiz tuzilishi juda oddiy ko‘rinardi. Bizda tarmoq kutubxonalari yo'q edi va AsyncTask hali ham bizning do'stimiz edi. Quyidagi diagrammada ushbu echimlarning taxminiy arxitekturasi ko'rsatilgan:


Kod ikki darajaga bo'lingan: REST API va turli xil mahalliy saqlashlar orqali olingan ma'lumotlarni qabul qilish / saqlash uchun javobgar bo'lgan ma'lumotlar qatlami (ma'lumotlar qatlami) va qayta ishlash uchun mas'ul bo'lgan taqdimot qatlami (ko'rish qatlami). va ma'lumotlarni ko'rsatish.
APIProvider Activities va Fragmentlarga REST API bilan o'zaro ta'sir qilish imkonini beruvchi usullarni taqdim etadi. Ushbu usullar URLConnection va AsyncTask-dan so'rovni fon oqimida bajarish va keyin natijalarni qayta qo'ng'iroq qilish funksiyalari orqali faoliyatga etkazish uchun foydalanadi. CacheProvider xuddi shunday ishlaydi: SharedPreferences yoki SQLite-dan ma'lumotlarni oladigan usullar mavjud va natijalarni qaytaradigan qayta qo'ng'iroq qilish funktsiyalari mavjud.
Muammolar
Ushbu yondashuvning asosiy muammosi shundaki, taqdimot qatlami juda ko'p mas'uliyatga ega. Keling, oddiy stsenariyni tasavvur qilaylik, unda ilova blog postlari roʻyxatini yuklab olishi, ularni SQLiteʼda keshlashi va keyin ularni ListViewʼda koʻrsatishi kerak. Faoliyat quyidagilarni amalga oshirishi kerak:

1. 
   APIProvider#loadPosts(Callback) usulini chaqiring.
   
2. 
   O'tkazilgan "e'ga qo'ng'iroq" da onSuccess() usuli chaqiruvini kuting va keyin CacheProvider#savePosts(Callback) ga qo'ng'iroq qiling.
   
3. 
   O'tkazilgan "qayta qo'ng'iroq"da onSuccess() usuli chaqirilishini kuting va keyin ma'lumotlarni ListView-da ko'rsating.
   
4. 
   Ikkitasini alohida davolang mumkin bo'lgan xatolar, bu APIProvider va CacheProvider da paydo bo'lishi mumkin.
   

Va bu yana bir oddiy misol. Haqiqiy hayotda, API ma'lumotlarni taqdimot qatlamimiz kutgan shaklda qaytarmasligi mumkin, ya'ni Faoliyat ular bilan ishlashdan oldin ma'lumotlarni qandaydir tarzda o'zgartirishi va/yoki filtrlashi kerak bo'ladi. Yoki, masalan, loadPosts() biror joydan olinishi kerak bo'lgan argumentni oladi (masalan, biz Play Services SDK orqali so'raydigan elektron pochta manzili). Shubhasiz, SDK manzilni qayta qo'ng'iroq qilish funksiyasi orqali asinxron tarzda qaytaradi, ya'ni bizda qayta qo'ng'iroq qilish funksiyalarini joylashtirishning uchta darajasi mavjud. Agar biz tobora ko'proq murakkablikni qo'shsak, biz qayta qo'ng'iroq qilish jahannami deb ataladigan narsaga duch kelamiz.
Keling, xulosa qilaylik:

• 
  Faoliyat va fragmentlar juda og'irlashib bormoqda va ularni saqlash qiyin
  
• 
  Yuvalashning juda ko'p darajalari kodning xunuk va o'qib bo'lmaydigan holga kelishiga olib keladi, bu esa yangi funksiyalarni qo'shish yoki o'zgartirishlar kiritishni qiyinlashtiradi.
  
• 
  Birlikni sinovdan o'tkazish qiyin (agar imkonsiz bo'lsa), chunki ko'p mantiq birliklarni sinab ko'rish uchun unchalik qulay bo'lmagan harakatlar yoki qismlarda.
  

RxJava bilan yangi arxitektura
Biz ikki yildan beri yuqorida tavsiflangan yondashuvdan foydalanamiz. Shu vaqt ichida biz tasvirlangan muammolardan og'riq va azob-uqubatlarni engillashtirgan bir nechta o'zgarishlarni amalga oshirdik. Misol uchun, biz bir nechta yordamchi sinflarni qo'shdik va harakatlar va fragmentlarni yuklash uchun ularga mantiqning bir qismini ko'chirdik, shuningdek, APIProvider da Volley-dan foydalanishni boshladik. Ushbu o'zgarishlarga qaramay, kodni sinab ko'rish hali ham qiyin edi va qayta qo'ng'iroq qilish jahannami vaqti-vaqti bilan u erda va u erda bo'lib o'tdi.
Vaziyat 2014 yilda, RxJava-da bir nechta maqolalarni o'qiganimizda o'zgara boshladi. Biz buni bir nechta sinov loyihalarida sinab ko'rdik va ichki qayta qo'ng'iroq qilish muammosining yechimi topilganga o'xshaydi. Agar siz reaktiv dasturlash bilan tanish bo'lmasangiz, ushbu kirishni o'qishni tavsiya qilamiz. Xulosa qilib aytganda, RxJava sizga asinxron oqimlar orqali maʼlumotlaringizni manipulyatsiya qilish imkonini beradi (bu holda biz oqimlarni oqim sifatida nazarda tutamiz, ularni iplar – bajarilish iplari bilan adashtirmaslik kerak) va oqimlarga oʻzgartirish, filtrlash uchun qoʻllanilishi mumkin boʻlgan koʻplab operatorlarni taqdim etadi. , yoki kerakli ma'lumotlarni birlashtiring.
So'nggi ikki yil ichida biz to'ldirgan barcha kamchiliklarni hisobga olgan holda, biz yangi ilovaning arxitekturasini o'ylashni boshladik va quyidagilarga keldik:


Kod hali ham ikki qatlamga bo'lingan: ma'lumotlar qatlami DataManager va yordamchi sinflar to'plamini o'z ichiga oladi, taqdimot qatlami Activity, Fragment, ViewGroup va boshqalar kabi Android SDK sinflaridan iborat.
Yordamchi sinflar (diagrammadagi uchinchi ustun) juda cheklangan mas'uliyat sohalariga ega va ularni izchil ravishda amalga oshiring. Masalan, ko'pgina loyihalarda REST API-lariga kirish, ma'lumotlar bazasidan ma'lumotlarni o'qish yoki uchinchi tomon SDK-lari bilan ishlash uchun sinflar mavjud. Turli xil ilovalar turli xil yordamchi sinflarga ega bo'ladi, lekin eng ko'p ishlatiladiganlari:

• 
  PreferencesHelper: SharedPreferences-dagi ma'lumotlar bilan ishlaydi.
  
• 
  DatabaseHelper: SQLite bilan ishlaydi.
  
• 
  REST API qo'ng'iroqlarini amalga oshiradigan xizmatlarni qayta jihozlash. Biz Volley o'rniga Retrofit-dan foydalanishni boshladik, chunki u RxJava-ni qo'llab-quvvatlaydi. Ha, va API yanada yaxshi.
  

Yordamchi sinflarning ko'plab ommaviy usullari RxJava Observables ni qaytaradi.
DataManager yangi arxitekturaning markaziy qismidir. U yordamchilardan olingan maʼlumotlarni birlashtirish, filtrlash va oʻzgartirish uchun RxJava operatorlaridan keng foydalanadi. DataManagerning vazifasi harakatlar va qismlarni ma'lumotlarni "tarash" ishidan ozod qilishdir - u o'zida barcha kerakli o'zgarishlarni amalga oshiradi va ko'rish uchun tayyor ma'lumotlarni beradi.
Quyidagi kod DataManager usuli qanday ko'rinishini ko'rsatadi. Bu shunday ishlaydi:

1. 
   Retrofit orqali postlar ro'yxatini yuklaydi.
   
2. 
   Ma'lumotlarni keshlash mahalliy ma'lumotlar bazasi DatabaseHelper orqali ma'lumotlar.
   
3. 
   Xabarlarni bugun chop etilganlar bo'yicha filtrlaydi, chunki taqdimot qatlami faqat ularni ko'rsatishi kerak.
   

ommaviy kuzatilishi mumkin LoadTodayPosts() ( mRetrofitService.loadPosts() ni qaytaring .concatMap(yangi Func1) () ( @Override public Observable Qo'ng'iroq (Ro'yxat ApiPosts) ( mDatabaseHelper.savePosts(apiPosts) ni qaytaring; ) )) .filtr(yangi Func1 () ( @Override ommaviy mantiqiy chaqiruv(Post post) (qaytish isToday(post.date); ) )); )
Taqdimot komponentlari shunchaki ushbu usulni chaqiradi va u qaytaradigan Observable-ga obuna bo'ladi. Obuna tugallangandan so'ng, natijada Observable tomonidan qaytarilgan xabarlar ularni RecyclerView yoki shunga o'xshash narsalarda ko'rsatish uchun adapterga qo'shilishi mumkin.
Ushbu arxitekturaning oxirgi elementi voqea avtobusi. Voqealar avtobusi bizga ma'lumotlar qatlamida sodir bo'lgan ba'zi hodisalar haqida xabarlarni yoqish imkonini beradi va taqdimot qatlamidagi komponentlar bu xabarlarga obuna bo'lishi mumkin. Misol uchun, DataManager'dagi signOut() usuli mos keladigan Kuzatiladigan o'z ishini tugatganligi haqida xabarni ishga tushirishi mumkin, so'ngra ushbu hodisaga obuna bo'lgan harakatlar foydalanuvchi tizimdan chiqqanligini ko'rsatish uchun foydalanuvchi interfeysini qayta chizishi mumkin.

Qanday muammolar qolmoqda?

• 
  Katta va murakkab loyihalarda DataManager juda shishib ketishi va uni saqlash qiyin bo'lishi mumkin.
  
• 
  Taqdimot qatlami komponentlarini (masalan, harakatlar va fragmentlar) engilroq qilib qo‘ygan bo‘lsak-da, ular hali ham RxJava obunasini boshqarish, xatolarni qayta ishlash va boshqalar atrofida aylanadigan adolatli mantiqni o‘z ichiga oladi.
  

Model ko'rinishida taqdimotchini sinab ko'rish
O'tgan yil davomida alohida me'moriy naqshlar Android hamjamiyatida MVP yoki MVVM sifatida mashhurlikka erisha boshladi. Ushbu naqshlarni sinov loyihasida, shuningdek, alohida maqolada o'rganib chiqqanimizdan so'ng, biz MVP loyihalarimiz arxitekturasiga mazmunli o'zgarishlar kiritishi mumkinligini aniqladik. Biz allaqachon kodni ikki qatlamga (ma'lumotlar va taqdimot) ajratganimiz sababli, MVP ning kiritilishi tabiiy ko'rinardi. Biz shunchaki taqdimotchilarning yangi darajasini qo'shishimiz va ko'rinishlardan ba'zi kodlarni unga ko'chirishimiz kerak edi.

Ma'lumotlar qatlami o'zgarishsiz qoladi, lekin hozir chaqiriladi model MVP dan mos keladigan daraja nomiga mos kelish uchun.