I 10 errori più comuni commessi dagli sviluppatori Android: un tutorial di programmazione

Androide. Cosa non ti piace di questa piattaforma? È gratuito, è personalizzabile, è in rapida crescita ed è disponibile non solo sul tuo telefono o tablet, ma anche sul tuo smartwatch, TV e auto.

Con l'ultimo aggiornamento di Lollipop, la programmazione Android continua a migliorare. La piattaforma è maturata un po' dalla versione iniziale di AOSP e ha impostato la barra delle aspettative degli utenti piuttosto alta. Guarda com'è bello il nuovo modello di design Material!

Esistono migliaia di dispositivi diversi, con dimensioni dello schermo, architetture di chip, configurazioni hardware e versioni software diverse. Sfortunatamente, la segmentazione è il prezzo da pagare per l'apertura e ci sono migliaia di modi in cui la tua app può fallire su dispositivi diversi, anche come programmatore Android avanzato.

Indipendentemente da tale enorme segmentazione, la maggior parte dei bug viene effettivamente introdotta a causa di errori logici. Questi bug sono facilmente prevenibili, purché otteniamo le basi giuste!

Ecco un tutorial di programmazione Android per affrontare i 10 errori più comuni commessi dagli sviluppatori Android.

Errore comune n. 1: sviluppo per iOS

Con mio grande piacere, questo errore Android è molto meno comune al giorno d'oggi (in parte perché i clienti stanno iniziando a rendersi conto che i giorni in cui Apple stabiliva tutti gli standard di progettazione sono ormai lontani). Ma ancora, ogni tanto, vediamo un'app che è un clone iOS.

Non fraintendetemi, non sono un evangelista della programmazione Android! Rispetto ogni piattaforma che fa fare un passo avanti al mondo mobile. Ma è il 2014 e gli utenti utilizzano Android da un po' di tempo ormai e si sono abituati alla piattaforma. Spingere gli standard di progettazione iOS verso di loro è una strategia terribile!

A meno che non ci sia un ottimo motivo per infrangere le linee guida, non farlo. (Google lo fa sempre, ma mai copiando e incollando.)

Ecco alcuni degli esempi più comuni di questo errore Android:

1. Non dovresti creare schede statiche e non appartengono alla parte inferiore (ti sto indicando Instagram).
2. Le icone di notifica del sistema non dovrebbero avere il colore.
3. Le icone delle app non devono essere posizionate all'interno di un rettangolo arrotondato (a meno che non sia il tuo vero logo, ad es. Facebook).
4. Le schermate iniziali sono ridondanti oltre la configurazione/introduzione iniziale. Non usarli in altri scenari.
5. Le liste non devono avere i punti di accento circonflesso.

Queste sono solo alcune delle tante altre piccole cose che possono rovinare l'esperienza dell'utente.

Errore comune n. 2: sviluppo per il tuo dispositivo Android

A meno che tu non stia creando un'app kiosk/promo per un singolo tablet, è probabile che la tua app per Android non abbia un bell'aspetto su tutti i dispositivi. Ecco alcuni suggerimenti per la programmazione Android da ricordare:

• I pixel indipendenti dalla densità (dp) sono diversi dai pixel normali (px).
• Le risorse sono incluse più volte per tenere conto delle diverse densità e orientamenti.
• I drawable a 9 patch sono allungati per adattarsi allo schermo.

Ci sono letteralmente migliaia di possibili scenari, ma dopo un po' si sviluppa il senso di coprirli tutti con una manciata di casi.

Non possiedi migliaia di dispositivi? Non è un problema. L'emulatore Android è super efficace nella replica di dispositivi fisici. Ancora meglio, prova Genymotion, è velocissimo e viene fornito con molti diversi dispositivi preimpostati popolari.

Inoltre, hai provato a ruotare il dispositivo? Può scatenarsi l'inferno...

Errore comune n. 3: non utilizzare gli intenti

Gli intenti sono uno dei componenti chiave di Android. È un modo per trasferire dati tra diverse parti dell'app o, ancora meglio, diverse app sul sistema.

Supponiamo che tu abbia un'app galleria in grado di condividere un collegamento per il download ad alcune immagini tramite SMS. Quale delle due opzioni sembra più logica?

Opzione 1:

• Richiedi l'autorizzazione SEND_SMS.

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

• Scrivi il tuo codice per inviare SMS utilizzando SmsManager .
• Spiega ai tuoi utenti perché la tua app galleria ha bisogno di accedere a servizi che possono costare denaro e perché devono concedere questa autorizzazione per usare la tua app.

Opzione 2:

• Avvia un SMS Intento e lascia che un'app progettata per gli SMS faccia il lavoro

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

In caso di dubbi, la soluzione migliore è l'opzione 2!

Questo approccio può essere applicato a quasi tutto. Condividere contenuti, scattare foto, registrare video, selezionare contatti, aggiungere eventi, aprire collegamenti con app native, ecc.

A meno che non ci sia una buona ragione per realizzare un'implementazione personalizzata (ad es. una fotocamera che applica filtri), utilizzare sempre Intenti per questi scenari. Ti farà risparmiare un sacco di tempo di programmazione e AndroidManifest.xml dalle autorizzazioni non necessarie.

Errore comune n. 4: non utilizzare frammenti

Qualche tempo fa in Honeycomb, Android ha introdotto il concetto di frammenti . Considerali come elementi costitutivi separati con i loro cicli di vita (piuttosto complessi) che esistono all'interno di un'attività. Aiutano molto con l'ottimizzazione per vari schermi, sono facilmente gestiti dall'attività dei genitori, possono essere riutilizzati, combinati e posizionati a piacimento.

L'avvio di un'attività separata per ogni schermata dell'app è terribilmente inefficiente, poiché il sistema cercherà di mantenerli in memoria il più a lungo possibile. Ucciderne uno non libererà le risorse utilizzate dagli altri.

A meno che tu non voglia approfondire il core di Android e leggere questo articolo, sostenendo contro l'utilizzo dei frammenti, dovresti usare i frammenti quando possibile. Fondamentalmente afferma che i frammenti e i caricatori di cursori hanno un buon scopo previsto, ma una scarsa implementazione.

Errore comune n. 5: blocco del thread principale

Il thread principale ha un unico scopo: mantenere l'interfaccia utente reattiva.

Sebbene la scienza alla base della misurazione del frame rate che i nostri occhi/cervello possono percepire sia complessa e influenzata da molti fattori, una regola generale è che qualsiasi cosa al di sotto di 24 fps con un ritardo maggiore di 100 ms non sarà percepita come fluida.

Ciò significa che le azioni dell'utente avranno un feedback ritardato e l'app Android che hai programmato smetterà di rispondere. Togliere all'utente il controllo sull'app porta alla frustrazione, gli utenti frustrati tendono a dare un feedback molto negativo.

Peggio ancora, se il thread principale viene bloccato per un po' (5 secondi per le attività, 10 per i ricevitori di trasmissione), si verificherà ANR.

Questo era così comune in Android 2.x, che nelle versioni più recenti il ​​sistema non ti consente di effettuare chiamate di rete nel thread principale.

Per evitare di bloccare il thread principale, utilizzare sempre thread di lavoro/in background per: 1. chiamate di rete 2. caricamento di bitmap 3. elaborazione di immagini 4. query del database 5. lettura/scrittura SD

Errore comune n. 6: reinventare la ruota

“OK, non userò il thread principale. Scriverò il mio codice che comunica con il mio server in un thread in background."

No! Per favore, non farlo! Le chiamate di rete, il caricamento delle immagini, l'accesso al database, l'analisi JSON e l'accesso ai social sono le cose più comuni che fai nella tua app. Non solo la tua, tutte le app là fuori. C'è un modo migliore. Ricordi come Android è maturato e cresciuto come piattaforma? Ecco un rapido elenco di esempi:

1. Usa gradle come sistema di compilazione.
2. Usa Retrofit/Volley per le chiamate di rete.
3. Usa Picasso per il caricamento delle immagini.
4. Usa Gson / Jackson per l'analisi JSON.
5. Usa implementazioni comuni per l'accesso social.

Se hai bisogno di qualcosa implementato, è probabile che sia già scritto, testato e ampiamente utilizzato. Fai alcune ricerche di base e leggi alcuni tutorial di programmazione Android prima di scrivere il tuo codice!

Errore comune n. 7: non presumere il successo

Grande. Abbiamo appreso che esiste un modo migliore per gestire le attività di lunga durata e a tale scopo stiamo utilizzando librerie ben documentate. Ma l'utente dovrà ancora aspettare. È inevitabile. I pacchi non vengono inviati, elaborati e ricevuti istantaneamente. C'è un ritardo di andata e ritorno, ci sono errori di rete, pacchetti persi e sogni distrutti.

Ma tutto questo è misurabile. Le chiamate di rete riuscite sono molto più probabili di quelle non riuscite. Allora perché aspettare la risposta del server prima di gestire la richiesta riuscita? È infinitamente meglio presumere il successo e gestire il fallimento. Quindi, quando un utente apprezza un post, il conteggio dei Mi piace viene immediatamente aumentato e, nell'improbabile eventualità che la chiamata non sia riuscita, l'utente viene avvisato.

In questo mondo moderno ci si aspetta un feedback immediato. Alla gente non piace aspettare. I bambini non vogliono sedersi in una classe per acquisire conoscenze che hanno un futuro guadagno incerto. Le app devono adattarsi alla psicologia dell'utente.

Errore comune n. 8: non capire le bitmap

Gli utenti adorano i contenuti! Soprattutto quando il contenuto è ben formattato e ha un bell'aspetto. Le immagini, ad esempio, sono contenuti estremamente piacevoli, principalmente per la loro proprietà di trasmettere mille parole per immagine. Inoltre consumano molta memoria. Tanta memoria!

Prima che un'immagine venga visualizzata sullo schermo, deve essere caricata nella memoria. Poiché le bitmap sono il modo più comune per farlo, forniremo una guida alla programmazione Android per l'intero processo:

Supponiamo che tu voglia visualizzare sullo schermo un'immagine che hai appena scattato con la tua fotocamera. La memoria totale necessaria per questo viene calcolata con la seguente formula: memory_needed_in_bytes = 4 * image_width * image_height;

Perché 4? Bene, la configurazione bitmap più comune / consigliata è ARGB_8888 . Ciò significa che per ogni pixel che disegniamo, dobbiamo mantenere in memoria 8 bit (1 byte) per il canale alfa, rosso, avidità e blu, in modo da visualizzarlo correttamente. Ci sono alternative, come la configurazione RGB_565 che richiede metà della memoria rispetto ad ARGB_8888 , ma perde la trasparenza e la precisione del colore (mentre magari aggiunge una sfumatura verde).

Supponiamo che tu abbia un dispositivo nuovo di zecca con schermo Full HD e fotocamera da 12 MP. L'immagine appena scattata è grande 4000x3000 pixel e la memoria totale necessaria per visualizzarla è: 4 bytes * 4000 * 3000 = 48 MB

48 megabyte di RAM solo per una singola immagine!? Questo è molto!

Ora prendiamo in considerazione la risoluzione dello schermo. Stai cercando di mostrare un'immagine 4000x3000 su uno schermo con 1920x1080 pixel, nel peggiore dei casi (visualizzazione dell'immagine a schermo intero) non dovresti allocare più di 4 * 1920 * 1080 = 8.3 MB di memoria.

Segui sempre i suggerimenti di programmazione Android per visualizzare le bitmap in modo efficiente:

1. Misura la visualizzazione in cui stai mostrando le tue immagini.
2. Ridimensiona/ritaglia l'immagine grande di conseguenza.
3. Mostra solo ciò che può essere visualizzato.

Errore comune n. 9: utilizzo della gerarchia di visualizzazione approfondita

I layout hanno una presentazione XML in Android. Per disegnare il contenuto, l'XML deve essere analizzato, lo schermo deve essere misurato e tutti gli elementi devono essere posizionati di conseguenza. È un processo che richiede risorse e tempo che deve essere ottimizzato.

Ecco come funziona ListView (e più recentemente RecyclerView).

Se un layout è stato gonfiato una volta, il sistema lo riutilizza. Tuttavia, a un certo punto deve avvenire il gonfiaggio del layout.

Diciamo che vuoi creare una griglia 3x3 con le immagini. Un modo per farlo è un LinearLayout verticale contenente 3 LinearLayout con lo stesso peso, ciascuno contenente 3 ImageViews con lo stesso peso.

Cosa otteniamo con questo approccio? Un avvertimento che "i pesi nidificati sono dannosi per le prestazioni".

C'è un detto nel mondo della programmazione Android, che ho appena inventato: "Con poco sforzo tutta la gerarchia può essere appiattita" .

In questo caso RelativeLayout o GridLayout sostituirà in modo efficiente LinearLayouts nidificato.

Errore comune n. 10: non impostare minSdkVersion su 14

Bene, questo non è un errore, ma è una cattiva pratica.

Android 2.x è stata un'enorme pietra miliare nello sviluppo di questa piattaforma, ma alcune cose dovrebbero essere lasciate indietro. Il supporto di dispositivi meno recenti aggiunge maggiore complessità per la manutenzione del codice e limita il processo di sviluppo.

I numeri parlano chiaro, gli utenti sono andati avanti, gli sviluppatori non dovrebbero restare indietro.

Sono consapevole che questo non vale per alcuni grandi mercati con vecchi dispositivi (es. India) e impostare minSdkVersion su 14, sull'app di Facebook, significa lasciare un paio di milioni di utenti senza il loro social network preferito. Ma se stai ricominciando da capo e stai cercando di creare una bella esperienza per i tuoi utenti, considera di eliminare il passato. Gli utenti che non dispongono delle risorse o sentono il bisogno di aggiornare il proprio dispositivo/sistema operativo, non avranno l'incentivo di provare una versione superiore della tua app Android e alla fine spenderci dei soldi.

Incartare

Android è una piattaforma potente che si evolve rapidamente. Potrebbe non essere ragionevole aspettarsi che gli utenti tengano il passo, ma è fondamentale che gli sviluppatori Android lo facciano.

Sapere che Android non è solo sui nostri telefoni o tablet è ancora più importante. È ai nostri polsi, nei nostri soggiorni, nelle nostre cucine e nelle nostre automobili. Ottenere le basi giuste è della massima importanza prima di iniziare ad espanderci.