Tecniche per localizzare applicazioni Apple iPhone
giovedì 25 febbraio, 2010 di Giovambattista FazioliIn Localizzare le applicazioni Apple iPhone in modo rapido abbiamo visto come sia semplice localizzare testi per uno o più linguaggi in Apple iPhone. In Come localizzare immagini e viste di Interface Builder ho mostrato come la stessa tecnica permetta di localizzare immagini ed interfacce generate con Interface Builder. Le procedure descritte negli articoli citati (che sono tutte sostanzialmente identiche) permettono un approccio al problema della localizzazione estremamente rapido, visuale e veloce. Tuttavia non sempre sono applicabili così come sono state descritte. Inoltre, in casi particolari, potrebbero preferirsi altre soluzioni praticabile da codice “puro”.
Senza utilizzare le cartelle .lproj
Un modo per localizzare stringhe, immagini e View senza utilizzare le cartelle .lproj è quello di chiedere al sistema “che lingua si sta utilizzando”:
1 2 3 4 | NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults]; NSArray *languages = [defaults objectForKey:@"AppleLanguages"]; NSString *currentLanguage = [languages objectAtIndex:0]; NSLog(@"Codice lingua %@", currentLanguage); |
In currentLanguage avremmo l’id della lingua attualmente in uso: en per linglese, it per l’italiano, etc… Ne segue che in qualsiasi momento potremmo utilizzare forme del tipo:
1 2 3 4 5 | if( [currentLanguage isEqualToString:@"it"] ) { // italiano } else { // altro } |
Questa tecnica può ovviamente essere applicata a qualsiasi tipo di risorsa: stringa, immagini, multimedia, xib file. Le risorse localizzate dovranno ovviamente essere identificate univocamente all’interno del sistema, sia se esse immagini, file mp3 o ViewController collegati ad uno XIB file. Il controllo sulla lingua viene tuttavia effettuato da codice, con blocchi if/else o switch/case. Ne deriva che meno sono i linguaggi da gestire e più comoda risulta questa procedura.
Variante con le le cartelle .lproj
Una variante al metodo sopra esposto potrebbe essere quella di sfruttare la classica localizzazione tramite le cartelle .lproj, come descritto in Localizzare le applicazioni Apple iPhone in modo rapido e determinare così il nome/id della risorsa da utilizzare.
I file stringa normalmente utilizzati per impostare oggetti UILabel o la label di un bottone, essendo composti dalla dupla id = contenuto, permettono di essere sfruttati anche per identifcare qualsiasi altro tipo di risorsa, non solo stringa.
Ad esempio nel file Italian.lproj potremmo avere:
1 | "sfondo" = "background-ita.png"; |
Mentre nel file English.lproj
1 | "sfondo" = "background-eng.png"; |
Nel codice avremmo poi:
1 2 | // imageViewInfo è un componente UIImageView ad esempio [imageViewInfo setImage:[UIImage imageNamed:NSLocalizedString(@"sfondo", @"")]]; |
Questa tecnica annulla di fatto la presenza di blocchi if/else o switch/case che, nel caso di applicazioni che supportano molti linguaggi, la rendono preferibile.
Nota
Per completezza ricordo che NSLocalizedString() è una macro così definita:
1 2 | #define NSLocalizedString(key, comment) \ [[NSBundle mainBundle] localizedStringForKey:(key) value:@"" table:nil] |
Notate che il secondo parametro di NSLocalizedString(), comment, è relegato solo alla macro stessa, e non utilizzato affatto all’interno della sua implementazione.
Quando utilizzare il code-localizzation
Le tecniche sopra esposte non devono necessariamente sostituire il più semplice, intuitivo, visuale e rapido struumento messo a disposizione da Xcode. Tuttavia esistono circostanze in cui si è costretti ad adottarle:
- In tutti quei casi in cui i componenti o risorse sono create da codice
- Quando non si conosce a priori la risorsa da localizzare
- In tutti quesi casi in cui le informazioni arrivano in dinamico, da rete o da database
In conclusione, a prescindere dal tipo di tecnica utilizzata per visualizzare un’immagine in italiano o una in inglese, rimane il fastidioso problema della duplicazione della risorsa (localizzata) stessa. Un’applicazione che decida di supportare 3, 4 o 8 lingue, se non contiene solo la localizzazione testuale (quella meno ingombrante a livello di bytes), potrebbe ritrovarsi con il 20%, 30% o peggio di “risorse” non utilizzate. Se ad esempio un’applicazione da 2 Mb contiene grafica per 5 Mb, con 4 linguaggi supportati si ha un’applicazione da 22 Mb dove ne sfruttiamo “solo” 7 Mb! Superato un certo limite, dunque, conviene separare gli eseguibili (come già accade in alcuni casi) e, dove non possibile, ricordarsi sempre che l’Apple iPhone – come l’iPad – non è un Desktop con 1 Tb di disco e 4/8 Gb di Ram.
Le risorse dei dispositivi mobili non sono infinite, e l’adozione di tecniche e artifizi atti ad ottimizzare dev’essere una regola da adottare sempre, onde evitare di ritrovarsi un “out of memory” (stile Commodore 64) sulla console di debug del nostro device!
Post correlati
(1 voti, media: 5,00 su 5)
Loading ...
[...] Leggi fonte: [...]