Top 10 cele mai frecvente greșeli pe care le fac dezvoltatorii Android: un tutorial de programare

Android. Ce nu-i place la această platformă? Este gratuit, este personalizabil, este în creștere rapidă și este disponibil nu doar pe telefon sau tabletă, ci și pe ceasul inteligent, pe televizor și pe mașină.

Odată cu cea mai recentă actualizare Lollipop, programarea Android continuă să se îmbunătățească. Platforma s-a maturizat destul de mult de la lansarea inițială AOSP și a stabilit ștacheta așteptărilor utilizatorilor destul de sus. Uite cât de bine arată noul model Material design!

Există mii de dispozitive diferite, cu dimensiuni diferite de ecran, arhitecturi de cipuri, configurații hardware și versiuni de software. Din păcate, segmentarea este prețul de plătit pentru deschidere și există mii de moduri în care aplicația ta poate eșua pe diferite dispozitive, chiar și ca programator Android avansat.

Indiferent de o astfel de segmentare uriașă, majoritatea erorilor sunt introduse de fapt din cauza erorilor logice. Aceste erori sunt ușor de prevenit, atâta timp cât înțelegem corect elementele de bază!

Iată un tutorial de programare Android pentru a rezolva cele mai frecvente 10 greșeli pe care le fac dezvoltatorii Android.

Greșeala comună #1: Dezvoltarea pentru iOS

Spre marea mea plăcere, această greșeală Android este mult mai puțin frecventă în zilele noastre (parțial pentru că clienții încep să realizeze că vremurile în care Apple stabilea toate standardele de design au trecut de mult). Dar totuși, din când în când, vedem o aplicație care este o clonă iOS.

Nu mă înțelege greșit, nu sunt un evanghelist de programare Android! Respect fiecare platformă care mișcă lumea mobilă cu un pas înainte. Dar, este 2014 și utilizatorii folosesc Android de ceva vreme și s-au obișnuit cu platforma. Împingerea standardelor de design iOS la ele este o strategie groaznică!

Dacă nu există un motiv foarte bun pentru a încălca regulile, nu o faceți. (Google face asta tot timpul, dar niciodată prin copiere-lipire.)

Iată câteva dintre cele mai comune exemple ale acestei greșeli Android:

1. Nu ar trebui să faceți file statice și nu aparțin în partea de jos (vă arăt pe Instagram).
2. Pictogramele de notificare de sistem nu ar trebui să aibă culoare.
3. Pictogramele aplicațiilor nu trebuie plasate într-un dreptunghi rotunjit (cu excepția cazului în care acesta este logo-ul dvs. real, de exemplu Facebook).
4. Ecranele de introducere sunt redundante dincolo de configurarea/introducerea inițială. Nu le folosiți în alte scenarii.
5. Listele nu trebuie să aibă semne de simbol.

Acestea sunt doar câteva dintre multele alte lucruri mici care pot strica experiența utilizatorului.

Greșeala comună #2: Dezvoltarea pentru dispozitivul dvs. Android

Dacă nu construiți o aplicație chioșc/promoțională pentru o singură tabletă, sunt șanse ca aplicația dvs. Android să nu arate bine pe fiecare dispozitiv. Iată câteva sfaturi de programare Android de reținut:

• Pixelii independenți de densitate (dp) sunt diferiți de pixelii normali (px).
• Resursele sunt incluse de mai multe ori pentru a ține seama de diferite densități și orientări.
• Desenabilele cu 9 petice sunt întinse pentru a se potrivi pe ecran.

Există literalmente mii de scenarii posibile, dar după un timp vă dezvoltați simțul de a le acoperi pe toate cu o mână de cazuri.

Nu dețineți mii de dispozitive? Nici o problema. Emulatorul Android este foarte bun în replicarea dispozitivelor fizice. Și mai bine, încercați Genymotion, este fulgerător și vine cu o mulțime de dispozitive presetate populare diferite.

De asemenea, ai încercat să rotești dispozitivul? Tot iadul se poate dezlănțui...

Greșeala comună #3: Nu folosiți intenții

Intențiile sunt una dintre componentele cheie ale Android. Este o modalitate de a transmite date între diferite părți ale aplicației sau, chiar mai bine, diferite aplicații din sistem.

Să presupunem că aveți o aplicație de galerie care poate partaja un link de descărcare către unele imagini prin SMS. Care dintre cele două opțiuni pare mai logică?

Opțiunea 1:

• Solicitați permisiunea SEND_SMS.

   <uses-permission android:name="android.permission.SEND_SMS" />

• Scrieți propriul cod pentru a trimite SMS-uri folosind SmsManager .
• Explicați utilizatorilor de ce aplicația dvs. de galerie are nevoie de acces la servicii care pot costa bani și de ce trebuie să acorde această permisiune pentru a vă folosi aplicația.

Opțiunea 2:

• Porniți un SMS Intent și lăsați o aplicație concepută pentru SMS să facă treaba

   Intent sendIntent = new Intent(Intent.ACTION_VIEW); sendIntent.setData(Uri.parse("sms:" + telephoneNumber)); sendIntent.putExtra("sms_body", x); startActivity(sendIntent);

În cazul în care aveți îndoieli, cea mai bună soluție este opțiunea 2!

Această abordare poate fi aplicată aproape la orice. Partajarea de conținut, realizarea de fotografii, înregistrarea video, alegerea contactelor, adăugarea de evenimente, deschiderea legăturilor cu aplicații native etc.

Cu excepția cazului în care există un motiv întemeiat pentru a realiza o implementare personalizată (de ex., o cameră care aplică filtre), utilizați întotdeauna Intenții pentru aceste scenarii. Vă va economisi mult timp de programare și va elimina AndroidManifest.xml de permisiunile inutile.

Greșeala comună #4: Nu folosiți fragmente

Cu ceva timp în urmă, în Honeycomb, Android a introdus conceptul de fragmente . Gândiți-vă la ele ca blocuri de construcție separate cu propriile lor cicluri de viață (destul de complexe) care există în interiorul unei activități. Ajută foarte mult la optimizarea pentru diverse ecrane, sunt ușor de gestionat de activitatea parentală, pot fi refolosite, combinate și poziționate după bunul plac.

Lansarea unei activități separate pentru fiecare ecran de aplicație este teribil de ineficientă, deoarece sistemul va încerca să le păstreze în memorie atâta timp cât poate. Uciderea unuia nu va elibera resursele folosite de ceilalți.

Dacă nu doriți să explorați adânc în nucleul Android și să citiți acest articol, pledând împotriva utilizării fragmentelor, ar trebui să utilizați fragmente ori de câte ori este posibil. Practic spune că fragmentele și încărcătorul cursorului au un scop bun, dar o implementare slabă.

Greșeala comună #5: Blocarea firului principal

Firul principal are un singur scop: menținerea interfeței de utilizator receptivă.

Deși știința din spatele măsurării ratei de cadre pe care ochii/creierul nostru o poate percepe este complexă și influențată de o mulțime de factori, o regulă generală este că orice lucru sub 24 fps cu întârziere mai mare de 100 ms nu va fi perceput ca fiind neted.

Aceasta înseamnă că acțiunile utilizatorului vor avea un feedback întârziat, iar aplicația Android pe care ați programat-o nu va mai răspunde. Renunțarea utilizatorului de controlul său asupra aplicației duce la frustrare, utilizatorii frustrați tind să ofere feedback foarte negativ.

Și mai rău, dacă firul principal este blocat pentru o perioadă (5 secunde pentru Activități, 10 pentru Broadcast Receiver), se va întâmpla ANR.

Acest lucru a fost atât de comun în Android 2.x, încât la versiunile mai noi sistemul nu vă va permite să efectuați apeluri de rețea în firul principal.

Pentru a evita blocarea firului principal, utilizați întotdeauna fire de lucru/de fundal pentru: 1. apeluri în rețea 2. încărcare bitmap 3. procesare imagini 4. interogare baze de date 5. citire/scriere SD

Greșeala comună #6: Reinventarea roții

„OK, nu voi folosi firul principal. Îmi voi scrie propriul cod care comunică cu serverul meu într-un thread de fundal.”

Nu! Te rog nu face asta! Apelurile în rețea, încărcarea imaginilor, accesul la baza de date, analizarea JSON și autentificarea la rețele sociale sunt cele mai comune lucruri pe care le faceți în aplicația dvs. Nu doar a ta, ci fiecare aplicație de acolo. Există o cale mai bună. Vă amintiți cum s-a maturizat și a crescut Android ca platformă? Iată o listă rapidă de exemple:

1. Utilizați gradle ca sistem de construcție.
2. Utilizați Retrofit / Volley pentru apeluri în rețea.
3. Utilizați Picasso pentru încărcarea imaginilor.
4. Utilizați Gson / Jackson pentru analizarea JSON.
5. Utilizați implementări comune pentru autentificarea socială.

Dacă aveți nevoie de ceva implementat, sunt șanse să fie deja scris, testat și utilizat pe scară largă. Faceți câteva cercetări de bază și citiți câteva tutoriale de programare Android înainte de a vă scrie propriul cod!

Greșeala obișnuită #7: Nu asumarea succesului

Grozav. Am aflat că există o modalitate mai bună de a gestiona sarcinile de lungă durată și folosim biblioteci bine documentate în acest scop. Dar utilizatorul va trebui totuși să aștepte. Este inevitabil. Pachetele nu sunt trimise, procesate și primite instantaneu. Există o întârziere dus-întors, există erori de rețea, pachetele se pierd și visele sunt distruse.

Dar toate acestea sunt măsurabile. Apelurile reușite în rețea sunt mult mai probabile decât cele nereușite. Deci, de ce să așteptați răspunsul serverului înainte de a gestiona cererea cu succes? Este infinit mai bine să vă asumați succesul și să faceți față eșecului. Deci, atunci când unui utilizator îi place o postare, numărul de like-uri crește imediat și, în cazul puțin probabil în care apelul a eșuat, utilizatorul este notificat.

În această lume modernă este de așteptat un feedback imediat. Oamenilor nu le place să aștepte. Copiii nu vor să stea într-o sală de clasă pentru a obține cunoștințe care au profituri viitoare incerte. Aplicațiile trebuie să se adapteze la psihologia utilizatorului.

Greșeala comună #8: Nu înțelegerea bitmaps

Utilizatorii iubesc conținutul! Mai ales când conținutul este bine formatat și arată frumos. Imaginile, de exemplu, au un conținut extrem de frumos, în principal datorită proprietății lor de a transmite o mie de cuvinte pe imagine. De asemenea, consumă multă memorie. Multă memorie!

Înainte ca o imagine să fie afișată pe ecran, aceasta trebuie să fie încărcată în memorie. Deoarece bitmaps-urile sunt cea mai comună modalitate de a face acest lucru, vom oferi un ghid de programare Android pentru întregul proces:

Să presupunem că doriți să afișați pe ecran o imagine pe care tocmai ați făcut-o cu camera foto. Memoria totală necesară pentru aceasta se calculează cu următoarea formulă: memory_needed_in_bytes = 4 * image_width * image_height;

De ce 4? Ei bine, cea mai comună / recomandată configurație bitmap este ARGB_8888 . Asta înseamnă că pentru fiecare pixel pe care îl desenăm, trebuie să păstrăm în memorie 8 biți (1 octet) pentru canalul alfa, roșu, lăcomie și albastru, pentru a-l afișa corect. Există alternative, cum ar fi configurația RGB_565 , care necesită jumătate din memorie decât ARGB_8888 , dar își pierde transparența și precizia culorii (în timp ce poate adăuga o nuanță verde).

Să presupunem că aveți un dispozitiv nou-nouț cu ecran full HD și cameră de 12 MP. Fotografia pe care tocmai ați făcut-o este de 4000x3000 pixeli, iar memoria totală necesară pentru a o afișa este: 4 bytes * 4000 * 3000 = 48 MB

48 de megaocteți din RAM doar pentru o singură imagine!? Asta e mult!

Acum să luăm în considerare rezoluția ecranului. Încercați să afișați o imagine de 4000x3000 pe un ecran care are 1920x1080 pixeli, în cel mai rău caz (afișarea imaginii pe tot ecranul) nu ar trebui să alocați mai mult de 4 * 1920 * 1080 = 8.3 MB de memorie.

Urmați întotdeauna sfaturile de programare Android pentru afișarea eficientă a hărților de bit:

1. Măsurați vizualizarea în care vă afișați imaginile.
2. Scalați/decupați imaginea mare în consecință.
3. Arată numai ceea ce poate fi afișat.

Greșeala comună #9: Utilizarea ierarhiei Deep View

Aspectele au o prezentare XML în Android. Pentru a desena conținut, XML-ul trebuie analizat, ecranul trebuie măsurat și toate elementele trebuie plasate corespunzător. Este un proces care necesită resurse și timp care trebuie optimizat.

Acesta este modul în care funcționează ListView (și mai recent RecyclerView).

Dacă un aspect a fost umflat o dată, sistemul îl reutiliza. Dar totuși, umflarea aspectului trebuie să se întâmple la un moment dat.

Să presupunem că vrei să faci o grilă 3x3 cu imagini. O modalitate de a face acest lucru este un LinearLayout vertical care conține 3 LinearLayout -uri cu greutate egală, fiecare dintre ele conținând 3 ImageViews cu greutate egală.

Ce obținem cu această abordare? Un avertisment că „greutățile imbricate sunt dăunătoare pentru performanță”.

Există o vorbă în lumea programării Android, că tocmai am inventat: „Cu puțin efort, toată ierarhia poate fi aplatizată” .

În acest caz, RelativeLayout sau GridLayout vor înlocui eficient LinearLayouts imbricate.

Greșeala comună #10: Nu setarea minSdkVersion la 14

Ei bine, aceasta nu este o greșeală, dar este o practică proastă.

Android 2.x a fost o piatră de hotar uriașă în dezvoltarea acestei platforme, dar unele lucruri ar trebui lăsate în urmă. Suportul dispozitivelor mai vechi adaugă mai multă complexitate pentru întreținerea codului și limitează procesul de dezvoltare.

Cifrele sunt clare, utilizatorii au trecut mai departe, dezvoltatorii nu ar trebui să rămână în urmă.

Sunt conștient că acest lucru nu se aplică pentru unele piețe mari cu dispozitive vechi (ex. India), iar setarea minSdkVersion la 14, în aplicația Facebook, înseamnă să lăsați câteva milioane de utilizatori fără rețeaua lor socială preferată. Dar, dacă începeți din nou și încercați să creați o experiență frumoasă pentru utilizatorii dvs., luați în considerare eliminarea trecutului. Utilizatorii care nu au resursele sau care simt nevoia să-și actualizeze dispozitivul/OS nu vor avea stimulente să încerce o versiune superioară a aplicației pentru Android și, în cele din urmă, să cheltuiască bani pe ea.

Învelire

Android este o platformă puternică care evoluează rapid. Poate că nu este rezonabil să ne așteptăm ca utilizatorii să țină pasul, dar este esențial pentru dezvoltatorii Android să facă acest lucru.

Este și mai important să știi că Android nu este doar pe telefoanele sau tabletele noastre. Este pe încheieturile noastre, în camerele noastre de zi, în bucătăriile noastre și în automobile. Obținerea corectă a elementelor de bază este de cea mai mare importanță înainte de a începe să ne extindem.