Chegamos ao final do curso de Swift! Agora, é hora de pensarmos nos aprimoramentos de uma aplicação, por exemplo: Ícones, Imagens, i18n (internacionalização) e l10n (localização) da aplicação.
Como exemplo deste capítulo, usei uma app que ainda estou desenvolvendo: Hércules Password Protector - HPP, uma app que eu criei para a plataforma Android e estou portando para iOS. Infelizmente, ainda não ficou pronta, porém, quando eu terminar, você terá acesso ao código-fonte.
Há quatro anos (este livro foi escrito em Março de 2015), eu criei uma app Android, junto com o meu amigo Francisco, para armazenar senhas. Esse aplicativo é o “Hercules Password Protector”.
Nós o publicamos como Open Source, no Google Code, onde está até hoje:
A ideia era criar um programa que realmente fosse seguro, e permitisse guardar nossas senhas em um “cofre” virtual. Com uma senha “mestra”, você poderia abrir o cofre e ter acesso a todas as suas senhas.
Naquela época (e até hoje) a maioria das apps de segurança, tanto para Android como para iOS, tem um defeito básico: Elas armazenam sua senha “mestra”. Algumas armazenam internamente, dentro da própria app, outras, enviam para um site ou web service. E ainda existem algumas, cujo segredo está no próprio algoritmo utilizado para proteger as senhas.
Depois de ler o livro “Applied Cryptography”, de Bruce Schneier (http://www.amazon.com/Applied-Cryptography-Protocols-Algorithms-Source/dp/0471117099), eu entendi que a segurança de uma app criptográfica não pode estar no algoritmo, e que, segredo entre duas pessoas só existe se uma delas for morta!
Queríamos fazer um programa que JAMAIS armazenasse sua senha “mestra” e, cujo algoritmo, fosse inútil para desvendar o segredo.
Então, duas coisas me vieram à cabeça:
- Usar “hash” para validar cada entrada no “cofre”;
- Usar um algoritmo padrão, como o 3DES - Triple DES.
O HPP encripta os registros no Banco de dados, criando um hash MD5 para cada um deles. O Banco SQLite é como um “cofre”, com os elementos encriptados. A única informação que fica de fora é a chave, que é um UUID.
Para abrir o “cofre”, o HPP lhe pede a senha “mestra”. Ele tenta decriptar cada entrada, validando o seu “hash” contra o que foi armazenado e decriptado. Se for diferente, então a senha é inválida.
Desta forma, o HPP não precisa ter a sua senha armazenada, para saber se é válida ou não.
O HPP é uma app de sucesso no Google Play, com milhares de instalações. Ele é gratuito, baseado em ADS.
Na primeira vez que você executa o HPP, não existe um “cofre”. Logo, ele te pede a senha “mestra”:
Dentro dos arquivos do livro, que eu aconselho que você baixe novamente, tem uma versão "tosca" do HPP, que vamos aprimorar. Você pode abrir o projeto no Xcode e acompanhar essa lição.
Ícone da app
O ícone será o primeiro elemento que o usuário verá da sua aplicação. Até mesmo na AppStore, você coloca uma versão deste ícone, de modo a instigar o usuário a baixá-la.
Antes de mais nada, os ícones e imagens da app estão dentro da pasta dos arquivos do livro, na subpasta: “capt10/imagens”. Os ícones estão em: “capt10/imagens/hpp-icons”.
Você já deve ter reparado que o Xcode gera um ícone para nós, cheio de “linhas de construção”, de modo a termos algum ícone para ela. Porém, JAMAIS pense em manter este ícone!
Leia atentamente o documento: https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/AppIcons.html#//apple_ref/doc/uid/TP40006556-CH19-SW1.
Requisitos para um ícone de app
A Apple tem um documento excelente, chamado: “iOS Human Interface Guidelines”, onde ela descreve os formatos e resoluções das imagens, incluíndo ícones de App.
Toda app deve ter um ícone, e ele pode ter os seguintes tamanhos:
Dispositivo TamanhoiPhone 6 Plus (@3x) 180 x 180iPhone 6 and iPhone 5 (@2x) 120 x 120iPhone 4s (@2x) 120 x 120iPad and iPad mini (@2x) 152 x 152iPad 2 and iPad mini (@1x) 76 x 76
O iOS usa sufixos especiais de nome de arquivo para diferenciar cada tipo de ícone. A Apple recomenda que os ícones sejam criados com cores de 24 bits, em formato PNG (não entrelaçado).
App Universal
Ainda não falei explicitamente sobre isso, mas você pode limitar os dispositivos que a sua app suportará. Por exemplo, você pode determinar que sua app suporta apenas iPad, logo, os usuários de iPhone não poderão baixá-la. Se você disse que a app é para iPhone, os usuários de iPad poderão usá-la, mas terão que fazer “zoom” para que a tela aumente.
Eu recomendo fortemente que você sempre pense em criar apps universais, ou seja, que suportem todos os dispositivos. isto é especificado na aba “General”, das propriedades do Projeto:
Múltiplas resoluções
Você não pode limitar os modelos de dispositivos que sua app suporta. Por exemplo, não é possível especificar que sua app não suportará iPhone 4S. Porém, você pode limitar algumas coisas:
- Versão mínima do iOS (dentro de “deployment target”,
como já vimos);
- Especificação mínima do processador ARM (dentro de
“Info.plist”, “Required device capabilities”);
A versão atual do iOS, enquanto eu estava escrevento este livro, é 8.3. Ela roda nos aparelhos do iPhone 4S em diante. Porém, o iPhone 4S possui um processador dual core, que roda em 800 Mhz, logo, dependendo do que a sua app faz, pode rodar um pouco lenta e deixar o usuário “furioso”.
Você pode limitar a especificação do processador. Se você abrir o arquivo “Info.plist”, que fica dentro de “Supporting files”, no seu Projeto, verá que está especificado “armv7”:
Isto significa que sua app poderá ser baixada até pelos usuários de iPhone 4S.
Este é o conjunto de instruções, suportadas pelo processador ARM do dispositivo. Os dispositivos mais modernos, como: iPhone 5 em diante, suportam “armv7s”, e, a partir do iPhone 5S, suportam instruções de 64 bits. Porém, se você tentar mudar para “armv7s”, ele deveria limitar a execução em dispositivos que usem o conjunto de instruções, porém, no iOS Simulator, ele continuou rodando a app em iPhone 4S.
Bem, de qualquer forma, você deve suportar várias resoluções de tela, e o mínimo é o iPad 2, cujo ícone tem 76 x 76 pixels.
Você deve criar várias versões do ícone, e não se preocupe em arredondar as bordas, pois o iOS vai aplicar uma “máscara” e cortar as bordas arredondadas automaticamente.
AppStore icon
Bem, vamos começar criando a versão do App Launch Icon que será usada pelo iTunes e pela AppStore. Ela deve ter 1024 x 1024, e deve se chamar, obrigatoriamente: “[email protected]”. Como é a maior imagem, fica fácil criar versões reduzidas a partir dela.
Eis a imagem que eu criei, usando espadas do Openclipart.org, e umagem de foto gratuita:
Eu não sou um artista gráfico, logo, não tenho muito talento para desenho e composição de imagens, porém, este foi o logo do HPP para Android, e acho que representa bem a segurança que ele proporciona às suas senhas pessoais.
Você pode usar um programa como o Gimp (http://www.gimp.org), que funciona muito bem em todas as plataformas, e é gratuito.
Esta imagem deve ter o tamanho de 1024 x 1024, e ser renomeada para: “[email protected]”. Usando o Gimp, vou criar versões reduzidas da mesma imagem:
- Versões para iPhone 6 Plus (@3x):
- Ícone normal: [email protected]
(180 x 180);
- Ícone para busca (Spotlight): iconespot@3x.png
(120 x 120);
- Ícone para Settings: [email protected]
(87 x 87);
- Ícone normal: [email protected]
(180 x 180);
- Versões para iPhone 5S e 6 (@2x):
- Versões para iPad e iPad Mini (@2x):
Para atribuir as imagens à sua app, abra o arquivo de assets: “Image.xcassets”, e arraste cada imagem para o seu lugar correspondente:
Este “asset”, chamado “AppIcon”, contém um conjunto de imagens já associadas com o ícone da aplicação. Isto pode ser visto dentro dos settings da app, na aba “General / App Icons...”.
Ao executar e parar sua app, você poderá constatar o novo ícone no iOS Simulator ou no dispositivo real:
Launch screen e imagens de fundo
O iOS 8 introduziu o comceito de “launch screen”, que é uma cena especial, exibida enquanto sua app está sendo carregada para a memória. Antes do iOS 8, você deveria criar uma “launch image”.
De qualquer forma, você TEM que providenciar uma das duas coisas: Uma launch screen ou uma launch image. Como estamos trabalhando com “deployment target” iOS 8, então, vamos usar a launch screen que o Xcode criou para nós.
Imagens de fundo
Uma imagem de fundo, cobre todo o “background” de uma cena, ficando as views por cima dela. Duas características são importantes sobre imagens de fundo:
- Elas serão “esticadas”;
- Elas devem estar alinhadas com as margens da tela física.
Ao criar imagens de fundo, temos que evitar colocar elementos que possam ser “distorcidos”, como: círculos ou letras. Uma imagem de fundo deve ser o mais neutra possível. Embora possamos criar padrões e gradientes, temos que pensar em como isso será visto pelo Usuário.
Eu recomendaria evitar padrões intrincados, como: tranças metálicas ou imagens repetitivas.
O HPP usa uma imagem de fundo simples, em dois “sabores”: horizontal (landscape) e vertical (portrait), dependento da orientação do dispositivo. A imagem imita uma chapa metálica, com um brilho de luz no alto e à esquerda. Vamos ver as duas imagens:
Orientação do dispositivo
Até este momento, eu evitei propositadamente tocar nesse assunto. Minha política é adiar uma nova característica técnica até quando ela se torna necessária. Isto evita encher sua cabeça (e sua paciência) com coisas que ainda não está precisando aprender.
Agora, chegou o momento de falarmos de orientação do dispositivo. Abra as propriedades do seu projeto, e selecione a aba “General” (é só clicar no nó de mais alto nível do projeto).
Temos duas verticais (Portrait e Upside Down) e duas horizontais (Landscape Left e Landscape Right).
Você deve suportar o máximo de orientações possíveis, pois não sabe como o usuário vai querer ver sua app. O Xcode já começa inibindo isso, pois desabilita o uso da app com o dispositivo de cabeça para baixo (Upside Down). Eu marcaria essa opção também, pois, se o usuário estiver com o dispositivo de cabeça para baixo, sua app também ficará de cabeça para baixo.
E por que um usuário colocaria seu dispositivo de cabeça para baixo? Simples! Eu mesmo faço isso a todo momento! Geralmente, eu “plugo” os fones de ouvido no meu iPhone, para ouvir música, e o coloco de cabeça para baixo, dentro do bolso, pois a entrada de fones é na parte de baixo do iPhone. Assim, se sua app não suporta “Upside Down”, usuários como eu são obrigados a retirar o iPhone do bolso e virá-lo, só para poder rodar sua app.
Suportar todas as orientações de dispositivo é uma boa prática, e é recomendada pela Apple. É claro que nem todo tipo de app pode suportar todas as orientações, mas, se sua app não tem essa restrição, é melhor você suportar todas, incluindo “Upside Down”.
Para suportar todas as orientações, além marcar isso nas propriedades do Projeto, é necessário que TODOS os seus View Controllers tenham este código:
override func
supportedInterfaceOrientations() -> Int {
return
Int(UIInterfaceOrientationMask.All.rawValue)
}
Size class
No iOS 8, nós não determinamos imagens para dispositivos. Nós usamos um conceito chamado de: “Size class”, relativo à altura e largura da tela, de acordo com a orientação atual do dispositivo, se está em formato horizontal (landscape) ou vertical (portrait).
Quando um dispositivo pequeno, como um iPhone, por exemplo, está na vertical, então ele está em sua posição normal. Nesta posição, seu “Size class” é:
- Altura: “regular", ou seja, a altura não está
compactada;
- Largura: “compact”, ou seja, a largura está compactada.
iPads não têm essa restrição, pois, em qualquer posição, sua altura e largura não são consideradas como: “compact”.
Isto é usado tanto no arquivo de “assets” (Images.xcassets), como dentro do Storyboard. A nomenclatura é sempre: Altura, Largura. Por exemplo:
- *,*: Qualquer altura, qualquer largura - Serve para
qualquer orientação e dispositivo;
- *,-: Qualquer altura, largura compacta - Serve para iPhones
em orientação horizontal;
- -,*: Largura compacta, qualquer altura - Serve para iPhones
em orientação vertical.
Guardando as imagens no arquivo de “assets”
Ok. Já entendemos orientação e size class, então é hora de guardar nossas imagens dentro de um “image set”, no arquivo: “Images.xcassets”.
É só abrir o arquivo, clicar no botão “+”, que fica na parte de baixo da lista de “assets”, e escolher: “Image set”. Um novo conjunto de imagens será criado, com espaços para @1x (iPad 2 e iPad Mini), @2x (iPhone 5S e iPad Air) e @3x (iPhone 6 plus). As imagens para o HPP estão dentro da pasta dos arquivos do livro, na subpasta: “capt10/imagens”. As imagens de fundo para orientação horizontal e vertical estão dentro das subpastas: “capt10/imagens/fundo-landscape” e “capt10/imagens/fundo-portrait”.
Arraste a imagem da orientação vertical (a normal) para a posição do meio do image set (@2x). Agora, vamos alterar nosso image set para dizer que também queremos colocar uma versão desta imagem para orientação horizontal. Selecione o image set, abra o Attributes inspector, e mude a propriedade “height” para: “Any & compact”. Assim, estamos querendo adicionar uma versão da imagem para altura compactada também. Então, arraste a imagem da orientação horizontal, para a posição do meio da segunda linha do image set. No final, deve ficar assim:
Alterando a Launch Screen
Se você observar bem o Projeto, há um arquivo “LaunchScreen.xlb”, que apresenta uma cena inicial, exibida enquanto nossa app estiver sendo carregada.
Vamos acrescentar uma “Image View” à ela. Para isto, arraste uma “Image View, da lista do Object library, para dentro da cena:
Agora, temos que fazer alguns ajustes. Em primeiro lugar, temos que associar essa Image View ao nosso Image Set, que criamos no arquivo “Images.xcassets”. É só selecionar a Image View e, no Attributes inspector, selecionar o Image Set que nós criamos (se chama “image”):
Agora, procure alinhar a Image View centralizada. É fácil, pois vão aparecer duas linhas azuis, quando o centro da imagem estiver alinhado com o centro da tela. Você notou que essa imagem está ocultando o Label que estava na cena? Isso acontece porque ela está em primeiro plano, então, como é uma imagem de fundo, devemos enviá-la para o fundo.
O sistema de views do iOS funciona em camadas, logo, podemos posicionar uma imagem em qualquer lugar. Para ter certeza que a imagem ficará no fundo, é só selecioná-la e ir ao menu “Editor / Arrange / Sendo to Back”.
Bem, a imagem está centralizada e posicionada ao fundo, mas como faremos para que ela cubra toda a área da cena? Isso é trabalho para as restrições de auto-layout.
Precisamos centralizar a imagem e ajustá-la ao tamanho da tela. Para isto, basta:
- Esticar a imagem horizontalmente (de ambos os lados), para
que coincida com a margem da cena;
- Esticar a imagem verticalmente (de ambos os lados), para que
coincida com a margem da tela;
- Selecione a Image View e abra o menu: “Editor / Resolve
auto layout issues / Reset to suggested constraints”;
Se você abrir o Document Outline (na janela do Editor, no canto inferior esquerdo), verá as restrições que foram criadas:
Você pode criar manualmente as restrições, indicando que o topo, a esquerda, a direita e a parte de baixo da imagem, coincidam com as respectivas margens da view superior (a cena), embora eu não recomende isso.
Agora, ao executar sua app, você verá esta tela inicial:
Alterando o fundo da tela inicial
Além da “launch screen”, nossa app tem uma tela inicial, onde pedimos a senha. Esta tela pode rotacionar para landscape ou portrait.
Em primeiro lugar, colocamos a image view exatamente como fizemos na Launch screen, sem esquecer as restrições de auto layout.
Depois, temos que criar a versão para tela Landscape. Onde está escrito: “Any / Regular”, clique na palavra “Regular” e arraste para cima, de modo a criar a versão com altura compacta. Eis o layout com altura regular:
Agora, veja a tela inicial com altura compacta:
É só clicar na palavra “Regular” e arrastar o cursor para cima, e você verá a versão com altura compacta. Para voltar, clique na palavra “Compact” e arraste o cursor para baixo.
Você deve alinhar as restrições de auto layout nas duas versões da tela.
Fundo da tela Mestre e da tela Detalhe
Na app original do Android, o fundo da tela mestre é cinza escuro, com letras brancas. Podemos fazer isso também.
Para isto, temos que alterar a cor de fundo da célula protótipo, aquela usada pela Table View para preencher as linhas, e a cor do texto também.
Ilumine o texto da célula protótipo, e troque sua cor para branco:
Agora, troque a cor de fundo da célula protótipo. É só selecioná-la e trocar a cor:
Finalmente, queremos que a lista toda apareça com fundo cinza, e não apenas as células criadas. Então, trocamos o fundo da View da Table View para cinza. Selecione a área livre, fora da célula protótipo e abaixo dela, e mude sua cor:
O iPhone funciona bem só com a configuração via Xcode, porém, no iPad, há um problema: ele sempre limpa as células com a cor branca. Então, é necessária uma ligeira alteração no MasterViewController.swift:
override func tableView(tableView:
UITableView, willDisplayCell cell: UITableViewCell, forRowAtIndexPath
indexPath: NSIndexPath) {
cell.backgroundColor =
UIColor.darkGrayColor()
}
Bem, só falta agora a cena de detalhe. Na aplicação HPP original, ela ficava com o mesmo fundo de tela da tela inicial, então, repita o mesmo procedimento que fez para a tela inicial, não esquecendo que são dois layouts: Um para altura regular e outro para altura compacta:
Muito bom. Agora, a app está com uma aparência mais profissional.
Internacionalização e localização
Talvez, você esteja pensando: “Por que eu preciso me preocupar com isso? Só quero vender minha app no Brasil”. Embora seja possível determinar em quais países sua aplicação estará disponível para venda, eu recomendo fortemente que você procure distribuí-la no maior número de países possível.
Uma app que nada vende no Brasil, pode lhe render horrores nos Estados Unidos, ou em outro lugar qualquer. Então, é preciso Internacionalizar sua app e criar localizações para os principais países onde você pretende distribuí-la.
Internacionalização é o processo de preparar uma app para usar mais de um idioma. E não é só o idioma, as configurações regionais também (vírgula decimal, símbolo de moeda etc).
Já vimos um pouco disso anteriormente, e agora é hora de colocar em prática. Para começar, vamos definir uma coisa: Qual é o idioma padrão da nossa app? Será Português? Então está bom. E quais outros idiomas vamos suportar?
A internacionalização é feita preparando a app para lidar com Strings que serão exibidos para o usuário. Por exemplo a função: NSLocalizedString permite traduzir um texto para outro idioma. Mas ela só funciona se você tiver o arquivo contendo a tradução dos strings.
Então, é hora de pensar no segundo idioma que nossa app suportará: Inglês. É recomendado que, para cada idioma suportado, você contrate um tradutor profissional, ao invés de usar recursos como o “Google Translator”. Porém, como eu sou fluente em inglês, e a app tem poucos textos, eu vou assumir este risco.
Para começar, vamos mudar as configurações de idioma e região do iOS Simulator:
Agora, configure o “Info.plist” do projeto, para conter 2 localizações:
A primeira será Português e a segunda, Inglês.
Para exibir o header “Localizations”, é só selecionar algum elemento da lista e mudar para ele.
Agora, execute a app.
Temos um problema: Os títulos “Master” e “Detail” ainda estão em inglês. Agora, mude o idioma do iOS Simulator para inglês e rode a app. Você verá que todos os cabeçalhos e textos estão em Português, exceto os títulos “Master” e “Detail”. É hora de corrigirmos isso.
Localização base e linguagem de desenvolvimento
Sei que seu orgulho nacional deve ser grande, mas temos que reconhecer: Português não é um idioma internacional, como o Inglês ou o Espanhol.
No sistema de internacionalização do iOS, é possível determinar dois tipos de idioma: Base e de desenvolvimento. Eu recomendo que você use o Inglês para ambos.
Idioma base
O idioma (ou localização) base é aquele que será utilizado, quando não existir uma tradução da sua app para determinada linguagem. Eu recomendo que use o Inglês (e já deve estar assim). Abra as propriedades do Projeto, e verifique se está com a localização: “English - Development language”, e com “Use base internationalization” marcada:
Quando você abre as propriedades do Projeto, ele já posiciona no Target. É preciso posicionar nas opções globais do Projeto, clicando neste ícone:
O que isto significa?
- Development language: O idioma que você usou para
desenvolvimento. Você deveria usar sempre inglês, logo, sugiro que
traduza seu Storyboard, colocando todos os títulos e “placeholders”
em inglês;
- Base internationalization: A app usa apenas uma Storyboard,
escrita na “development language”, e cria arquivos de Strings
para cada localização que você criar.
Bem, então temos que traduzir nossa interface para inglês, e vamos aproveitar para mudar outras coisas também:
Criando a localização em Português para a UI
Ok, já definimos a nossa localização base e linguagem de desenvolvimento como inglês. Agora, vamos criar a localização em Português para a nossa Interface de Usuário. Abra novamente as propriedades do Projeto (tendo o cuidado de selecionar o Projeto inteiro e não apenas um dos Targets), e adicione a localização em Português (“Editor / Add localization”):
Ao adicionar a localização, o seu “Main.storyboard” ganhará um “triângulo”, que você poderá expandir:
A localização é um arquivo, contendo cada texto utilizado no Storyboard “base”, para o qual você deve fornecer uma tradução para o Português. Então, é só ler o que está no comentário, e fornecer a tradução.
Traduzindo os Strings de dentro do código
Ok, traduzir a UI foi simples, mas como traduzir o strings que usamos programaticamente? Toda mensagem ou diálogo que você apresente ao usuário, devem ser traduzidos também. Aí é que entra a função “NSLocalizedString()”:
let texto = NSLocalizedString(“<chave>”,
comment: “”)
Nós criamos diálogos baseados no UIAlertController, que devem ter os seus textos traduzidos, por exemplo, no MasterViewController.swift:
// Mostra um alerta para pegar o
local e o texto secreto:
var alert = UIAlertController(title:
NSLocalizedString("Novo registro", comment: ""),
message: NSLocalizedString("Insira os campos", comment:
""),
preferredStyle:
UIAlertControllerStyle.Alert)
alert.addTextFieldWithConfigurationHandler(configurationLocalTextField)
alert.addTextFieldWithConfigurationHandler(configurationTextoSecretoTextField)
alert.addAction(UIAlertAction(title:
NSLocalizedString("Close", comment: ""),
style: UIAlertActionStyle.Cancel, handler:handleCancel))
alert.addAction(UIAlertAction(title:
"Ok", style: UIAlertActionStyle.Default, handler:{
(UIAlertAction)in
self.inserirRegistro()
}))
self.presentViewController(alert,
animated: true, completion: {
println("completion block")
})
func mudarParaAbrir() {
labelSenha.text =
NSLocalizedString("Senha", comment: "")
labelConfirmar.hidden = true
txtConfirmar.hidden = true
btnAbrirCriar.setTitle(NSLocalizedString("Abrir",
comment: ""), forState: UIControlState.Normal)
}
Além disto, qualquer diálogo ou mensagem que mostremos ao usuário também precisam ser localizados. Temos alguns diálogos de erro, que também necessitam disto.
Ok, mas como essa função traduz o texto? Na verdade, ela não traduz nada! Ela procura um arquivo de Strings para o idioma atual do dispositivo. Este arquivo se chama: “Localizable.strings”.
Crie um arquivo novo, do tipo “Resource / Strings”:
Depois, selecione o arquivo, e adicione todos os Strings que você usou como “chave”, nas funções “NSLocalizedString()”. Você pode fazer uma busca no projeto. No nosso caso temos estes:
/*
Localizable.strings
HPP
Created by Cleuton Sampaio on 21/04/15.
Copyright (c) 2015 Cleuton Sampaio. All
rights reserved.
*/
"Cancel" = "Cancel";
"Edit" = "Edit";
"Done" = "Done";
"Senha" = "Password";
"Abrir" = "Open";
"Local" = "Place";
"Texto Secreto" = "Secret";
"Insira os campos" = "Fill
the data";
"Há dado sem salvar" =
"Unsaved changes";
"Você alterou o texto secreto e não
salvou. Quer salvar?" = "You have changed the secret, want
to save it?";
"Sim" = "Yes";
"Não" = "No";
"Novo registro" = "New
record";
"Close" = "Close";
Agora, vamos criar duas localizações: Base e Portuguese:
A “base” é a própria cópia dos Strings originais, em inglês. Já, a versão em português contém os mesmos Strings traduzidos.
O primeiro elemento é a chave que será procurada, e o segundo, é o valor.
Agora, teste toda sua app em Português, e depois mude o idioma do Simulador para Inglês e Francês. Você verá que para qualquer idioma, sem ser Português, a versão base, que é em Inglês, será apresentada.
Conclusão
Demos uma aparência mais profissional, com ícone, imagem de fundo e fundo de tela. Além disso, nós a internacionalizamos e criamos duas localizações para ela: Base e Português.
Não se esqueça!
Acesse a página do curso para ver as outras lições, e sempre baixe novamente o zip do curso, pois, como é um trabalho em andamento, pode haver correções de erros e aprimoramentos.Se tiver dúvidas, use o fórum!
Esse "curso" não dá diploma algum! E todo o material é liberado sob licença "Creative Commons" compartilha igual.
Você pode compartilhar esse material da forma que desejar, desde que mantenha o mesmo tipo de licença e as atribuições de autoria original.
O trabalho "Criando apps para iPhone com Swift " de Cleuton Sampaio de Melo Jr está licenciado com uma Licença Creative Commons - Atribuição-CompartilhaIgual 4.0 Internacional. Isso inclui: Textos, páginas, gráficos e código-fonte.
Nenhum comentário:
Postar um comentário