ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 149
Numărul 148 Numărul 147 Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 78
Abonament PDF

Componente de arhitectură în Android - Jetpack

Bogdan Hampu
Software developer @ 3Pillar Global



PROGRAMARE

Încă de la începutul apariției sistemului de operare Android, cele mai bune practici privind designul aplicațiilor și arhitecturile acestora au fost determinate exclusiv de comunitate, aceasta având un rol decisiv asupra modului în care dezvoltatorii și-au construit roadmapul către produsul finit. Putem observa cu ușurință o creștere foarte mare a comunității Android, care a condus inevitabil la dezvoltarea ecosistemului care s-a creat în jurul frameworkului.

Cu toate acestea, modul în care s-a realizat dezvoltarea aplicațiilor pentru platforma Android a evoluat lent. Au fost introduse noi cadre și au existat dezbateri permanente în acest sens, dar comunitatea a evitat să își asume impunerea unor seturi de reguli și standarde cu privire la modul în care ar trebui proiectate și dezvoltate aplicațiile. Este bine cunoscut faptul că de-a lungul anilor, ideologia celor de la Google în calitatea lor de companie, a fost să creeze produse de top, inovatoare, care să rezolve anumite probleme ale societății în care trăim, cu accent pe satisfacția utilizatorilor, fără să ofere întotdeauna îndrumarea necesară asupra direcției pe care ar trebui să o urmărească dezvoltatorii, lucrurile fiind lăsate să evolueze de la sine.

Nevoia existenței unui set de reguli care să facă dezvoltarea aplicațiilor mai ușoară, i-a împins pe cei de la Google să își schimbe filozofia și să găsească soluții pentru rezolvarea unor probleme comune cu care se confruntă dezvoltatorii. Contextul actual a permis ca în anul 2017, Google să introducă conceptul de Android Architecture Components (componente de arhitectură în Android), reprezentat de un set de librării ghidate de principiul separării diferitelor aspecte ale funcționalității (engl. SoC principle - Separation of Concerns), care să permită proiectarea și dezvoltarea unor aplicații modulare, codul fiind mai ușor de testat și de întreținut.

Acest concept a fost repede adoptat de comunitate, iar în ultimii doi ani, au fost rezolvate numeroase probleme introducându-se, totodată, funcționalități noi. Pentru a elimina codul redundant și pentru a simplifica complexitatea unor procese, dar și pentru a păstra compatibilitatea între diferitele versiuni de dispozitive și sisteme de operare existente, Google a decis să reorganizeze componentele de arhitectură și librăriile deja existente, într-o nouă colecție, numită Android Jetpack.

Ce este Android Jetpack?

Android Jetpack înglobează un set de componente, instrumente și soluții arhitecturale bine definite, care au ca scop accelerarea procesului de dezvoltare, reprezentând o actualizare majoră asupra modului în care se realiza dezvoltarea aplicațiilor mobile până la momentul respectiv. Fiecare dintre componentele regăsite în cadrul acestui concept arhitectural, a fost proiectată astfel încât să poată fi folosită independent, nefiind condiționată de utilizarea celorlalte componente sau de o anumită versiune a sistemului de operare, având astfel un grad foarte mare de flexibilitate și adaptabilitate.

Pornind de la introducerea componentelor de arhitectură și continuând cu Jetpack, cei de la Google au făcut un pas important în stabilirea unor reguli și principii asupra direcțiilor pe care fiecare dezvoltator trebuie să le urmeze. Având la bază aceste principii și aplicabilitatea lor, putem observa că Jetpack accelerează anumite etape din ciclul de viață al unui produs, precum dezvoltarea sau întreținerea codului. În cadrul echipelor și al comunităților de Android, procesle de internship sau onboarding au devenit facile, persoanele noi putând să dobândească mai ușor o viziune amplă asupra culturii din mediul respectiv, și asupra a ceea ce a devenit dezvoltarea aplicațiilor Android în zilele noastre.

Figura 1. Android Jeptack

După cum se poate observa în Figura 1, Android Jetpack este divizat în patru mari concepte:

Navigation

Navigarea între componentele vizuale ale unei aplicații Android a reprezentat întotdeauna o dificultate, fie că era vorba de legături multiple și complexe între modulele unei aplicații, fie că era vorba de gestionarea corectă a succesiunii pe stiva de activități. Cu scopul de a rezolva aceste probleme, a fost introdusă componenta de arhitectură Navigation, care vine în ajutorul dezvoltatorilor, oferindu-le un cadru vizual complex și manevrabilitate ridicată în ceea ce privește tranziția și transmiterea datelor între componente.

Pentru a facilita o navigare consistentă și predictibilă a utilizatorilor finali, la baza adoptării componentei Navigation, stă o serie de principii care oferă un cadru extins asupra direcției care ar trebui urmate de către dezvoltatori, printre care regăsim:

În cadrul Navigation, regăsim două concepte noi și anume cel de destinație (engl. destination) și acțiune (engl. action). O destinație reprezintă fiecare loc în care utilizatorul poate ajunge navigând prin aplicație. Mai multe destinații pot fi interconectate prin intermediul unor acțiuni. În general, o destinație este reprezentată de o componentă vizuală, fie ea activitate sau fragment.

Puse cap la cap, aceste elemente dau naștere unei structuri de graf orientat în care nodurile sunt reprezentate de destinații, iar drumurile dintre noduri de către acțiuni. Acest graf poartă numele de graf de navigare (engl. navigation graph) și poate fi manipulat utilizând editorul de navigare (engl. Navigation Editor), introdus în Android Studio 3.2 Canary.

Figura 2. Graf de navigare cu trei destinații Interconectate

În Figura 2 se poate observa un exemplu de dispunere vizuală a unui graf de navigare care conține trei destinații, interconectate prin acțiuni. Pe lângă vizualizare, ne este permis să manipulăm tranziția între anumite stări ale grafului, să adăugăm deeplink-uri în funcție de care aplicația să reacționeze, dar și să manipulăm argumentele care se doresc a fi trimise de la o destinație la alta. Toate aceste îmbunătățiri fac ca navigarea în cadrul unei aplicații Android să se realizeze mult mai ușor, eliminând codul redundant, având ca rezultat final o experiență plăcută a utilizatorilor finali.

Paging

O problemă des întâlnită în cadrul aplicațiilor Android este reprezentată de solicitarea și încărcarea cantităților mari de date pe ecran, aceasta putând avea un impact negativ asupra performanței. Soluțiile folosite inițial: secvențierea și consumarea unor cantități mai mici de date de la sursă, utilizarea unor liste specializate în cadrul aplicațiilor client (precum RecyclerView) și încărcarea graduală a datelor pe ecran manipulând capabilitățile de scroll ale acestora, s-au dovedit dificile pentru menținerea eficienței. Mai mult, deoarece logica care stă în spatele interacțiunii cu utilizatorul și a manipulării datelor devine foarte complicată, aceasta tinde să conducă pe termen lung la apariția problemelor de depanare și testare.

Componenta de arhitectură Paging vine ca o rezolvare pentru a prelua și a consuma eficient cantități convenabile de date, din surse diferite, economisind resursele de sistem și lățimea de bandă. Ideea centrală a acestei componente este de a manipula datele în structuri, numite pagini și de a le afișa cât mai rapid utilizatorului.

Cele mai importante concepte în jurul cărora a fost proiectată această componentă, sunt:

Fiind proiectată având la bază design patternul Observer și cu aplicabilitate directă cu alte concepte de interes și actualitate precum Room, LiveData și RxJava, componenta Paging, abstractizează comunicarea dintre anumite substraturi ale aplicației, făcând codul testabil și ușor de întreținut. S-a reușit standardizarea și eficientizarea procesului de preluare a datelor de la anumite surse și prezentarea lor utilizatorului, într-o manieră secvențială, cu scopul de a îmbunătăți experiența acestuia.

WorkManager

O direcție foarte importantă care ar trebui urmată și care stă la baza unei funcționări optime a oricărei aplicații mobile, este reprezentată de execuția asincronă în fundal, a anumitor taskuri de lungă durată, dereferențiate de firul principal de execuție responsabil de interfața grafică și de interacțiunea cu utilizatorul (engl. main thread - UI thread). Necesarul decuplării acțiunii propriu-zise de firul principal e dat de obligativitatea păstrării unui nivel de execuție cât mai scăzut pe acesta, pentru a nu periclita experiența utilizatorului. În caz contrar, dacă main threadul este încărcat cu diferite operații costisitoare, poate conduce la performanțe slabe și ulterior la blocarea aplicației.

Pentru operațiuni care nu afectează direct interfața cu utilizatorul și care ar putea deveni costisitoare în materie de timp, se recomandă folosirea unor fire de execuție separate. De-a lungul timpului, au fost introduse diferite mecanisme responsabile atât de realizarea în fundal a anumitor activități (ex: JobSchedulers, Services, Loaders, AlarmManager), cât și de eficientizarea consumului resurselor de sistem (ex: Doze mode, App standby, Background services limitation).

Componenta de arhitectură WorkManager a fost introdusă ca o soluție optimă pentru rezolvarea proceselor care trebuie executate cert, dar care pot fi amânate până la satisfacerea anumitor condiții.

Cele mai importante caracteristici care se regăsesc în cadrul componentei WorkManager, sunt:

Un obiect de tip WorkManager poate să execute sarcinile pentru care a fost proiectat, o singură dată sau periodic. Aceste două modalități de execuție sunt abstractizate folosind clasele OneTimeWorkRequest sau PeriodicWorkRequest. Mai multe obiecte de tip WorkRequest pot fi dispuse în paralel, astfel încât timpii de execuție a sarcinilor pe care trebuie să le ducă la bun sfârșit, poate fi redus exponențial. Dacă se dorește o execuție secvențială, atunci acestea pot fi înlănțuite, rezultatele obținute anterior putând fi pasate ca date de intrare pentru următorul obiect de tip WorkRequest din lanț. În continuare, am prezentat un simplu exemplu, scris în Kotlin, prin care mai multe obiecte de tip WorkRequest pot fi construite și trimise către execuție în paralel sau secvențial.

val request1 = OneTimeWorkRequest.Builder(DownloadImageWorker::class.java).build()
val request2 = OneTimeWorkRequest.Builder(ProcessImageWorker::class.java).build()
val request3 = OneTimeWorkRequest.Builder(DownloadImageWorker::class.java).build()
val request4 = OneTimeWorkRequest.Builder(ProcessImageWorker::class.java).build()

WorkManager.getInstance().beginWith(request1, request2).then(request3).then(request4).enqueue()

Figura 3. Exemplu de execuție în paralel și secvențială a unor sarcini de lucru, folosind WorkManager

Flexibilitatea și adaptabilitatea componentei WorkManager a permis ca anumite sarcini complexe, precum descărcarea unor fișiere de dimensiuni mari, procesarea imaginilor sau sincronizarea datelor în mod offline, să se poată realiza facil. Aceste sarcini pot fi combinate după bunul plac, astfel încât timpii de procesare să devină optimi, iar utilizatorul final să nu aibă de suferit în proces.

Concluzii

Putem spune că odată cu introducerea Jetpack și adoptarea lui rapidă de către comunitate, s-a realizat un pas foarte important pentru validarea și valorificarea ideologiei care stă la baza succesului pe care îl are frameworkul Android. Deși au fost introduse seturi de reguli și standarde noi cu privire la modul în care ar trebui proiectate și dezvoltate aplicațiile, acestea erau necesare, deoarece au standardizat procesele și au schimbat concepția dezvoltatorilor, deschizând noi orizonturi, care în trecut nu erau posibile.

Chiar dacă la început dezvoltatorii sunt reticenți cu privire la adoptarea tehnologiilor din cadrul Jetpack, iar dezvoltarea aplicațiilor poate părea greoaie, putem afirma că această trecere va reprezenta o etapă benefică în cariera oricărui programator. Experimentarea graduală a fiecăreia dintre componentele introduse, și nu numai, va permite dobândirea unor cunoștințe noi și va accelera procesul de dezvoltare, prin reducerea complexității și a dimensiunii codului, având un impact direct asupra utilizatorului final.

Bibliografie

https://developer.android.com/jetpack/

https://www.raywenderlich.com/5376-introduction-to-android-jetpack

https://android-developers.googleblog.com/2018/05/android-studio-3-2-canary.html

https://www.i-programmer.info/news/193-android/11792-jetpack-and-android-studio-32-not-much-new.html

https://www.raywenderlich.com/6040-workmanager-tutorial-for-android-getting-started

LANSAREA NUMĂRULUI 150

Noile tehnologii SAP ABAP

Marți, 10 Decembrie, ora 18:00

sediul MHP - A Porsche Company

Facebook Meetup StreamEvent YouTube

NUMĂRUL 149 - Development with AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects