2012-10-31 11 views
15

Sto sviluppando un'applicazione per tablet da 7 pollici Kindle Fire HD e Nexus 7. Queste due applicazioni hanno le stesse dimensioni e la stessa risoluzione dello schermo. Tuttavia, eseguo la mia applicazione, è molto diversa. Perché?Nexus 7 e Kindle Fire HD, penso diverso

sembra che questo sia perché il nesso 7 viene rilevato come TVDPI, e il Kindle Fire HD è HDPI. Come avere uno stesso rendering basato su un modello 1280 * 800?

Grazie

+0

Interessante, puoi fornirci SS che mostra le differenze (so che potrebbe essere difficile visto che stai sviluppando il progetto)? – Warpzit

+0

Nexus7 mostra l'app come dovrebbero essere i tuoi layout predefiniti? [Ed Burnette] (https://plus.google.com/106300001086744879268/posts/Wa9xtQjZHJx) ha parlato di un problema relativo alle risoluzioni TVDPI e in particolare a Nexus7. Immagino che Nexus stia ottenendo il layout predefinito. – Korcholis

+0

Avremmo bisogno di sapere "cosa sembra diverso" esattamente per aiutarti. –

risposta

25

Bene, sembra che hai già scoperto il motivo per cui i due hanno differenze, è perché riportano diversi fattori di scala densità:

  • Nexus 7: TVDPI: Fattore di scala = 1.333
  • Kindle Fuoco HD: HDPI: Fattore di scala = 1,5

Quindi perché riportano in modo diverso quando tecnicamente hanno le stesse dimensioni fisiche e risoluzione?

Il problema CORE esiste in realtà perché un dispositivo è un dispositivo Google Play (Nexus) e l'altro no (Kindle). Tutti i dispositivi Android dotati di Google Play (e di altre app Google) possono farlo solo passando qualcosa chiamato Compatibility Test Suite (CTS), che verifica che impostazioni come questa siano conformi agli standard che hanno presentato. Gli standard stessi sono documentati in un documento di compatibilità (CDD) per ogni versione. Here is a link to the CDD for Android 4.0 (la sezione 7.1 riguarda le dimensioni e la densità dello schermo). Il CDD dice a un produttore di dispositivi che dovrebbero segnalare il fattore di scala che è numericamente più vicino al DPI attuale dello schermo, che in realtà è TVDPI in questo caso.

I dispositivi Amazon non utilizzano alcuna applicazione Google, incluso Google Play. Sebbene possa essere nel loro migliore interesse seguire gli stessi standard, essi non sono vincolati da essi e spesso non vengono seguiti. TVDPI si è intrufolato su tutti quando è apparso sul Nexus 7, ma Amazon lo avrebbe saputo se avessero fatto riferimento al CDD durante la progettazione.

In che modo questo li induce a comportarsi in modo diverso?

Le differenze non sono nella selezione del layout. Ovviamente dai tuoi screenshot entrambi i dispositivi stanno riprendendo il layout corretto come ti aspetti. La modifica del valore sw in una directory di layout influisce solo su quali dispositivi selezioneranno quel layout ... non cambierà nulla su come le cose verranno ridimensionate. Non preoccupatevi di cercare di posizionare i layout stessi in directory specifiche della densità ... i layout dovrebbero essere flessibili.

Invece il problema si trova con qualsiasi calcolo di dimensione o dimensione realizzato su unità pixel indipendenti dalla densità (ad esempio dip o dp), come dimensioni del testo, eventuali dimensioni fisse di visualizzazione eventualmente create e dimensioni disegnabili.

Poiché questi due dispositivi hanno scelto per ridimensionare le risorse in modo diverso, qualsiasi risorsa estraibile che si utilizza o qualsiasi valore definito in "dp" comporterà una piccola modifica.Permettetemi di darvi due esempi:

Si definisce la dimensione del testo per TextView per essere 16dp. Sul Nexus 7, questo disegnerà il testo a 21px. Il Kindle Fire HD disegnerà lo stesso testo a 24px. La differenza è piccola ... ma esiste.

Lo stesso vale per le immagini disegnabili. Se hai definito un'immagine solo in drawable-mdpi a 48x48 e la stessa immagine in drawable-hdpi a 72x72, Kindle ha un'immagine a 72px da usare direttamente, e il Nexus creerà un'immagine in scala 64px, quindi c'è una differenza di 8 pixel tra le due risorse .

Cosa posso fare per rendere i due più simili?

Nella maggior parte dei casi, direi che non dovresti. In genere il ridimensionamento eseguito non influisce in modo sostanziale sul risultato dell'applicazione a meno che i vincoli del layout non siano impostati con troppe dimensioni codificate.

Tuttavia, in generale se vi sono parti dell'interfaccia utente che è necessario modificare specificamente per questo scopo, la soluzione è definire risorse e dimensioni specifiche per il caso -tvdpi in cui si ritiene siano necessarie (di nuovo, non lo farei t consiglia di ridimensionare TUTTO nella tua app per soddisfare questo caso).

Per cose come testo o dimensioni di visualizzazione, significa che si può volere un file values-tvdpi/dimensions.xml e un file predefinito values/dimensions.xml. Utilizzando l'esempio sopra, è possibile definire la dimensione predefinita del testo come 16 dpi, ma nella posizione -tvdpi, definire la stessa dimensione di 18 dpi. Ciò farà sì che entrambi i dispositivi scalino il testo finale fino a 24px. Nel codice, dove viene utilizzata la dimensione effettiva, fare riferimento come @dimen/myTextSize anziché 16dp direttamente.

Per gli elementi disegnabili, aggiungere una directory drawable-tvdpi e scalare quei beni per abbinare come si pensa che dovrebbe disegnare su dispositivi come il Nexus 7. Anche in questo caso con il nostro esempio precedente, copiare lo stesso file di immagine dalla cartella drawable-hdpi nella cartella drawable-tvdpi quindi entrambi i dispositivi disegneranno la stessa immagine a 72px.

Per evitare di copiare la stessa risorsa in più posizioni, è possibile farlo anche con l'aliasing. Inserendo l'immagine stessa in drawable/ con un nome speciale e utilizzando values-tvdpi/drawables.xml e values-hdpi/drawables.xml per fare riferimento alla singola risorsa in due punti. Per ulteriori informazioni sull'aliasing, see this documentation. Gli esempi sono per i layout, ma lo stesso paradigma funziona per i drawable (o qualsiasi risorsa) passando a type="drawable".

+3

Questa è un'ottima risposta, l'unica avvertenza che aggiungerò è che l'aliasing basato sulla densità è solo una soluzione temporanea. Quando esce un tablet che è conforme al CDD ed è in realtà un HDPI, tutto ciò si interromperà. Questa è la stessa situazione in cui ci trovavamo con il Galaxy Tab 7 ". Si riferiva come HDPI quando era realmente MDPI. Tutti iniziarono a farlo funzionare, ma quando il Nexus 7 uscì, tutti gli hack furono scoperti e la maggior parte delle aziende dovette abbandonare supporto per la scheda 7 "per supportare la nuova linea di dispositivi con risoluzione superiore. Attualmente mi sto appoggiando a nuovi layout che utilizzano -sw533dp ma non sono ancora soddisfatto. – JustinMorris

1

Perché il Nexus7 è un dispositivo tvdpi utilizza i beni di layout-sw600dp (sulla base di calcoli a 213dpi), il FireHD è un dispositivo HDPI e finisce con le attività di layout-sw533dp (calcoli basati su 240 dpi)

+3

perché la densità è calcolata in pixel/pollice, entrambi i dispositivi hanno la stessa risoluzione, entrambi i dispositivi hanno le stesse dimensioni dello schermo. una differenza di densità? – stoefln

1

Forse dovresti usare layout-tvdpi e layout-hdpi?

Problemi correlati