Publicado por: webclaudio | 04/05/2009

Curso de programação para IPHONE – Parte 9

Título do Post

Olá pessoal. Neste capítulo vamos aprender sobre como interagir um pouco mais com o usuário. E para isso vamos construir nossa primeira aplicação usando o Interface Builder que vamos a partir de agora chamar carinhosamente de IB. Mas antes acho prudente falar também de algumas limitações quando se programa para dispositivos móveis. Bom aprendizado.

Bom, vamos começar a descrever as limitações no que diz respeito a desenvolver para iPhone:

Limitações da Plataforma

Quando se fala de plataformas móveis como o iPhone, sempre surgem várias preocupações, tais como armazenamento, limites de interação, bem como a duração da bateria. Plataformas móveis não podem oferecer o mesmo espaço em disco que dispositivos Desktops. E juntamente com limites de armazenamento, interfaces reduzidas e o consumo de energia restringem de uma forma muito real o que você como um desenvolvedor pode realizar.

Com o iPhone, não é possível desenvolver pensando em uma grande tela, um mouse, um teclado físico, ou mesmo para um abastecimento de energia sempre ligado na parede. Em vez disso, você deve moldar e orientar o seu desenvolvimento às realidades da plataforma. Felizmente, a Apple fez um trabalho incrível criou uma nova plataforma que impulsiona alguma flexibilidade a partir do seu conjunto de armazenamento limitado, interação limitada e limitada vida da bateria.

Limites de Armazenamento

O iPhone possui uma poderosa mas ainda compacta versão do sistema operacional OS X instalado. Embora todo o iPhoneOS preencha não mais do que algumas centenas de megabytes de espaço, quase nada comparado aos sistemas operacionais de hoje, ainda fornece uma biblioteca extensa de frameworks.

Estes frameworks de rotinas pré-compiladas do iPhone permitem aos usuários executar uma gama diversificada de compactas aplicações, desde telefonia à reprodução de áudio, desde e-mail à navegação na Web.

O iPhone oferece suporte suficiente de programação para criar interfaces flexíveis mantendo-se seus arquivos de sistema em tamanhos reduzidos para encaixar perfeitamente dentro de limites de armazenagem apertados..

Limites de Acesso a Dados

Cada aplicação do iPhone sofre um “sandbox” (Nome conhecido em ambientes Unix cuja tradução é caixa de areia, este procedimento fecha sua aplicação e limita acessos ao dispositivo e Sistema operacional) . Seu programa não pode ser acessado a partir de outras aplicações e de certas pastas, incluindo a biblioteca iTunes interna. Ele pode, porém, acessar quaisquer dados que estejam disponíveis gratuitamente através da Internet quando o iPhone está conectado a uma rede.

Limites de Memória

Em se falando de iPhone, o gerenciamento de memória é critico.O iPhone não dá suporte ao “swap” para realizar memória virtual (Acredito que todos saibam do que estou falando).Quando sua memória se esgota, o iPhone reinicializa. Provavelmente randômicos reboots não são a melhor experiência com usuário que você estava esperando. Sem “Swap”, você deve gerenciar cuidadosamente a sua memória e exige-se estar preparado para o caso do iPhoneOS terminar a sua aplicação se este consumir muita memória.Você também deve ter cuidado no que diz respeito ao uso de recursos. Muitas aplicações usam alta resolução de imagens e arquivos de áudio pesados que podem fazer seu programa candidato para um autoterminate.

Nota
Xcode automaticamente otimiza suas imagens PNG utilizando o utilitário pngcrush do SDK. Por esta razão, você deve utilizar imagens PNG em suas aplicações iPhone sempre que possível como o seu formato preferido de imagem.

Limites de Interação

Trocar dispositivos físicos de entrada e trabalhar em uma pequena tela não significa que você perde interação e flexibilidade. Com o multitouch (Múltiplos toques), você pode construir interfaces de usuário que desafiam as regras. A tecnologia touch do iPhone permite que você crie aplicações completas com entradas de texto e pontuação, usando uma teclado virtual que é muito maior do que seria um real físico. Um auto-corretor inteligente e um acelerômetro que detecta a posição do aparelho são apenas duas das principais tecnologias que separam o iPhone do resto da computação móvel.

Nota
A tela do iPhone suporta até cinco toques ao mesmo tempo, embora, seja raro encontrar qualquer aplicação que use mais de dois de uma vez.

Limites de Energia

Para plataformas móveis, você não pode ignorar as limitações de energia. Sabendo disto, as características do SDK da Apple ajudam a criar as suas aplicações limitando a utilização da CPU e evitando o uso contínuo da bateria. A utilização inteligente da tecnologia (por exemplo, como suspender corretamente os programas) permite que seus aplicativos rodem muito bem no iPhone e evitam do seu software queimar energia à toa. Alguns programas, quando deixados executando, produzem elevados níveis de calor residual fazendo com que o telefone torna-se quente ao toque e a bateria rapidamente acabe. A câmera é um notável exemplo.

Limites de Aplicação

A Apple tem instituído uma forte política de “uma aplicação por vez”. O que significa que para um programador não é possível desenvolver aplicações que são executados em segundo plano como os da Apple (utilitários de Correio e telefone). Cada vez que seu programa é executado, tem de limpar e metaforicamente sair do controle antes de passar para a próxima aplicação selecionada pelo usuário. E não podem deixar correr um daemon que verifica a existência de novas mensagens e as envia ou periodicamente fazer updates. Um “Open SDK” criado por hackers existe para contornar esta limitação, mas aplicações construídas com essas ferramentas não podem ser adicionados aos e vendidos através do iPhone AppStore.

Por outro lado, a Apple suporta enviar dados pela Web. WebServices podem enviar e receber mensagens as aplicações.

Nota
De acordo com os Termos de Serviço do iPhone, você não pode criar frameworks externos para a sua aplicação iPhone ou usar a arquitetura de plug-in Cocoa nas aplicações apresentados à AppStore.

Bom, então conhecendo nossas limitações vamos por a mão na massa e fazer nossa primeira aplicação usando o interface Builder (IB para os íntimos).

Manipulando Interações

Nossa aplicação “Alô Mundo!” foi uma boa introdução para o desenvolvimento em iPhone usando o Cocoa Touch, mas ele não tem uma crucial habilidade: A habilidade de interagir com o usuário. Sem ele, nossa aplicação é severamente limitada em termos de abrangência.

Neste capítulo nós iremos escrever uma aplicação um pouco mais complexa, com dois botões e um label como mostrado na figura abaixo. Quando o usuário tocar no botão a mensagem do label mudará. Isto pode ser visto como um exemplo simples, mas irá demonstrar o conceito básico para manipular controles nas aplicações iPhone.

projeto2-1O paradigma MVC

Antes de iniciarmos, precisamos de um pouco de teoria. Os designers do Cocoa Touch foram guiados por um conceito chamado Model-View-Controller (ou MVC), que é o caminho mais lógico de dividir o código da interface gráfica. Nos dias atuais todos os frameworks pegam um pouco da lógica MVC, mas nenhum outro como o Cocoa Touch.

O modelo MVC divide todas as funcionalidades em três categorias distintas:

  • Model: São as classes de sua aplicação que acessam dados;
  • View: Contém seus Windows, controls, e outros elementos que o usuário possa interagir;
  • controller: liga o Model ao view e é a parte lógica da aplicação que decide como manipular as entradas do usuário.

A meta no MVC é fazer que os objetos que implementam esses três tipos de código serem diferentes um do outro quanto possível. Qualquer objeto que você escreva o terá que ser identificado em uma dessas três categorias, com pequena ou nenhuma funcionalidade e que o fizesse estar classificada nas outras duas.

Em um objeto que implementamos um botão, por exemplo, não se deve conter códigos para processar dados quando este botão é pressionado, e o código que implementa uma conta de banco não deve desenhar a tabela que mostra esta transação.

O MVC ajuda a você a ter o máximo de reusabilidade. A classe que implementa um botão genérico pode ser usada em qualquer aplicação. A classe que implementar um botão que faz um cálculo particular só podem ser usados na aplicação que originalmente foi escrito.

Quando você escreve aplicações Cocoa Touch, você irá primeiramente criar seus componentes View usando o interface builder, você poderá também algumas vezes modificar sua interface pelo código, ou você poderá instânciar existentes views e controls.

O seu Model será criado pelas classes do Objective-C que você criar e que são específicas para a sua aplicação. Mas não estaremos criando nenhum objeto Model neste capítulo, porque nós não precisamos guardar ou preservar dados, mas nós iremos introduzir objetos Model quando nossa aplicação ficar mais complexa em futuros capítulos.

Seu componente controller estará tipicamente compreendida nas classes que você criar e que são específicas para a sua aplicação. Controllers podem ser completamente customizadas, mas eles oferecem mais, eles podem ser istanciadas dia existentes classes de controles genéricos do UIKit framework como o UIViewController, que você verá em alguns instantes. Istanciando uma dessas existentes classes, você irá pegar um monte de funcionalidades gratuitamente a que não terá de perder tempo reinventando a roda, como dizem.

Quando nós nos aprofundarmos no Cocoa Touch, você irá rapidamente começar a ver como as classes do framework UIKit segue os princípios da MVC. Se você colocar este conceito dentro de sua cabeça de desenvolvedor, você irá melhorar seu código e verá que ficará mais fácil mantê-lo.

Criando nosso projeto

Desta vez para criar o nosso projeto Xcode. Nós iremos usar um diferente template: view-based Application. Vamos em frente criar o nosso projeto, salve-o com o nome de Button_Fun. Se você tiver algum problema criando seu projeto, referencie o procedimento do capítulo anterior.

Você provavelmente se lembrar que o projeto foi criado com algumas classes para nós. Você irá encontrar as mesmas classes neste projeto apenas os nomes que serão um pouco diferente por causa dos nomes das classes serem baseadas no nome do projeto.

Criando o View controller

Um pouco depois deste capítulo, nós iremos desenhar um View (ou interface de usuário) para nossa aplicação usando o interface Builder, como nós dissemos no último capítulo. Antes de nós fazemos isso, nós iremos dar uma olhada e fazer algumas mudanças no código que foi criado automaticamente para nós.

Antes de nós fazemos algumas mudanças, vamos dar uma olhada nos arquivos que foram criados para nós. Na janela de projeto, expanda a pasta de classes para revelar os quatro arquivos dentro. Conforme imagem abaixo:
projeto2-2Estes quatro arquivos implementam 2 classes, cada uma contém um .m e .h arquivo. Aplicação que nós iremos criar neste capítulo tem somente um View, e a classe controller que é responsável pelo gerenciamento é chamada Button_FunxiewController Clique no Button_FunViewController.h e dê uma olhada no conteúdo arquivo:

#import <UIKit/UIKit.h>
@interface Button_FunxiewController: UIViewController {

}
@end

Não é muito. Essa é uma estância do UIViewController, que é uma das classes de controles genéricos que nós mencionamos anteriormente a. Ele faz parte do UIKit e nos dá um range de funcionalidades gratuitamente. Os Xcode não sabe que funcionalidade específica nossa aplicação do irá fazer, ele só sabe que irá fazer alguma coisa, então ele cria esta classe para essa funcionalidade genérica.

Nosso programa consiste em dois botões e uma caixa de texto que reflete qual botão nós apertamos. Mas criaremos todos esses três elementos no interface Builder. Desde que nós também iremos escrever um código, ele deve ter alguma forma de interagir com seu código a interagir com os elementos criados no interface Builder, certo?

Absolutamente certo. Nossa classe controller pode referenciar objetos do interface Builder usando uma especial porção de variáveis de instâncias chamadas de “Outlet”. Pense no Outlet como um ponteiro que aponta para um objeto do nib. Por exemplo, suponha que você crie uma caixa de texto no interface Builder e queira chamar essa caixa de texto pelo seu código. Para declarar um outlet para o objeto label, você deve usar o outlet dentro do seu código para mudar o objeto label. Você verá como fazer isso daqui a pouco.

Indo em outra direção, objetos de interface no nosso arquivo “nib” pode ser configurado para chamar métodos especiais na nossa classe controller. Só que esses métodos especiais são conhecidos como os métodos de ação “Action”. Por exemplo, você pode dizer o interface Builder que quando o usuário tocar no botão, um método especifico do código deve ser chamado.

Nosso próximo exemplo irá atribuir dois botões e um label.

No nosso código, iremos criar um outlet que aponta para o label, e este outlet irá permitir mudar o texto do label. Nós também criaremos um método chamado buttonPressed: que irá acionar quando um dos dois botões forem tocados . buttonPressed: irá configurar a propriedade texto do label dizendo ao usuário que botão ele apertou.

Nós usaremos o interface Builder para criar os botões e eu label, e depois nós faremos alguns cliques e arrastar e soltar para conectar o label ao nosso label Outlet e nossos botões a nossa ação buttonPressed.

Mas antes vamos mexer no código, mas daremos um pouco mais de detalhes sobre os Outlets e os Actions.

Outlets

Outlet são variáveis de instância e são declaradas usando a palavra chave IBOutlet. A declaração de um Outlet fica no cabeçalho do seu arquivo controller “.h” que pode se parecer com isso:

IBOutlet UIButton *myButton;

A palavra chave IBOutlet é definida desta forma:

#ifndef IBOutlet
#define IBOutlet
#endif

Confuso? IBOutlet Não faz absolutamente nada em que o compilador esteja envolvido. Ele é feito propositalmente o para agir como uma dica ao interface Builder que esta é uma variável de instância que nós iremos conectar a um objeto em um nib. Qualquer variável de instância que você crie e quiser conectar a um objeto no arquivo nib deve ser precedida de um IBOutlet. Quando você abrir o interface Builder, ele irá procurar os seus arquivos de cabeçalho do projeto a ocorrência dessa palavra chave em irá permitir a você fazer conexões do seu código para a sua variável nib equivalente. Em alguns minutos, você verá como atualmente se faz uma conexão em entre o Outlet e um objeto de interface de usuário com interface Builder.

Actions

Actions São métodos que fazem parte de sua classe controller. Eles são também declarados com uma palavra chave especial , IBAction, que xiz ao interface Builder que este método é uma ação e pode ser provocado por um controle. Tipicamente, é o a declaração de um método Action irá se parecer com isso:

– (IBAction) fazAlgumaCoisa:(id)sender;

O atual nome do método pode ser qualquer coisa que você quiser, mas ele deve retornar um tipo “IBAction”, que é o mesmo que declarar um tipo de retorno “void”. Esta é outra forma de dizer que o método Action não retorna valor algum. Usualmente, o método Action irá pegar um argumento, e será tipicamente definido como id e também dará o nome de quem solicitou (sender). O controle que provoca a sua ação usar o argumento “sender” para passar a referência dele mesmo. Então, por exemplo, se seu método Action foi chamado pelo resultado de um toque no botão, o argumento “sender” deverá conter a referência para o botão específico que foi apertado.

Como você verá, o nosso programa irá usar o argumento sender para configurar o label com texto esquerda e direita, dependendo do botão que você apertar. Se você não precisa saber qual o controle chamou seu método, você pode também definir o método Action sem um parâmetro “sender”. Ele deve se parecer com isto:

– (IBAction) fazAlgumaCoisa;

Você não precisa se preocupar se você declarar um método Action com um argumento “sender” e ignorar o “sender”. Os métodos Action do Cocoa aceitam o sender sendo usados ou não.

Somando Actions e Outlets no seu View controller

Agora que você sabe o que Outlets e Actions são, vamos ao cabeçalho somar cada uma de nossas classes de controle. Nós precisaremos de um Outlet para podermos mudar o label. Nós não vamos querer mudar nada nos botões, nós não precisaremos de Outlet para eles.

Nós iremos declarar um único método Action que será chamado por ambos os botões. Quando muito os métodos Action são chamados por um único controle, é possível usar a mão única ação para manipular entradas de múltiplos controles, que é o que nós vamos fazer aqui. Nosso Action irá pegar o nome do Butão e colocar no argumento sender e usar o Outlet do label para inserir no nome do botão na propriedade ”text” do label.

Vamos agora somar o seguinte código no Button_FunViewController.h:

Nota: O que tiver em negrito é o que está sendo somado.

#import <UIKit/UIKit.h>
@interface Button_FunxiewController: UIViewController {

IBOutlet UILabel *statusText;
}
@property (retain, nonatomic) UILabel *statusText;

– (IBAction) buttonPressed: (id)sender;
@end

Bom gente, acho que já tem muito texto para um Capítulo só. Desculpem tanta teoria, mas sem ela não irá ter pernas para caminhar por outras veredas. Nesta semana ainda termino a outra parte do nosso projeto. Consegui uma forma mais rápida de fazer estes tutoriais e pretendo adiantá-los bastante. Abraços.

Anúncios

Responses

  1. Muito legal. Valeu por ter postado mais rapidamente. Você está de parabéns.

  2. Muito bom essa sua iniciativa. Parabens.

  3. Valeu Cláudio ! estou acompanhando e aprendendo com vc. Vamos para a parte 10.

    abs


Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

Categorias

%d blogueiros gostam disto: