Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Android SDK
Code

Introduksyon sa Mga Bahaging Pang-arkitektura ng Android

by
Difficulty:IntermediateLength:LongLanguages:
This post is part of a series called Android Architecture Components.
Android Architecture Components: Lifecycle and LiveModel

Tagalog (Wikang Tagalog) translation by Anna Nelson (you can also view the original English article)

Ang Android ay ipinakilala sa mundo noong 2005 at nakamit ang kahanga-hangang tagumpay sa loob ng 12 taon ng pag-iral nito dahilan para kilalanin bilang pinaka-iniinstal na mobile OS. Sa panahong iyon, 14 na iba’t ibang bersyon ng operating system ang inilunsad, kasabay ang palagiang pag-unlad ng Android. Gayon pa man, isang napakaimportanteng aspeto ng plataporma ang patuloy na pinagsasawalang bahala: ang pamantayang modelong pang-arkitektural na may kakayahang pangasiwaan ang mga kakaibang aspeto ng plataporma at madaling maintindihan at magaya ng isang karaniwang debeloper.

Aba, mas maganda nang huli kaysa hindi kailanman. Noong huling Google I/O, ang Android team ay nakapagdesisyon na sa wakas na magsalita ukol sa problemang ito at tugunan ang mga feedback ng mga debeloper sa buong mundo. Naisagawa ito sa pamamagitan ng paghahayag ng opisyal na rekomendasyon para sa Android Application Architecture and pagbibigay ng pundasyon para ipatupad ito: ang bagong Architecture Components. At mas mabuti pa kaysa sa inaasahan, kinaya nilang gawin ito nang hindi nilalagay sa peligro ang pagiging bukas ng sistema na alam at mahal nating lahat.

Architecture Components

Sa tutoryal na ito, aalamin at sisiyasatin natin ang ginagawang pamantayang pang-arkitektura na binalangkas ng Android team at Google I/O at titignan ang mga pangunahing bahagi ng bagong Architecture Components: LifecycleViewModelLifeData, at Room. Hindi natin masyadong bibigyang pansin ang mga kowd sa halip ay magpopokus tayo sa mga kosepto at logiko sa likod ng mga temang ito. Titignan din natin ang ilang simpleng piraso na lahat ay isinulat gamit ang Kotlin, isang kahanga-hangang wika na ngayon ay opisyal na sinusuportahan ng Android. 

1. Ano Ang Nakalimutan ng Android?

Kung ikaw ay baguhan sa pa lamang pagiging debeloper, posibleng hindi mo alam kung ano ang mga sinasabi ko. Sabagay, ang pang-arkitekturang aplikasyon ay maaring isang malabong paksa sa una. Pero paniwalaan mo ako, matutunan mo ang kahalagahan nito maya-maya! Habang ang aplikasyon ay umuunlad at nagiging mas komplikado, ang arkitektura nito ay magiging mas importante.  Kaya nitong gawing mala-langit  o mala-impiyerno ang trabaho mo nang literal.

Ang Arkitektura ng Aplikasyon

Sa madaling salita, ang pang-arkitekturang aplikasyon ay hindi pabagu-bagong plano na kinakailangang gawin bago magsimula ang proseso ng pagdedebelop. Ang planong ito ang nagtatakda ng balangkas kung paano dapat pagsasama-samahin at gagawing organisado ang iba’t ibang bahagi ng aplikasyon. Ipinapakita din nito ang mga alituntunin na kailangang sundin sa panahon ng proseso ng pagdedebelop. Itinatampok din ng pang-arkitekturang aplikasyon ang paggawa ng ilang sakripisyo, na madalas ay may kaugnayan sa mgaklase at boilerplate, ay matutulungan ka sa huli na makabuo ng isang aplikasyon na mahusay na naisulat at mas nasusubok, napapalawak, at napapanatili. 

Ang software application architecture ay ang proseso ng pagtukoy sa binalangkas na solusyon na tumutugon sa lahat ng pangangailangang teknikal at operasyonal habang pinapabuti ang karaniwang kalidad ng mga katangian tulad ng paglilingkod, seguridad, at kakayahang mamahala. Kasali din dito ang serye ng mga desisyon base sa malawalk na sakaw ng mga salik. Bawat isa sa mga desisyong ito ay maaring mayroong malaking epekto sa kalidad, paglilingkod, pagpapanatili, at sa kabuuang tagumpay ng aplikasyon. 
— Ang Software Architecture at Gabay sa Disenyo ng Microsoft 

Maraming salik ang isinasaalang-alang ng magandang arkitektura lalo na ang katangian at limitasyon ng sistema. Sari-saring solusyong pang-arkitektura na may kanya-kanyang kalamangan at kahinaan ang nariyan. Gayon man, ilan sa mga importanteng konsepto ay pare-pareho sa lahat.  Sari-saring solusyong pang-arkitektura na may kanya-kanyang kalamangan at kahinaan ang nariyan. Gayon man, ilan sa mga importanteng konsepto ay pare-pareho sa lahat. 

Mga Dating Pagkakamali

Hanggang noong huling Google I/O, ang sistema ng Android ay hindi nagrekomenda ng kahit anong partikular na kayarian para pagpapa-unlad ng aplikasyon. Ibig sabihin nito ay pwedeng –pwede kang kumupkop nang libre ng kahit anong modelo ang mayroon tulad ng MVP, MVC, MVPP, o kahit na diretsyahang walang sinusundang pattern. Kaugnay nito, ang balangkas ng Android ay hindi man lang nagbigay ng solusyon para sa mga problemang ginawa mismo ng sistema partikular na ang lifecycle ng parteng bumubuo nito.

Great news at the Google IO 2017

Kaya kung ginusto mong kukupin ang Model View Presenter pattern sa iyong aplikasyon, kinailangan mong mag-isip ng iyong sarili solusyon mula sa wala, magsulat ng napakaraming kowd ng boilerplate, o kumupkop ng librerya na walang opisyal na suporta. Napakaraming aplikasyon ang pangit ang pagkakagawa na may mga codebase na mahirap panatilihin at suriin ang naging bunga ng kawalan ng pamantayan.

Gaya ng sinabi ko, maraming taon nang pinupuna ang sitwasyong ito. Sa katunayan, sumulat ako ngayon-ngayon lang sa seryeng pinamagatang How to Adopt Model View Presenter on Android tungkol sa problemang ito at kung papaano ito tutugunan. Ngunit ang importe ay matapos ang 12 taon, ang Android team sa wakas ay nagdesisyong pakinggan ang ating mga mga reklamo at tulungan tayo sa pagresolba sa problemang ito.

2. Ang Android Architecture

Ipinaliliwanag ng bagong Android Architecture Guide ang ilang pangunahing detalye na kinakailangang sundin ng isang mainam na Android aplikasyon. Bukod pa dito, iminungkahi din nito ang isang tiyak at siguradong gabay na susundan ng debeloper upang makalikha ng mahusay na aplikasyon. Ganon man, lantarang sinasabi ng gabay na hindi naman sapilitang kailangang sundin ang iprinisintang mga hakbang. Bagkus, personal na desisyon na ng debeloper kung gusto niyang kupkupin at sundin ang lahat ng mga ibinigay na mga hakbang. Maaari din namang pumili ng kahit anong klase arkitektura  ang naising sundin ng debeloper.

Ayon sa patnubay, ang mainam na Android application ay dapat magtakda ng paghihiwalay ng interest at ibahin ang UI mula sa modelo. Ang kahit anong kowd na hindi kayang pangasiwaan ang interaksyon ng UI o ng operating system ay hindi dapat ilagay sa Activity o sa Fragment sapagkat maiiwasan ang maraming problemang kaugnay ng lifecyle kung papanatilihin silang palaging malinis.  Matapos ang lahat, maaaring sirain ng sistema ang Activities o Fragments kahit anong oras. Ang mga datos ay dapat pangasiwaan ng mga modelo na nakahiwalay mula UI, samakatwid mula sa mga isyu ukol sa lifecyle.

Ang Bagong Nirekomendang Arkitektura

Ang arkitektura na inirerekomenda ng Android ay hindi basta-basta maihahanay sa mga alam nating pamantayang modelo. Kahalintulad nito ang itsura ng Model View Controller pattern ngunit ito din ay may malaking kapagkakahawig sa arkitektura ng sistema na mahirap pangalanan ang bawat parte gamit ang mga kilalang kombensyon. Bagaman hindi ito nauukol sa paksa, ang importante ay ito ay umaasa sa bagong Architecture Components para makagawa ng pagbubukod ng interest na may mahuhusay na abilidad sa pagsusuri at pagpapanatili. At mas maganda pa, madali itong maisasagawa.

Para maintindihan kung ano ang iminumungkahi ng Android team, kinakailangan nating alamin ang lahat ng bahagi ng Architecture Components dahil ang mga ito ang tutulong sa atin sa pag-intindi sa mga komplikadong konsepto. Mayroong apat na bahagi at bawat isa sa mga ito ay may partikular na tungkulin:RoomViewModelLiveData, at Lifecycle. Lahat ng mga bahaging ito ay may kanya-kanyang tungkulin at sama-samang nagtatrabaho upang makalikha ng isang matibay na arkitektura. Upang maintindihan pa lalo natin ang iminungkahing arkitektura, halina’t tignan natin pinasimpleng diyagram nito.

Android Architecture

Gaya ng iyong nakikita, mayroon tayong tatlong bahagi na bawat isa ay may sariling responsibilidad.

  1. Kinakatawan ng Activity at Fragment ang View layer na walang kinalaman sa lohika ng negosyo at sa mga komplikadong operasyon. Isinasa-ayos lamang nito ang view, pinangangasiwaan ang interaksyon ng user, at ang pinakaimportante sa lahat,  inoobserbahan at ipinapakita ang mga element ng LiveData na nagmula sa ViewModel. 
  2. Ang ViewModel ay awtomatikong inoobserbahan ang kalagayan ng Lifecycle ng view habang pinananatili ang kabuuan tuwing nagbabago ang konpigurasyon at iba pang pangyayari sa Lifecyle ng Android. Kinakailangan din nito ng view upang kumuha ng datos mula sa Repository na siya namang ibinibigay gaya ng naoobserbahang LiveData. Importanteng maintindahan na ang ViewModel ay hindi kailanman direktang sumasangguni sa View at ang mga update sa datos ay palaging ginagawa ng LiveData entity.
  3. Ang Repository ay hindi espesyal na bahagi ng Android. Ito ay isang simpleng klase na walang partikular na pagsasakatuparan at siya ding bahala sa pagkuha ng datos mula sa lahat ng maaaring pagkunan, mula sa database at sebisyo mula sa web. Ito ang namamahala sa lahat ng mga datos na ito. Ilan sa paraan ng pamamahala ay ang pagpapalit-anyo sa mga datos upang maging nao-obserbang LiveData at upang magamit ito ng ViewModel.
  4. Ang Room database ay isang SQLite mapping library na nangangasiwa sa proseso ng pakikitungo sa database. Ito ay kusang nagsusulat ng napakaraming boilerplate, nagrerepaso ng mga kamalian sa oras ng pagtatala, at higit sa lahat ay kaya nitong direktang ibalik ang mga tanong na may nao-obserbahang LiveData.

Sigurado akong napansin mo na na napag-usapan natin nang masinsinanang tungkol sa mga nao-obserbahan. Ang Observer Patter ay isa sa mga pundasyon ng elemento ng LiveData at ng kaugnay na bahagi ng Lifecycle. Pinahihintulutan ng pattern na ito ang isang bagay na abisuhan ang listahan ng mga tagamasid tungkol sa kahit anong pagbabago sa kalagayan at datos nito. Kaya kapag ino-obserbahan ng Activity ang LiveData entity, ito ay makakatanggap ng mga update kapag sumailalim sa kahit anong pagbabago ang datos.

Isa pang rekomendasyon ng Android ay ang pagpapatatag ng arkitektura nito gamit ang sistema ng Dependency Injection katulad ng sa Google Dagger 2 o gamit ang Service Locator pattern na di hamak na mas simple kaysa DI ngunit wala lang masyadong benepisyo. Hindi natin pag-uusapan ang DI o ang Service Locator sa tutoryal na ito pero ang Envato Tuts+ ay may ilang mga mahuhusay na tutoryal tungkol dito.  Gayunpaman, mabuti nang malaman mo na ipapaliwanag sa ikalawang bahagi ng seryeng ito ang ilang partikularidad ng pagtatrabaho sa Dagger 2 at Android Components. 

3. Architecture Components

Kinakailangan nating suriin at pag-aralang mabuti ang mga aspeto ng mga bagong parte upang lalong maintindihan at maka-angkop sa modelong pang-arkitektura nito. Datapwa’t, hindi natin bibigyang pansin ang lahat ng mga detalye sa tutoryal na ito.  Dahil sa pagiging komplikado ng bawat bahagi, pag-uusapan natin ang tungkol lamang sa kabuuang ideya sa likod ng bawat isa at tignan ang ilang pinasimpleng parte ng koda sa tutoryal na ito.  Susubukan nating talakayin ang sapat na impormasyon na magpapakilala sa mga parte upang makapagsimula ka na. Subalit huwag kang mangamba, dahil sa mga susunod na artikulo sa seryeng ito ay sisiyasatin natin nang mabuti at tatalakayan ang lahar ng partikularidad ng Architecture Components.

Mga Bahaging may Kinalaman sa Lifecyle

Karamihan sa mga bahagi ng Android app ay may mga lifecycle na kaugnay ng mga ito at siya din namang direktang nangangasiwa sa sistema.  Noon, desisyon ng debeloper kung imomonitor niya ang kalagayan ng bahagi at kung aaksyunan ito habang sinisiguro niya na sinisimulan at tinatapos niya ang trabaho sa tamang oras. Subalit talagang madaling malito at makagawa ng pagkakamali sa ganitong klase ng operasyon. Pero binago ito lahat ng parsela ng android.arch.lifecycle.

Ang Activities at Fragments ay may Lifecycle object na nakakabit sa kanila ngayon na pwedeng mabantayan gamit ang mga uri ng LifecycleObserver gaya ng ViewModel o kahit anong obdyek na nagsasagawa ng ganitong interface. Ibig sabihin nito ay ang obserber ay makakatanggap ng mga update tungkol sa mga pagbabago sa lagay ng obdyek na inoobserbahan tulad kung ang Activity ay nahinto o kung ito ay nagsisimula.  Kaya din nitong i-tsek ang kasalukuyang lagay ng inoobserbahang obdyek. Kaya ngayon ay higit na mas madali nalang pangasiwaan ang mga operasyon na kailangang isaalang-alang  ang balangkas ng mga lifecycle.

LifecycleObserver reacts to LifecycleEvents

Sa ngayon, kinakailangan mong palawakin ang Activity o Fragment para makagawa ng LifecycleActivity o LifecycleFragment na sumusunod sa bagong pamantayan. Ngunit dahil ang Android team ay naglalayong tuluyang pagsama-samahin ang mga bagong gamit sa kanyang balangkas, posibleng ito ay hindi palaging kakailanganin.

Ang LifecycleObserver ay nakakatanggap ng mga pangyayari sa Lifecycle  at pwedeng sumagot  sa pamamagitan ng anotasyon o komentaryo. Kinakailangang walang susuway sa kahit anong paraan. 

Ang LiveData Component

Ang bahagi na LiveData ay ang may hawak ng datos na naglalaman ng halaga na maaaring obserbahan. Kung ang nago-obserba ay naglaan ng Lifecycle noong kasalukuyang  nagbibigay ng halimbawa ang LiveData, ang LiveData ay kikilos nang naaayon sa kalagayan ng Lifecycle. Kung ang kalagayan ng Lifecycle ng tagamasid ay STARTED o RESUMED, ang tagamasid ay aktibo; kung hindi naman, ang tagamasid ay hindi aktibo.

Nalalaman ng LiveData kung ang datos ay napalitan at kung ang tagamasid ay aktibo at kailangang tumanggap ng update. Isa pang kawili-wiling katangian ng LiveData ay ang kakayahan nitong mag-alis ng tagamasid kung ang kalagayan nito ay Lifecycle.State.DESTROYED dahilang upang naiiwasan ang mga memory leak ng Activities at Fragments.

LiveData value updating process

Ang LiveData ay dapat isagawa ang paraan ng onActive at onInactive.

Para obserbahan ang bahagi na Livedata, kinakailangan mong tumawag ng observer (LifecycleOwner, Observer<T>).

The ViewModel Component

Isa sa mga pinakaimportanteng mga klase ng bagong Architecture Components ay ang ViewModel na idinisenyo para hawakan ang datos na konektado saUI para mapanatili ang integridad nito sa tuwing may mga pagbabagong nagaganap gaya ng pag-ikot ng iskrin. Ang ViewModel ay may kakayahang makipag-usap sa Repository para makuha ang LiveData mula dito at gamitin ito bilang ganti para maobserbahan ito ng view.  Hindi kinakailangan ng ViewModel na tumawag muli sa Repository matapos ang pagbabago sa konpigurasyon na siyang dahilan upang lubos na magamit sa kowd.

ViewModel is tight to UI Lifecycle

Upang makalikha ng view model, palawigin ang klase na ViewModel.

Para ma-access mula sa view, pwede mong tawagan ang ViewProviders.of(Activity|Fragment).get(ViewModel::class). Ang pamamaraang ito ay mababalik ng bagong halimbawa ng ViewModel o papanatilihin ang dati kung naaangkop.

Ang Room Component

Sinuportahan ng Android ang SQLite sa umpisa pa lang. Gayun man, upang mapagana ito, parating kinakailangang sumulat ng sandamakmak na boilerplate. Hindi din nai-save ng SQLite ang POJOs (lumang Java obdyek) at hindi din nito nasuri ang mga tanong noong oras ng pagtatala.  At dumating na nga ang Room upang bigyang kasagutan ang mga isyung ito! Ito ay SQLite mapping library na mga kakayahang patuloy na tumatanggap ng Java POJOs, direktang nagsasalin ng mga tanon sa obdyeks, nagsusuri ng mga kamalian tuwing oras ng pagtatala, at gumagawa ng LiveData observables mula sa mga resulta ng tanong. Ang Room ay isang Object Relational Mapping library na may ilang kahanga-hangang dagdag mula sa Android.

Hanggang ngayon, pwede mong gawin ang halos lahat ng kayang gawin ng Room gamit ang ibang ORM Android libraries ngunit wala sa kanila ang may opisyal na suporta. Dagdag pa ditto, ang pinakaimportanteng pagkakaiba ay hindi nila kayang  makapagprodyus ng mga resulta ng LiveData. Tamang-tama ang Room library bilang kasalukuyang layer na iminungkahi ng Android Architecture.

Upang makagawa ng Room database, kinakailangan mo ng @Entity gaya ng Java POJO para magpatuloy, @Dao interface para gumawa ng mga tanong at mga operasyon ng input/ output, at @Database abstract class na magpapalawig sa RoomDatabase.

Pagdadagdag ng Architecture Components sa Iyong Proyekto

Sa ngayon, para magamit ang bagong Architecture Components, kinakailangan mo munang idagdag ang repository ng Google sa iyong build.grandle file. Para sa ibang detalye, tignan ang opisyal na patnubay.

Konklusyon

Gaya ng iyong nakikita, ang ginagawang pang-arkitekturang pamantayan ng Android ay napapalooban ng napakadaming konsepto. Huwag munang umasa na maiintindihan nang ganap ang paksang ito. Matapos ang lahat, ipinakilala pa lamang naman namin ang temang ito. Subalit siguradong ngayon ay mayroon ka ng sapat na kaalaman upang maintindihan ang logiko sa likod ng arkitektura at ang mga papel ng iba’t ibang Architecture Components.

Napag-usapan natin ang tungkol sa halos lahat ng mga tema na may kaugnayan sa iminungkahing Android Architecture at ang mga bahagi nito. Gayunpaman, ang mga detalye ukol sa pagpapatupad ng mga bahaging ito at iba pang ekstra tulad ng Respository class at sistema ng Dagger 2 ay hindi natalakay sa unang parte ng serye. Sisiyasatin natin ang mga tema iyon sa mga susunod na artikulo.

Hanggang sa muli!

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.