2012-11-24 8 views
21

Mi chiedo solo quali sono i benefici/costi generali sono per l'utilizzo @string piuttosto che stringhe di codifica rigidi all'interno del codice Java vero e proprio ... Per esempio:stringa hardcode vs @String in codice Java - Android

// To get the string resource: 
getActivity.setTitle(getString(R.string.my_string)); 

E 'questa la migliore prassi per cose come i titoli ActionBar, testo dei pulsanti dinamicamente creato, ect ... o devo solo fare questo:

// Hardcoded string 
getActivity.setTitle("My String"); 

so che ci sarà un po' più in alto facendo il primo modo .. Non sono sicuro di quale sia la migliore pratica.

risposta

28

Nel caso in cui non si fosse a conoscenza del punto in cui si dispone del sistema @string, leggere la documentazione localization. Ti consente di individuare facilmente il testo nella tua app e in seguito di tradurlo.

Modifica Grazie a Hippo per averlo chiarito.

L'utilizzo di più stringhe dello stesso valore indipendentemente dal metodo (Strings.xml vs programatically) non sembra avere alcun sovraccarico. Secondo Oracle "Tutte le stringhe letterali e le espressioni costanti con valori stringa sono internate", il che significa che l'oggetto viene riutilizzato anziché ricreato se lo si utilizza nuovamente.

+8

+1 per localizzazione. – PravinCG

+9

Le stringhe sono internate, quindi non penso che valga il tuo secondo commento. – AbdullahC

+1

@Hippo Questo è il punto che stavo cercando di fare lì. Se la stringa "Titolo" è stata creata in una classe e in altre cinque classi. Usando Strings.xml farà riferimento a una istanza. Piuttosto che in quelle 5 classi che istanziano un nuovo oggetto String. Suona accurato? – KDEx

3

In questo modo si ha un posto fisso per modificare tutte le stringhe all'interno del progetto. Diciamo che hai usato la stessa stringa in 10 diverse posizioni nel codice. Cosa succede se decidi di modificarlo? Invece di cercare dove tutto è stato usato nel progetto, basta cambiarlo una volta e le modifiche si riflettono ovunque nel progetto.

1

Dovrebbe essere analizzato bene il file strings.xml, no? Quindi suppongo che l'hard coded sarebbe il migliore per le prestazioni, anche se probabilmente inosservabile in fase di runtime. Le persone scelgono di usarlo però per avere tutte le stringhe in un punto nel caso ci siano piani per tradurre l'app.

0

Ci sono molti vantaggi nell'impostare le stringhe in un file strings.xml; in poche parole, consente di utilizzare la stessa stringa in più posizioni, il che è positivo se in qualche modo è necessario modificare la stringa in un secondo momento. Permette anche di visualizzare lo stesso testo in diverse lingue; hardcoding la stringa non ti offre tutte queste opzioni.
BTW, non è necessario inserire tutti i testi nel file string.XML; solo quelli che potrebbero essere utilizzati in più punti nell'applicazione.
La regola generale per l'immissione stringhe nel file strings.xml sono queste:

  • verrà utilizzato in più sedi?
  • Sarà utilizzato in più lingue?
  • Sarà dinamico o statico?

Sono sicuro che ci sono altri motivi, ma questi sono quelli che conosco.

Speriamo che questo aiuti.

9

Non è consigliabile applicare le stringhe di codice nel file/codice di layout. Dovresti aggiungerli a un file di risorse stringa e quindi farli riferimento dal tuo layout.

Motivi:

  • Questo consente di aggiornare tutte le ricorrenze della stessa parola in tutti i layout, allo stesso tempo, semplicemente modificando il file strings.xml.
  • È inoltre estremamente utile per supportare più lingue in quanto un file strings.xml separato può essere utilizzato per ciascuna lingua supportata.

Come il documentation dice:

Supponiamo che la lingua di default dell'applicazione è l'inglese. Supponiamo che sia che si voglia localizzare tutto il testo dell'applicazione a francese e la maggior parte del testo nell'applicazione (tutto eccetto il titolo dell'applicazione) in giapponese. In questo caso, è possibile creare tre file strings.xml alternative, ciascuna memorizzato in una directory risorsa specifica locale

Credo che queste ragioni sono sufficienti per consigliare di andare per @String