Feche o IB, e execute a aplicação.

Exercício

1. Crie um projeto que permita ao usuário digitar um texto, quando tocar um botão, o texto digitado deverá aparecer em um label.

É muito importante agora, entender o que estamos vendo. Os elementos exibidos no IB neste momento, estão intimamente ligados ao código (gerado automaticamente pelo wizard) da nossa aplicação.

Para manter o esquema do treinamento vamos entender o ambiente do IB que é diferente do XCode, afinal é outro programa. Na figura 16, além da barra de menu do IB na parte superior da tela (conforme qualquer programa Mac), temos 4 janelas. Cada janela tem a sua finalidade, conforme segue:

• • MainView.xib: Nesta janela temos todos os elementos que fazem parte do nosso formulário. Temos um controller, um first responder (uma espécie de controle também) e uma view, chamada de Main View.
  • Main View: É o mesmo elemento citado na janela MainView.xib. Ele já vem aberto para facilitar o seu uso, mas caso você feche esta janela, poderá abrir novamente, dando um duplo click em cima do elemento da janela MainView.xib. Na verdade, esta janela é o elemento View que falaremos com mais propriedade mais adiante. Por enquanto, vamos absorver que esta view é aonde serão colocados os novos componentes da nossa aplicação.
  • Library: Nesta janela, temos todos os componentes possíveis para a nossa aplicação. Estes componentes são divididos em categorias que são: Controllers, Data Views, Input & Values e Windows, Views & Bars.
  • Inspector: Esta é uma das janelas mais importantes para dominarmos. É nesta janela que vamos configurar os componentes (oriundos da Library) inseridos na nossa view (no caso Main View).

Na medida que formos inserindo cada componente, iremos explicar melhor as suas características, o importante agora é entender o ambiente do IB.

Uma curiosidade. Você deve ter percebido que existe uma barra de status na Main View. Você pode estar se perguntando, mas nós não tiramos esta barra anteriormente? A resposta é sim, retiramos a barra de status anteriormente, porém o IB não sabe disso, e ele sempre vai considerar (por default) que você quer deixar a barra de status na aplicação, portanto ele mantém graficamente, para ser uma referência para você, quando estiver desenhando a sua interface. Retirar ou manter esta barra de status no IB, não afeta em nada o funcionamento real da nossa aplicação.

Como retiramos a barra de status da nossa aplicação, convém retirar esta barra do nosso ambiente gráfico, para que a mesma não nos atrapalhe no momento da criação do layout da tela.

Como disse antes, para configurarmos um componente, vamos utilizar a janela Inspector (na figura 16, é a janela do lado direito). Esta janela possui 4 botões. Começando pela esquerda, temos : Attributes, Conections, Size e Identity. Na medida que vamos trabalhando a interface, vamos explicar cada uma dessas opções nos momentos mais oportunos. Por exemplo, agora vamos começar a falar do Size. Nesta aba de opções, temos como configurar o tamanho do componente que está selecionado na Main View. Se você der um click em cima da janela Main View e depois escolher a opção Size, você poderá configurar o tamanho da view. Nota importante, o tamanho de uma View é 320×480 pixels. Mas vamos nos certificar desta informação. Verifique o tamanho da view.

Deve estar 320×460 (valores de W e H). Poxa, acabei de falar que o tamanho é 320×480, por que está 460? Simples, ele está descontando o tamanho da barra de status, que tem 20 pixels de altura. Repare que por conta disso, as dimensões estão travadas, não permitem que você altere, dizemos que a View já se encontra no tamanho máximo permitido. Entendido isso, vamos retirar afinal esta barra de status do IB. Ainda com a Main View selecionada, escolha a opção Attributes do Inspector (a primeira opção da esquerda). A primeira propriedade que aparece para configurar é Status Bar, que deve estar configurada como Gray. Escolha None. Faça isso com bastante calma para observar que o tamanho da View diminuiu. Se você não percebeu a mudança visualmente, volte a opção para Gray e refaça a escolha do None. Depois de fazer esta operação é só voltar para o Size e acertar as dimensões para 320×480, pois agora será permitido alterar seus valores.

Se você fez os passos descritos acima, você terá como resultados final a tela apresentada na figura acima.

Fizemos um passo bem simples, somente para você ir se acostumando com o IB, porém vamos entender um pouco mais do ambiente. Para entender um pouco mais vamos usar o Identity do Inspector (o quarto botão da esquerda para direita). Ainda com a Main View selecionada, escolha o Identity. Veja qual a classe que está selecionada, Main View. Esta é a classe definida no XCode. Recordem que existe uma pasta no projeto chamado de Main View e dentro existem 4 arquivos: MainView.h, MainView.m, MainViewController.h e MainViewController.m. A janela Main View do IB está relacionada com a classe MainView (.h e .m) do projeto XCode. Agora, selecione o File’s Owner da janela MainView.xib do IB e volte para o Identity. Agora a classe referenciada é a MainViewController. O que isto quer dizer? Quer dizer que quando criarmos um componente gráfico pelo IB dentro da MainView, este elemento deverá ter sua referência dentro das classes por ele representado.

Deve ter ficado um pouco confuso isso. Então vamos para a prática. Vamos inserir um componente na MainView e vamos referência-lo no código. Como dito anteriormente, é na Library que estão todos os componentes do IB. Selecione Input & Values e arraste o componente Label (UILabel) para dentro da MainView. Para facilitar a visualização, vá em Attributes e altere a cor do Label para branco. Para fazer isso, de um click em cima do componente que acabou de arrastar, fazendo com que ele fique selecionado, e depois escolha uma cor no item Color.

Ao fazer este click, aparecerá um menu do tipo popup, escolha a opção Open As e depois Source Code File.

Quando você executa estes procedimentos está acessando o código fonte deste arquivo e desta forma poderá modificar o fonte da maneira que achar conveniente. Como até o momento temos pouca experiência, não vamos inventar nada de mais, vamos apenas acrescentar algumas linhas de código para que possamos inibir a barra de status da nossa aplicação. As linhas que vamos inserir são:

<key>UIStatusBarHidden</key>

<true/>

Colocaremos estas linhas no final do arquivo, mas respeitando as tags já existentes:

Repare que as linhas foram inseridas no final do arquivo, porém respeitando as tags dict e plist. Se você inserir fora destas tags, você estará gerando erros e o comportamento da sua aplicação sairá do controle.

Após incluir estas linhas você pode voltar para o formato original que o XCode exibe para você, para isso dê um click com o botão control pressionado em cima do arquivo, com isso aparecerá um menu do tipo popup, escolha a opção Open As e depois XML Property List. Se nesta operação aparecer uma mensagem perguntando se deseja salvar o que você escreveu, você deve confirmar para que estas linhas de fato sejam inseridas no arquivo.

Se você fez tudo certo, teremos a seguinte tela

Repare na última linha, Status bar is initially hidden. Esta linha fará com que a barra de status seja excluída da nossa aplicação. Existe uma maneira de retirar esta linha de forma programática, porém esta é a mais eficiente. Usamos da forma “programática” quando queremos variar o comportamento da aplicação, ora mostrando, ora inibindo esta barra. Veremos um pouco mais a frente como manipular esta barra programaticamente.

Agora, vamos ver a nossa aplicação sem a barra de status, rode a aplicação.

Ualá!!!

Estamos sem a barra de status.

Como falei anteriormente, existe outra forma de inibir a barra de status da nossa aplicação, mas de forma “programática”. Vamos entender que quando falamos forma “programática” queremos dizer que vamos usar ObjC.

Porém para entendermos como vamos utilizar o ObjC neste caso, precisamos entender primeiro como funciona o modelo de projeto que o wizard do XCode gera para o desenvolvimento. Quando o wizard gera o código, ele gera um esquema próprio, que tem como partida a delegação do inicio da execução do código para um controller. Um pouco mais para frente falaremos deste controller, vamos apenas ter em mente que inicialmente criamos um projeto do tipo Utility, e que esta delegação fará com que um controller do tipo “Utility” seja inicializado no momento da execução do código.

De uma maneira resumida, o que vamos fazer, é que assim que o código for delegar a sua execução, nós vamos retirar a barra de status, com a seguinte linha de código:

[[UIApplication sharedApplication] setStatusBarHidden:YES animated:NO];

Mas aonde vamos colocar esta linha?

Como queremos que a barra de status desapareça no momento da execução, vamos colocar esta linha no arquivo iPhoneHelloAppDelegate.m, que está contido na pasta Application Delegate.

Repare que colocamos a linha no método applicationDidFinishLaunching, que é o método que é chamado assim que uma aplicação é inicializada. Como vocês são alunos muito aplicados, vão se lembrar que já falei de uma certa função que é chamada assim que uma aplicação é inicializada, a viewDidLoad. Porém a viewDidLoad está declarada em uma classe controller e a applicationDidFinishLaunching em uma classe delegate. Isto quer dizer que a função viewDidLoad é chamada (executada) após a execução do método

applicationDidFinishLaunching, pois primeiro se executa o delegate e depois o controller.

Façam o teste e executem a aplicação depois de colocar esta linha no applicationDidFinishLaunching, não se esqueçam de remover a linha do código XML. Quando estiverem executando o código reparem quando a aplicação se inicializa no simulador, reparem que além de ser mais lenta ocorre uma “piscada” na tela. Por esta razão daremos sempre preferência em usar o arquivo XML, que é mais rápido e mais limpa, sem esta “piscada”. Usamos este comando ObjC, quando queremos habilitar (ou desabilitar) a barra de status durante a execução da aplicação.

Entendendo a Área de Trabalho

Vamos começar entendendo nossa área de trabalho. Observe o painel do lado esquerdo da janela do XCode.

Objective-C

Como disse anteriormente, a linguagem de desenvolvimento para iPhone é a Objective-C, ou ObjC. Esta linguagem é um superset da poderosa linguagem C, os comandos básicos advém desta linguagem, porém ObjC é uma linguagem orientada à objetos (OOP). Caso você não saiba o que é uma linguagem orientada à objetos, recomendo procurar uma literatura para compreender melhor, não entender o que isso significa pode comprometer o bom entendimento deste curso. Como ObjC é uma evolução da linguagem C, absorveu todas estruturas primárias de sua antecessora. Se você conhece a linguagem C, achará muito familiar na estrutura demonstrada anteriormente nos arquivos com extensão “.h”. Arquivos com estas extensões são chamados de header (como no C), a diferença está nos seu par, enquanto no C seu par tem extensão “.c”, no ObjC o seu par tem extensão “.m”. Observe, por exemplo, MainView.h e MainView.m. No arquivo header possuímos todas as declarações de variáveis e funções que serão implementadas no arquivo com extensão “.m”. Será um bom execício de observação, verificar os conteúdos de cada arquivo “.h” e “.m” correspondente.

Uma pergunta muito comum quando começamos desenvolver para iPhone, é tentar saber se existe outra linguagem para o desenvolvimento de aplicações nativas. A resposta é não. A Apple disponibilizou somente o ObjC no SDK. Você pode desenvolver uma página web para iPhone, ai você usa outra linguagem, porém por não ser uma aplicação nativa, você perde muitas funcionalidades nativas do aparelho.

Executando o Projeto

Como já vimos, montar um projeto foi bem tranqüilo. Agora vamos executar o projeto. Com o Projeto1 aberto, vamos compilar o projeto e verificar se existem erros no projeto. De um click no botão Build que fica na parte alta, ou vá até o menu Build e escolha Build, ou ainda tecle command+B.

Claro, não vai dar erro algum, quem montou este código foi o próprio XCode, não tem erro e já poderemos executar o programa no simulador.

Para executar a aplicação no simulador, podemos executar clicando no botão Build and Go, ou vá até o menu Build e selecione Build and Run, ou ainda tecle command+R.

Observe que o XCode compila o código novamente, este é um comportamento esperado de todo ambiente de desenvolvimento, primeiro compila e depois executa. Quando o XCode executa o simulador, ele está na verdade chamando outro programa, ou seja, o simulador deve ser encerrado quando acabarmos de observar o código. Veremos também que será possível fazer Debug do nosso código. Quem ainda não é um desenvolvedor, deve estar se perguntando o que é um Debug. Quando um desenvolvedor disser que está “debugando” um código, ele quer dizer que está executando um código e ao mesmo tempo está verificando qual linha de código está sendo executada. Quando queremos fazer um Debug de um código, colocamos um breakpoint no código, e quando o simulador passar por esta linha, ele para a execução para que possamos verificar se o conteúdo de todas as variáveis estão de acordo com que estávamos imaginando, e se os caminhos que imaginamos que o simulador ia seguir está de fato sendo seguido. Usa-se muito esta funcionalidade de Debug para localizar erros de um código, pois é sem dúvida a melhor maneira de encontrá-los.

Porém, antes de aprendermos mexer com o Debug, vamos observar o simulador funcionando.

Como podemos observar, o simulador é uma cópia fiel de um iPhone. Com o simulador temos a possibilidade de efetuar quase todas as funcionalidades que um aparelho como o iPhone possui.

Assim que o simulador estiver funcionando, vamos pressionar o ícone “i”. Veremos a tela efetuar uma efeito chamado de flipview (figura 05). Depois de efetuar o efeito, teremos outra tela disponível, se você pressionar o botão Done, teremos novamente o efeito flipview e voltaremos para a tela principal da nossa aplicação. Antes de fecharmos o simulador, vamos fazer uma rotação do iPhone.

Para efetuar a rotação do iPhone, de um click na opção Hardware e depois selecione Rotate Right. Pronto conseguimos simular a rotação do iPhone. Como podemos observar é possível simular a rotação do iPhone, veremos um pouco mais adiante como podemos modificar o comportamento da nossa aplicação de acordo com a rotação do aparelho.

Pronto, vamos terminar a nossa primeira incursão no simulador, para fecha-lo vá até o menu iPhone Simulator e escolha a opção Quit.

Breakpoint, Run e Debug

Como dito anteriormente, usamos o Debug quando queremos localizar um comportamento não esperado da nossa aplicação. Para podermos trabalhar corretamente com o Debug, temos que inicialmente incluir um breakpoint no nosso código. O que vem a ser este breakpoint. Como o próprio nome diz, é um ponto onde queremos que a execução da aplicação pare. Quando o simulador encontra um breakpoint, ele suspende a execução da aplicação, sem encerrá-la, e permite o acesso ao conteúdo das variáveis naquele momento do código.

De um click no arquivo RootViewController.m, do lado direito vai aparecer o código que este arquivo contém. Perceba que este código é numerado, e para inserir um breakpoint, nós vamos dar um click em cima do número da linha que desejamo que o simulador pare, no caso mostrado na figura 07, foi executado um click em cima da linha 25. Quando inserimos um breakpoint, a linha fica com uma seta azul. Para remover um breakpoint, click novamente em cima da linha, mas com o botão control pressionado, irá aparecer um menu popup com uma opção para remover breakpoint.

Mas antes de remover vamos executar o simulador com este breakpoint ativo. Basta dar um click no botão Build and Go.

Assim que você executar o simulador através do botão Build and Go, o simulador será executado, e antes que possa aparecer algo na tela do simulador, ele volta para o ambiente do XCode e naquele breakpoint que colocamos na linha 25, agora temos uma seta vermelha. Isto ocorreu, porque no momento que o simulador foi executar esta linha, ele encontrou um breakpoint, e com isso ele suspendeu a execução do código e retornou para o XCode.

A primeira coisa que aprendemos, (sim, já aprendemos algo agora) é que antes de exibir o conteúdo de uma tela, a função viewDidLoad é carregada primeiro. Repare que antes de exibir qualquer coisa, o simulador tentou passar pela linha 25, que faz parte desta função. Primeira lição, se você deseja que a sua aplicação execute algo algo de extrema importância antes de sair executando qualquer tela, a função viewDidLoad é um bom local para colocar este código. Veremos mais para frente o que podemos fazer, mas é bom já ir prestando atenção neste comportamento.

Eu disse antes que quando estamos “debugando”, podemos conferir o conteúdo das variáveis que estamos usando. No momento que o simulador volta para o XCode é o momento ideal para validarmos estes conteúdos.

Para checarmos estes conteúdos, vamos clicar no menu Run e selecionar a opção Debugger.

Vamos observar que uma nova janela aparece, e nela podemos validar o conteúdo de variáveis, do lado direito da janela temos 3 colunas, a primeira variable, a segunda value e a terceira summary. Como nosso bom inglês já explicou, na coluna value teremos o conteúdo da variável neste exato momento que o simulador suspendeu a execução da aplicação e retornou para o XCode.

Com isso terminamos nosso primeiro capítulo. Ainda não colocamos nenhum código no projeto, mas já tivemos o primeiro contato com o ambiente de programação, já vimos como usar o simulador e até como efetuarmos um Debug no código. Vamos agora consolidar nossos conhecimentos, para poder ir mais adiante. Vamos aos exercícios!

Exercícios

1. O que encontramos na pasta Resource de um projeto iPhone?
2. Quais os comandos procedimentos para fazer a rotação do aparelho no simulador?
3. Qual é uma das primeiras funções (métodos) executados no momento que um código do iPhone é executado?
4. Defina breakpoint e Debug.
5. Crie um projeto do tipo Utility, chamado iPhoneHello. Execute o projeto e veja o conteúdo da variável $st6.

(by Ademar Varela)