2012-04-04 13 views
32

In Android R.java viene utilizzato per fornire l'accesso alle risorse definite nei file XML. Per accedere alla risorsa, è necessario invocare il metodo findViewById() passando all'ID della risorsa da recuperare.Qual è il concetto alla base di R.java?

Questo è simile a Spring in cui i bean sono definiti in un contesto XML e vengono recuperati utilizzando il contesto dell'applicazione. context.getBean("beanId")

Questo fornisce un accoppiamento lento poiché i bean sono definiti esternamente e potrebbero essere modificati senza apportare modifiche al codice.

Questo mi ha confuso. Sebbene ciò che Android assomiglia alla primavera, quale vantaggio offre?

  1. Qual è il punto di avere un R.java intermedio comunque? Non potremmo semplicemente acquisire risorse direttamente da XML utilizzando un risorsa contesto lettore/applicazione. per esempio. findViewById("resourceId")
  2. Non c'è alcun accoppiamento libero. Poiché i riferimenti in R.java vengono generati automaticamente, come è possibile eliminare una risorsa e inserirne una nuova?
  3. Quale modello di progettazione segue (se ce n'è uno)?
  4. Non sarebbe meglio disporre di risorse iniettate usando IOC (come Roboguice)? Perché Google ha deciso di darci un tale tipo di un modo strano di lavorare con le risorse?

Perdonare la mia ignoranza. Sono uno sviluppatore Java principiante che prova troppe cose contemporaneamente. :-) Grazie per tutto il feedback.

+0

Voglio solo ripetere la tua domanda due volte, questa è una domanda molto interessante – fatiDev

risposta

18

android.R.java non è solo dove XML id vengono memorizzati. Contiene anche l'accesso alle risorse, come drawable, layout, stringhe, matrici e praticamente tutto ciò che è possibile dichiarare nelle risorse.

Personalmente trovo che sia utile quando si utilizza Eclipse. Posso semplicemente digitare findViewById(R.id. e Eclipse mostrerà un suggerimento con un elenco di opzioni tra cui scegliere.

Tuttavia, a livello di piattaforma, direi che le variabili id ​​codificate consentono di evitare errori quando si utilizzano le stringhe per identificare le risorse, ovvero possono essere debuggate durante la programmazione (o durante la compilazione, piuttosto che il runtime).

+5

Non potrei essere più d'accordo. Penso che il controllo del tempo di compilazione ne valga la pena. La sicurezza del tempo di compilazione è uno dei motivi per cui amo Java rispetto ad altri linguaggi dinamici. :-) –

1

Il confronto si sente un po 'un po' (in realtà) strano, perché si confrontano due meccanismo basato sul fatto che usano cose nominate per fare cose. Per il caricamento delle risorse, ad es., Guarda come viene gestita la risorsa nel mondo .Net.


Esso prevede tempo di compilazione controllando se la risorsa è disponibile. Perché se così non fosse, non ci sarà una staticità all'interno di R.java che punta ad essa. Nell'esempio di primavera, come puoi essere sicuro che ci sia un bean chiamato beanId? Tuttavia, non prevede il controllo se è il tipo di risorsa.

Perché non è libero? Finché la nuova risorsa ha lo stesso nome, genererà la stessa costante statica. In primavera, dovresti utilizzare lo stesso nome di bean.

Motivo di progettazione? Nessuna. Aggiunge solo un livello di riferimento indiretto nominando le risorse e quindi fare riferimento a esse solo per nome, non caricandole direttamente dalla loro posizione reale.

In realtà, le risorse sono immesse in, perché il caricamento delle risorse deve far fronte alla localizzazione. Vedi here per come Android fa roba; nel mondo .Net, le colture aggiuntive sono imballate in gruppi satelitari; il resource manager caricherà quello giusto in base alla cultura corrente.

21

Il più grande vantaggio è nella localizzazione e nella fornitura di risorse alternative per schermi di dimensioni diverse.

ad esempio si può avere una risorsa di stringa R.string.myname questo potrebbe essere un definito in inglese in /values-en/strings.xml e in spagnolo in /values-es/strings.xml

sistema si prenderà cura o raccogliendo il file giusto a seconda del locale non vi resta che utilizzare @string/myname nel file di layout o R.string.myname nel codice.

Allo stesso modo si potrebbe avere due file di layout per verticale e orizzontale definiti

res/layout/mylayout.xml 
res/layout-land/mylayout.xml 

Nel codice sarà sufficiente specificare R.layout.mylayout per gonfiare il layout. Il gestore risorse preleva il file in layout-land se il dispositivo è in modalità orizzontale.

Fare questo manualmente sarebbe un incubo - da qui la necessità per il file R

0

Esso contiene anche l'accesso alle risorse - quali ID, drawable, layout, stringhe, array e in fondo tutto ciò è possibile dichiarare di risorse .

+1

Grazie per aver contribuito a StackOverflow. Prendi in considerazione la lettura della voce [Centro assistenza] (http://stackoverflow.com/help/how-to-answer) su come rispondere a una domanda. Come scritto, la tua risposta non è una risposta completa a se stessa. Si riferisce al contesto da altre domande. Considera di fare una lista completa di ciò che si trova in R.java, non solo le cose lasciate fuori da altri poster. –

Problemi correlati