Android Compose-first: ghid pentru echipele mobile

La Google I/O 2026 din această săptămână, Google a luat decizia pe care dezvoltatorii Android o așteptau de ani de zile. Jetpack Compose este acum modalitatea oficială și implicită de a construi interfața Android. Setul de instrumente View — lumea TextView, ListView, ConstraintLayout și Fragment pe care rulează marea majoritate a aplicațiilor de producție — se află în modul de întreținere. Primește doar corecții critice și nimic altceva.

Google a ales cuvintele cu grijă. Views nu sunt depreciate și nu există o dată de eliminare. Dar „modul de întreținere” are o semnificație precisă aici. Nicio funcționalitate nouă, nicio API nouă, iar orice nouă funcție UI din Android Studio este înghețată, inclusiv Layout Editor și Navigation Editor. Noile biblioteci Jetpack, documentația, codelaburile și exemplele vor fi Compose-first. Îndrumarea oficială este directă: construiți interfața nouă în Compose și convertiți ecranele existente pe măsură ce le modificați.

Am livrat aplicații Android native în domeniul sănătății, IoT și comerțului electronic de ani de zile, iar majoritatea au început ca proiecte bazate pe View. Deci aceasta este o decizie reală pentru multe echipe, nu doar un titlu de știre. Iată cum o interpretăm.

Riscul practic nu constă în faptul că aplicația ta se va strica. Nu se va întâmpla asta. Riscul este mai subtil. Codul sursă derivă liniștit spre o insulă nesusținută. Fiecare nouă capacitate Android, fiecare nou component Material, fiecare îmbunătățire a instrumentelor presupune acum Compose. O echipă care mai folosește Views în 2027 nu este în pericol — plătește pur și simplu un cost din ce în ce mai mare în soluții de avarie și funcționalități lipsă.

Instinctul de a „rescrie toată aplicația” este cel greșit. Am văzut rescrierea UI în stil big-bang blocată luni întregi și livrând regresii, iar Compose este construit pentru abordarea opusă. ComposeView și AndroidView permit Compose și Views să ruleze pe același ecran, chiar și în același layout. Poți converti un ecran, apoi o componentă, iar utilizatorii nu vor observa niciodată cusătura. Compose 1.11, prezentat tot la I/O, a îmbunătățit performanța specific pentru aceste ecrane hibride.

Există și un aspect legat de recrutare care este ușor de trecut cu vederea. Compose este ceea ce noii dezvoltatori Android învață acum. Candidații se așteaptă la el, iar documentația actuală îl presupune. O bază de cod dominată de View devine din ce în ce mai greu de completat cu personal, iar acel cost rămâne invizibil până când ajungi la trei luni într-o căutare.

Google a prezentat și un Android Studio Migration Assistant care folosește un agent AI pentru a porta ecranele, iar AI Studio poate genera acum aplicații Compose dintr-un prompt. Acestea vor ajuta. Dar din propria noastră experiență în integrarea agenților AI în fluxuri reale de livrare, lecția se repetă mereu: un agent care convertește un ecran este util doar dacă un dezvoltator care cunoaște Compose revizuiește rezultatul. Tratați o migrare generată ca pe o schiță, nu ca pe un rezultat final. Echipele care au de suferit sunt cele care lasă volumul de conversii să depășească capacitatea lor de revizuire.

Dacă întrețineți o aplicație Android bazată pe View, faceți un lucru concret în trimestrul acesta. Alegeți următorul ecran cu adevărat nou și construiți-l în Compose, de la capăt la capăt, cu interoperabilitatea conectată corespunzător. Nu un spike, ci un ecran pe care îl livrați efectiv. Acel singur exercițiu vă spune mai mult decât orice document de planificare: cum gestionează echipa voastră starea Compose, unde sistemul vostru de design are nevoie de echivalente Compose, cum face față configurația de build și test. Apoi stabiliți o regulă simplă. Fiecare ecran la care lucrați substanțial se convertește. Constant și fără surprize, și se acumulează.

Încă un lucru pentru echipele care lucrează atât pe iOS, cât și pe Android. Compose-first pe Android se aliniază cu poziția în care se află deja SwiftUI pe iOS. Ambele platforme se așteaptă acum la un strat UI declarativ, bazat pe stare. Dacă planificați lucrări native iOS și Android, acesta este un moment bun pentru a vă alinia arhitectura astfel încât cele două platforme să abordeze interfața UI în același mod. Aceasta face bazele de cod mai ușor de completat cu personal și mai ușor de revizuit — ceva ce am văzut că aduce beneficii în proiectele noastre mobile anterioare.

Aceasta nu este o urgență. Este o direcție. Platforma UI a Android are acum un standard clar, iar costul ignorării acestuia nu este un crash. Este o acumulare lentă de fricțiune.

Dacă un set de ecrane Android bazate pe View fără un plan clar de migrare vă sună cunoscut, hai să vorbim.